Ответ на статью.
Если вы не разрабатываете ПО для машин или систем автоматического поддержания жизни и тд — нижесказанное работает для вас при грамотном применении.
Сразу скажу — не моя идея, в статье «Проектирования больше нет?» сам Мартин Фаулер писал об эволюционном рефакторинге. А Боб Мартин даже целую книгу запилил с примером поэтапного развития приложения (и не одним), назвав «Быстрая разработка ПО» и продемонстрировав умение виртуозно материться на Java и C++.
Во-первых, говнокод на первом этапе обязателен. Причин куча. Раз — вы ничего не знаете о реальных условиях работы приложения, все ваши домыслы фигня. Пока реальный опыт не получен, пока не занесены первые живые данные реальным пользователем — у вас нет обратной связи. Если вы не согласны, почитайте Макконнелла, миф о стабильных требованиях, и получите левелап.
Два — зарплата не берется из воздуха, и от идеи до хоть как-то взлетевшего стартапа лежит некий период поиска удачных вариантов функционала и монетизации. Прежде всего — функционала. И чем быстрее стартап может изменяться, тем с большей вероятностью он разовьется до стадии самодостаточности, обойдет конкурентов и пойдут деньги, из которых можно будет платить разработчикам премии. Как писал пророчески Билл Гейтс в 1997, 2000е будут десятилетием скорости. Кстати, на Хабре было исследование, согласно которому большая часть успешных стартапов так или иначе имели в своем развитии говнокод.
Несколько конкретных примеров.
Мы делаем трехуровневое меню хардкодом (версткой и массивами в годобжекте, magic numbers и другие антипаттерны), и у нас это копируют конкуренты, проектируя дерево в базе и делая кучу классов. Мы следим за кликами пользователей и видим, что люди теряются. Упрощаем меню, меняем код за один день (он простой, и выбросить не жалко хардкод, так как знали, что перепишем). У конкурентов начинается срач между ведущими, которым жалко менять спроектированное меню и две недели крутого правильного программирования, плюс у них замылен глаз. В итоге мы получили две недели времени.
Дальше мы делаем денормализованную таблицу товаров и категорий, экспериментируем с рубрикатором. Конкуренты делают пятую нормальную форму, категории nested sets, пишут неделю кучу хранимок в базе. В это же время за неделю мы по кликам, статистике, аналитики конверсии заказов поняли, что нужна линейная категоризация, выбрасываем категории и делаем облако тэгов. Конкуренты в шоке, еще неделя выиграна.
Затем мы делаем сводный отчет за час руками в php. Оно жрет память, но работает. Анализируя поведение человека, допиливаем отчет и приступаем к рефакторингу. В это время от конкурентов уходит разработчик-идеалист, которому надоела смена правил игры, и они вешают вакансию поиска на месяц — ведь они писали на рельсах, а не на противном php, поэтому разработка стоит в два раза дороже и поиск разработчика тормозит проект на четыре недели.
Через два месяца конкуренты умерли, а мы переписали проект (часть я переделал на плюсах, когда трафик вырос), так как уже знали все сущности, бизнес-процессы и user stories, покрыли тестами, наладили CI. Еще заплатили премию нашим дорогим программистам из денег, которые мы заработали за счет прорыва на рынке, и отправили наших разработчиков бесплатно на две недели в Тайланд.
Совпадения с реальными событиями случайны, если что ;-)
И во-вторых, я за свою жизнь встретил среди сотен разработчиков только трех, кто реально архитектор и сразу проектирует, как нужно. Такой архитектор пишет на любом языке, виртуозно владея несколькими, и вполне понимает, что язык, tdd и методологии — просто инструмент, которым нужно пользоваться с умом, и может и говнокодом накидать для проверки идеи, и круто написать реализацию уже рабочей стратегии.
Большая же часть рефакторит не то, нет так, как надо, и не тогда, когда надо. В php примером является ранний мегасвязанный zend, когда ООП ради ООП, и на простые операции 100500 вызовов функций плюс сверхвысокая связанность. Неплохим являются слабо связанные компоненты symphony2, но и там есть некий overengineering.
Сегодня я даю своим программистам время на рефакторинг, так как сам вырос в менеджера проектов из ведущего программиста (в прошлом прикладное ПО, затем web development).
Потому что помню о техническом долге и стремлюсь его уменьшать.
Завершу словами песни из 17 мгновений весны: «а в общем, нужно просто помнить долг от первого мгновения до последнего».
Желаю всем времени на рефакторинг и нужных скиллов!
Автор: Cord
