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