Холивар проектирования против прототипирования в больших проектах – это палка о двух концах. На одном из которых – консервативные приверженцы махрового энтерпрайза с каскадным (waterfall) подходом “Спроектируй-запланируй-отрисуй-закодируй-протестируй”, на другом – ярые фанаты Agile и всякого там “XP” с идеей “лучший прототип – это быстро сделанный и запущенный проект”.
В рамках этого поста я не буду вдаваться в сравнение ватерфола и эджайла, ибо на эту тему написаны гигабайты статей и книг. Хотя сама по себе распространённость “гибких методологий” уже говорит о том, что с каскадной моделью что-то не так.
Этот пост о другом. Я хочу разобрать конкретные ошибки, страхи и риски, “благодаря” которым ваш вроде-бы-нормальный проект “по эджайлу” начинает попахивать стилем “хуяк-хуяк и в продакшен“.
Для начала, Agile не отрицает проектирование, а переосмысливает его. В частности, методика говорит, что вы можете проектировать только находясь в зоне своей квалификации. Иными словами, если вы пытаетесь спроектировать что-то, для чего у вас не хватает квалификации, что вы никогда не делали, в чём вы не разбираетесь – результат работы через проектирование будет настолько же плох, как если бы вы сразу сели писать код.
Но вы ещё и потеряете время.
Agile пытается донести до вас мысль, что если вы не в силах удержать весь проект в голове – садитесь писать код сразу. Пока у вас голова ещё свежа. Пока у вас ещё есть время.
Более того, с точки зрения достижения бизнес-результата, если у вас есть три месяца на проект – бизнесу всё равно, потратите ли вы первый месяц на проектирование, второй – на дизайн, а третий – на разработку. Или за первый месяц накодите говнопрототип, покажете его фокус-группе, выкинете нахрен и за второй месяц напишете второй, получше. А потом выкинете его и за оставшийся месяц напишете третий, уже совсем хороший и правильный.
С точки зрения бизнеса “3 месяца = результат” в обоих случаях. Но во втором случае – сработается команда, определятся коэффициенты точности эстимэйтов, будут отлажены процессы тестирования и деплоя, вырастет здоровое и полноценное API, приобретётся понимание “как делать не надо”, накопится здоровенная база автоматизированных тестов, заказчик и фокус-группа будут в течение аж двух месяцев щупать вашу поделку, и у вас будет ещё две попытки переделать ключевые моменты.
Поэтому я возьму на себя смелость утверждать, что стремление разработчика к проектированию – ошибочное. И оно базируется на одном главном принципе:
Я не хочу переписывать код.
Один мой коллега, директор веб-студии и матёрая звезда рынка веб-разработки, умудряется нести со сцены фразы типа “разработчики – слуги маркетинга” и не получать за это по морде. Он бы сказал “да кого еб..т, что ты не хочешь переписывать код”, но мы в этом посте будем адекватны и разберём ситуацию по деталькам.
Причины?
Это может быть банальная лень или пресловутый синдром конфигуратора. Для решения этих проблем придумана масса способов, от кнутов и пряников до реально полезных систем мотивации разработчиков. Говоря кратко, если вы ходите на работу не только за деньгами, но и реально хотите сделать что-то крутое и значимое на рынке – оставляйте вашу лень дома.
Попробуем рассмотреть более весомые причины:
Растерянность от отсутствия полной картины проекта. Справедливое замечание, поскольку понимание курса и приоритетов не только добавляет психологической уверенности, но и помогает выстраивать внутренние приоритеты при решении тех или иных техологических подзадач в рамках одной поставленной задачи. Лечение – открытость, коммуникация, готовность объяснить “странные” моменты, логичность и последовательность в принятии решений, простые наброски блок-схем (скетчи?), всё что угодно – что позволит всем представлять конечную цель хотя бы в общих чертах.
Страх внесения изменений в продакшен. Строго говоря, никаких внесений изменений в продакшен не должно быть, а должна быть процедура деплоя с миграциями. Обязательно должен быть ряд тестовых стендов, имитирующих продакшен в девелоперской среде. Не экономьте на виртуалках – их у вас должно быть десятки. Не экономьте на процедурах – внедрение изменений и их откат должны быть автоматизированы. Изучите и применяйте системы менеджмента окружений.
Страх лавинообразных изменений. Иными словами, необходимость внесения одного изменения “в 100500 мест в проекте” означает, что вы на начальном этапе не вынесли этот кусок в подключаемый модуль. Используйте модульную структуру, используйте SOA, используйте что угодно из доступных вам инструментов чтобы менять “что-то” только в одном месте.
Страх хаотичности API. Я неоднократно наблюдал, как разработчики пытаются согласовать API на бумаге, чтобы заранее раз и навсегда утвердить протокол. Во-первых, это само по себе утопично, а во-вторых перед вашими глазами лежит проверенная годами технология. Откройте документацию по автоматизированному тестированию (например phpunit) и вы увидите там моки и стабы (mock и stub). Авторы потратили несколько страниц, чтобы донести вам простую мысль – не надо охватывать всю систему целиком. Тестируйте кусочки, заткнув заглушками все коммуникации с остальными узлами. Вам остаётся только осмыслить и применить этот паттерн к процессам разработки.
Страх потери обратной совместимости. Поскольку раньше мы уже выяснили, что при неограниченном росте сложности проекта наступает пороговая планка, когда даже самая продуманная документация не может являться гарантией от факапов, – вместо борьбы со следствием попробуйте бороться с причиной. Изучите паттерны “горячей замены кода” – всё хорошее уже давно придумано за вас. Как только вы поймёте, как в конкретно вашей архитектуре “на ходу” заменить кусок проекта, чтобы бизнес-процессы тестовых пользователей обрабатывались “по-новому”, а всех остальных пользователей “по-старому”, страх просто перестанет существовать.
В заключение:
Индустрия разработки ПО движется к тому, что самый “эффективный” (дешевый, быстрый, удобный) способ проектирования – это прототипирование путём написания кода. Написать код – дешевле, чем рисовать и утверждать макеты дизайна. Его проще поддерживать, чем перерисовывать бумажные схемы. Он всегда актуален и делает ровно то, что делает, в отличие от регулярно устаревающей документации. В него дешевле вносить изменения, чем в любые другие вещи. Если у вас не так – это повод задуматься об эффективности ваших инструментов.
Рабочие прототипы и принципы JFDI – это не гонка и не говнокодинг, а трезвый и взвешенный подход к достижению результата в жёстких условиях. В современном мире, где успешность вашего проекта определяется не документацией, утверждёнными макетами дизайна и бэклогом, а обратной связью (фидбэком) от ваших клиентов и потребителей, единственным способом “сделать успешный проект” является его сделать.
Никакой инвестор не подпишется под сухой пачкой документации, но будет живо заинтересован поговорить с фаундером, у которого есть активная команда, работающий прототип, живая аудитория и внятная модель монетизации. Это – ключевые факторы успеха. Поэтому методики и технологии, помогающие вам этого достичь, должны быть ведущими в вашем проекте.