Качество и Lean Startup
Сейчас среди стартапов модна идеология Lean — делать minimal valuable product, не заморачиваться над архитектурой, готовиться к тому, что проект — это тестирование бизнес-идеи на выживаемость, и возможно идея будет передумана, часть кода удалена, поэтому вкладывать много времени в доведение качества до 100% и в разработку супер-архитектуры невыгодно.
Кто работал в таких стартапах как аутстафф? Как вы относитесь к тому, что 100% качество не требуется, да и времени на 100% качество не даётся, не претит ли («не для того я 5 лет учился, чтобы теперь некачественно делать»)? Стоит ли программисту с нормальным образованием и 7+ лет полноценного опыта ввязываться в такое, или опытным — только в серьёзные проекты, а Lean Startup-ы должны писать студенты, «не царское это дело»?
9 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівЯ бы сказал, наоборот — как раз имея 7+ опыта есть шанс «вытянуть» потребности стартапа, где все быстро меняется и любое ошибочное решение через месяц может аукнуться очень больно.
Студентам проще учиться на больших стабильных проектах — никто не куда не спешит, у «старших» есть время на обучение и даже если сделал глупость, ее скорее всего выловит процесс — review/QA.
Пример ниже dou.ua/...ic/9755/#468621
Что бы вы делали?
Не понял как могут сотрудники, которые умеют делать дело, спецом делать негодный продукт. Любой нормальный прогер бунт поднимет если скажут «жертвуй качеством в угоду скорости» — это вот вообще как? :) Набор фич может быть урезан, но если работает про, то он сделает их как про.
Другое дело что аж потом становится ясно что можно было сделать лучше, специально фигню никто в здравом уме не делает.
Простите, а разве вам надо «дополнительное время на качество»?
Пример: есть однотипные модули, в них есть общая функциональность, которую хорошо бы проанализировать и вынести в отдельное место (класс, модуль, неважно). Чтобы проанализировать существующие модули, выделить в них общее и вынести это общее, нужно дня два-три хотя бы(16-24 часов). 24-32 часа. Анализировать и переписывать существующее «не нужно, раз работает — не трогаем», «нам всего лишь нужен ещё один модуль к следующей неделе». Но вынести общее хочется (code smell же), и понимаешь что ты поддерживаешь (расширяешь) некачественную структуру.
Тебя просят дописать ещё один модуль и даётся на него
Разработка по скраму, т.е. в спринтах важно реализовывать user stories, а «мы улучшили архитектуру» это не user story, поэтому в скрам не вписывается.
На ДОУ есть такая колонка:
dou.ua/...pravo-na-vybor
А вот тут кроется несколько проблем.
1. Общая функциональность — архитектурный баг. Похожая функциональность — ещё не повод выносить её отдельно (очень часто потом оказывается, что функциональность таки не очень похожая, и по факту запиливается несколько реализаций в одном модуле/классе).
2. Нужно уметь четко объяснить, зачем нужны изменения, и в какой перспективе будет профит. Переделкой архитектуры за неделю до публичного релиза никто не занимается, это правда.
И да, по-моему опыту, обычно код протухает примерно так:
А добавлю-ка я ещё пару строчек в этот метод/класс =>
Ой, кажись название уже не очень соответствует функционалу, но не менять же название метода/класса по всему коду =>
Хрен его знает, что в этом модуле творится, пойду лучше свой напишу
Никакого отношения к скорости это не имеет.
Другий пункт — так, перший буває рідко, частіше код накопіпащений як у Some Developer зустрічається.
В шахматах, гроссмейстер 5 минутную партию сыграет тоже вполне качественно. Думаю, после 7+ лет оптыта, любое спагетти будет плавно пересекать в паттерны, архитектуру и тп.