Иван Котов, frontend-разработчик со стажем, сравнивает программный продукт с садом. Почему так? Или, вернее, может быть так как раз правильнее?
Хотелось бы поделиться интересным взглядом на промышленную разработку, которой занимаются программисты. По моим наблюдениям, в сообществе укоренено мнение, что программирование — весьма инженерная затея, и в этом смысле занятие в этой сфере стараются привести в соответствие с терминами, уже принятыми политехническими институтами и многолетней практикой больших и малых инженерных организаций.
И я в чем-то согласен с этой идеей. Но любая аналогия имеет тенденцию перерастать изначальное сравнение и объяснять гораздо больше, чем ей следует. В случае аналогии разработки ПО и строительной разработки (по-английски слова для профессий идентичны — developer) этот эффект особо красочен, на мой взгляд. Это вредно, особенно для начинающих разработчиков: у них создаются обманчивые представления об индустрии и относительно качеств результатов труда и взаимоотношений с заказчиками. Обо всем об этом постараюсь подробнее далее. И как альтернативу предлагаю свое сравнение: программирование сложных систем подобно разбитию сада и ухаживанию за ним. Полезные выводы из этого и являются сутью статьи.
Вначале разберемся с уже упомянутым сравнением со строительной индустрией. Оно действительно существует, стоит начать с самих терминов: в серьезных статьях повсюду мелькают слова “архитектура компьютера”, “архитектура приложения” , так что у студента, а затем у разработчика, в голове образуется четкое понимание того, что итоговый программный код — великое строение, которое вначале тщательно проектируется, потом строится, вводится в эксплуатацию, а затем обслуживается (если повезет). Так и появляется стандартный процесс разработки по-умолчанию, обозначаемый как “водопад”, т.е. последовательность шагов, после которых результат достигнут. То, что эта методология давно считается весьма ограниченно годной и то, что повсеместно процветают agile процессы, заставляет задуматься: вероятно, концепция строительства имеет небольшое отношение к программному обеспечению.
А вот сравнение с садоводством кажется весьма полезным, при таком подходе можно предугадывать некоторые следствия, и идеал работы программиста не столь разочаровывает при столкновении с реальностью. Что же в этой реальности происходит такого?
Во-первых, цикличность. Для садовода ежегодные работы следуют по графику. При этом сад взращивается долгое время, за один год его нельзя привести к какому-то конечному состоянию. Но каждый год в нем происходят одни и те же работы в зависимости от сезона. Разработчик тоже должен иметь в виду, что надо производить работы по улучшению и разработке программы или сервиса с некоторой регулярностью. Можно запланировать весь фронт работ с самого начала, но, как правило, идти к такому идеальному продукту придется слишком долго, а проект с точки зрения бизнеса и сообщества может этого и не выдержать.
Во-вторых, засыхание. Сад умирает без регулярного ухода. Если его забросить, он зарастет сорняками и перестанет плодоносить. Программный продукт тоже весьма скоро становится трупом. При этом исполняемый код замечателен тем, что его все-таки удается запускать не только на оборудовании, но и в эмуляторах, однако попытки использования программ даже десятилетней давности больше похожи на пляски вокруг Франкенштейна. И особенно это касается сложных программных систем, где интеграция разных программ критична для успешного функционирования. Замусоренность любой программы чувствуется даже ее создателем весьма скоро. Спросите себя (или друга-программиста), и наверняка припомнится момент, когда смотришь в код, написанный полгода-год назад, и глаза на лоб лезут: “Стыдоба!” Да, второй закон термодинамики про нарастание хаоса почему-то реализует себя в программном коде тоже. Иногда замусоренность перерастает в захламление, и нет никакой возможности исправить ситуацию, как только переписать проект с нуля. Это все равно, что срубить сад и начать высадку заново.
В-третьих, погода. Никто, конечно, не признается, но внешние условия очень важны для проектов. Какое там настроение у дизайнера, который придумал интерфейс для нашего классного приложения? Смотришь на макеты и понимаешь: вот это гроза, надо налить чая и зажечь камин; сегодня в сад ни ногой. Это не говоря про прочие внешние обстоятельства. Какой навоз фреймворк моден в этом году? Какие цветы сервера продают голландцы на местном рынке? Есть и более аргументированный довод в данном пункте. А именно, Закон Конвея, который говорит о том, что структура компании неизменно влияет на программный продукт, который повторяет систему коммуникации в компании.
В-четвертых, деление на съедобное и красивое. Сады ведь бывают разного толка. Спор между практиками и мистиками происходит во всех сферах деятельности, очевидно: как сад может быть плодовым или цветочным, приусадебным или городским, так может и программный продукт служить совершенно в разных целях. При этом удивительно то, что существование публичных садов аналогично многим продуктам с открытым исходным кодом.
В-пятых, сообщества профессионалов. Садоводы не ищут откровения в книгах по почвоведению (кроме некоторых упоротых, наверно), они работают на земле и делятся практическими соображениями. Так же работает сообщество программистов. Конференции по разработке вовсе не похожи на математические. Более того, они антинаучны по природе: на них критика не в почете, необходимо принятие выступающих. Если не нравится — иди попробуй сделай сам, по-своему, а экспертное мнение уже высказано. Эксперт считается таковым не по числу статей, а по числу лет в индустрии и авторитету среди коллег. Сообщество вводит моду на те или иные приемы, техники, принципы разработки. Так, как будто речь идет про лопаты, тепличные нововведения или мичуринские эксперименты.
В-шестых, любовь к делу. Если человек вкладывает душу в свою работу, это чувствуется. И не во все ее можно вложить. В квартальный отчет или налоговую ведомость вряд ли. А в суп можно, и в любимый палисадник у дома тоже. Увлеченный своим делом разработчик — вовсе не редкий случай, это же для многих единственный вариант творчества, программирование алгоритмов захватывающе. Хотя следует помнить, что это правило не всегда обеспечивает порядочность и общую адекватность специалиста.
И пожалуй, последнее, но очень важное. Это принцип, гласящий, что важнее реализация, а не идея. Прекрасные сады с единорогами и четырехлистным клевером всем задают планку, но реальные парки с обычными дорожками гораздо полезнее горожанам тут, на земле. То, как в действительности будет развиваться сад, зависит не только от автора первоначальной идеи, важны многие факторы. Т.е. реализация как развитие идеи либо доводит ее до улучшенного артефакта реальности, либо превращает в фантик, памятник истории.
Из этого вороха параллей можно выделить более и менее очевидные. Но вряд ли молодой разработчик про все это когда-либо слышал или предугадал. А если бы мог, то сразу же взял на вооружение следующие правила, которые понравились бы и опытному садоводу, я уверен.
Уход и дисциплина
- Надо присматривать за всей системой целиком, править или планировать правки по слабым частям, особенно где уже есть сорняки костыли. И это регулярный процесс.
Существование больших рисков, непредсказуемость
- Стихийные бедствия не идут по расписанию. Риски в сельском хозяйстве самые сильные, именно в этой сфере возникли фьючерсы как гарантии продукции. Не все происходит под контролем, особенно в сложном проекте. И микроменеджмент в командах разработчиков мало уместен.
Красивое бывает сложно продать
- Есть два исключения, противоречащих данному правилу, тем самым его подтверждающие: чудо бума доткомов конца 90-х XX века перекликается с тюльпановым крахом века XVII. Но в целом же, плодовые сады гораздо практичнее, так что они сразу находят покупателя, в отличие от цветочных полян. Аналогично можно встретить программный продукт, который пусть и странно спроектирован, но обладает огромной аудиторией, в то время как грамотные красивые решения остаются в дорожной пыли.
Обмен опытом как часть процесса
- Возможности систем не всегда описаны в сопроводительных документах. Более того, всегда есть место для экспериментов, и услышать их результаты из первых уст полезно для всех участников, это сильно продвигает индустрию в целом.
Эволюционное развитие
- Большой проект не может быть механически поделен на части, он взращивается из малого, точно так же, как дерево вначале прививается, а потом дает плоды. Грубо говоря, программисты ведут проект таким образом, что вначале появляется велосипед, потом скутер, потом уже автомобиль. Теоретически хотелось бы, чтобы параллельно создавались шасси, кузов и двигатель, которые потом совмещались бы. Я думаю, это идеализация, которая мешает жить: на самом деле, эволюция продукта и его технической составляющей всегда на лицо.
Что такое MVP и почему для запуска не нужен $1,000,000: разбираем на примерах
Обновление или инфраструктурная деятельность
- Так или иначе, рано или поздно надо полностью пересматривать концепцию поддержания проекта и сада. Любая инфраструктура имеет свой срок годности.
В заключение все же приведу те полезные следствия, которые получаются из параллели строительства и выстраивания программного кода.
Во-первых, концепция стандартных блоков. В программировании образуются так называемые модули, которые, подобно строительным блокам, могут образовывать некоторую конструкцию.
Во-вторых, технологии в строительстве перекликаются с паттернами и методологиями в программировании. Шаблонное представление о полном цикле технических работ сильно упрощает коммуникацию и вполне облегчает обучение.
В-третьих, для программных продуктов в их реальном широком использовании тоже возникает понятие нагрузки, которую надо рассчитывать точно так же, как рассчитывается нагрузка на строительные конструкции. И эта нагрузка может сильно поменять как устройство программной системы, так и инфраструктуру под нее.
В-четвертых, так же, как и в строительстве, в программной инженерии возникло множество специализаций.
Иногда в компаниях ощущается конкретно строительная атмосфера: они подготавливают блоки для конструкции, снабжают всех разномастных рабочих чертежами и ГОСТами, высчитывают нагрузку и планируют сроки по предыдущему опыту. Но как по мне, такой механический подход не выдерживает критики и реального опыта. То ли творческая составляющая программной деятельности, то ли ее практическая близость к бизнесу, существующему на рынке, как в экологической системе, то ли еще что-то, но абсолютно точно есть в разработке программного обеспечения хаотическое, анархическое начало, вдребезги ломающее идеальные конструкции из нулей, единиц и управляющих языков. Хочется вспомнить Илью Сегаловича, говорившего:
Прогресс неостановим. И второе: работать все равно ничего не будет.