Важный навык хорошего инженера, который я пока не смог формализовать - четкое ощущение времени когда в развивающемся проекте надо сказать "стоп" и сделать если не рефакторинг, то детальный ревью архитектуры, чтобы проект не был погребен под велосипедами и костылями 🧵
Сейчас я это наблюдаю на примере моих горячо любимых vue-test-utils - как появление новых и новых и новых фичей увеличивает сложность проекта и прямо сейчас ощущаю необходимость остановиться и переделать значительный кусок. Но в опенсорсе с этим проще 🧵
В реалиях работы всегда важна, конечно же и бизнес составляющая. Сильно помогает, когда бизнес уже "стал на ноги" и может предоставить хоть приблизительный план развития на какой-то срок (хотя бы полгода!) 🧵
Отсюда следует важный вывод: в стартапе на ранних стадиях на это надеяться не стоит - стартап это про бесконечные пивоты и поиск себя и самая грамотная архитектура - "корзинки для говнокода", которые позволят вам меньше страдать от регулярной смены линии партии
Важно понимать то бизнес готов выдать "план" - совершенно не значит что он будет соблюден - все пойдет не так в первый же возможный вариант. Поэтому всегда закладывайтесь шире, чем вам обрисовали. Иначе будет как в древней-древней истории - не хватит байта habr.com/ru/post/27055/
Сам я побывал по обе стороны баррикад - и в позиции тех с криками "ааа, вы тут нарушили SOLID" требует рефакторинга сразу как увидели код, и в позиции "интересы бизнеса главное, какой рефакторинг - он деньги не принесет". Если издержки первой очевидны, о второй стоит поговорить
Рассуждая о бизнесе, всегда стоит помнить что "перекладывать ответственность" на бизнес за подобные решения стоит тогда, когда вы убедились что последствия НЕпроведения рефакторинга доведены бизнесом и осознанны. Иначе у менеджмента просто нет экспертизы для принятия решения
Здесь очень важно быть здравым и избегать гипербол - если вы будете стращать бизнес что все навернется через 3 месяца, бизнес на свой страх и риск решит продолжать "как есть", а через 3 месяца все не навернулось - протолкнуть рефакторинг, который стал еще нужнее будет сложно
Сейчас, когда я говорю о рефакторинге я обычно употребляю формулировки вида "я прогнозирую падение velocity команды на Х пунктов в течение Y месяцев". И даже это - шаткая позиция, потому что стори пойнты включают в себя 3 метрики - сложность задачи, объем и неопределенность
Таким образом чистая скорость команды в сторипойнтах может расти, в то время как проект решительно катится в Адъ. И это не потому что программисты "читерят" и оптимизируют метрики - а потому что метрика совсем не про это
А где же метрика "ценности фичи для бизнеса" - а это банальная priority - чем фича выше в приоритете, тем ценнее для бизнеса. И вот сумма приоритетов заделивериных фич обычно хорошо показывает приближение проекта к тепловой смерти
• • •
Missing some Tweet in this thread? You can try to
force a refresh
