В своей колонке программист Павел Вейник рассуждает о том, как мир разработчика и «красивого кода» пересекается с миром заказчика и бизнеса.
Один разработчик говорит другому: «Как думаю — так и пишу». А тот ему отвечает: «Фу, как животное!».
Эту формулировку — «как животное» — произнёс один умнейший человеком, и она оказала на меня огромное воздействие. Сакральный смысл в том, что надо не только «думать и писать», но и думать, как ты думаешь — анализировать свой способ думанья и улучшать его, чтобы это отражалось на твоём коде.
В связи с этим хочется поговорить о том, как мир разработчика и кода, каким я его себе представляю, стыкуется с миром заказчика и бизнеса — и что при этом происходит. Оговорюсь: это моё полнейшее субъективное имхо.
Два полюса: красивый код vs кровавый говнокод на костылях и распорках
Вот чему учат разработчиков: код должен быть красивый, правильный, поддерживаемый, написанный по чётким и понятным критериям, начиная от правильно расставленных скобочек и заканчивая шаблонами проектирования.
Как противовес всей этой красоте существует говнокод. Вроде как рабочий, но некрасивый, крайне непонятный, сделанный через одно место, с костылями и распорками, его тяжело поддерживать, нереально править и вообще проще переписать с нуля.
У каждого есть свой пример самого страшного кода, когда-либо встречавшегося на пути. В моём случае это аутсорс-проект на Apache Wicket, который мне пришлось поддерживать несколько месяцев. В нём глубина вложенности анонимных классов была 5-7 уровней по всему проекту. Чтобы исправить баг на 4-5 уровне вложенности, нужно было или рефакторить буквально весь проект, или создавать ещё один уровень вложенности, увеличивая количество говнокода и его «ужасность». Разумеется, времени на наведение красоты не было вообще. Страдая и истекая кровью, я плодил и умножал говнокод.
Напротив, как пример красоты и правильности можно вспомнить код Unix ещё из универа. Он написан давным-давно, но настолько просто, расширяемо и удобно, без сумасшедших алгоритмов (в большинстве случаев), что даже сложные вещи более-менее просто реализуются. Главное, понять концепцию.
Общий расклад такой: на одном полюсе — красивый код, на другом — кошмарный говнокод в кровавом энтерпрайзе, а посередине — все проекты, которые вообще пишутся.
Причины появления «костыльных» проектов: хотят ли разработчики писать говнокод?
Странная ситуация: все разработчики говорят, что они обеими руками за красивый код. Я не видел ни одного разработчика, который бы сказал: напишу-ка я говнокод! Разве что в случае форс-мажора иногда сокрушаются: ух, блин, придётся поставить костыль, но как только дойдут руки — мы его красиво сделаем. Грамотный, хороший код — чёткая ценность любого разработчика.
Как же получается, что при таком отношении разработчиков к красоте кода (по крайней мере, именно оно декларируется) редко удаётся найти действительно красивый проект без говнокода? В чём секрет?
Говнокод всегда появляется по каким-то причинам.
Во-первых, контекст кода. У проекта, в рамках которого пишется код, всегда есть деньги, сроки, влияющие персоны (заказчик, постановщики, участники, включая жену или девушку разработчика), каждая из которых тянет проект в свою сторону, иногда — очень сильно тянет.
Во-вторых, разработчики, особенно в больших проектах, бывают даже не знакомы между собой. Обмен информацией о коде между программистами зависит от того, как в целом налажены информационные потоки в компании. А если вдруг над проектом работают две конкурирующие команды, каждая из которых хочет быть круче, то весь проект может развалиться на два нестыкуемых куска. Впрочем, это не такое уж страшное ограничение: разработчику всё равно проще договориться с другим разработчиком, чем с постановщиком задачи или с кем-то ещё. Поэтому давайте вернёмся к контексту кода.
Контекст кода: нужен ли красивый код менеджеру?
Представим обычный среднестатистический для Беларуси проект. Это аутсорсный проект, часто с legacy-кодом, который нужно развивать и поддерживать. Такие проекты никто не любит — все хотят писать с нуля и красиво. Но поскольку с нуля и красиво не получается, проект обрастает поправками, костылями, огрехами, со временем они наслаиваются.
Поэтому разработчики любят рефакторить код, исправляя старые огрехи и делая код красивее. Однако чаще всего на это банально не хватает времени.
Что думает менеджер, когда разработчик просит у него три дня на рефакторинг? Ага, команда с азартом потратит три дня (а раз разработчик сказал 3, то бери шире — все 5-6) на непонятно что, не добавив в проект нового функционала. При этом проект превратится в terra incognita: я не буду знать, какие проблемы в нём остались, какие исправлены, а какие прибавились, — его придётся заново исследовать. Более того, мне придётся как-то объяснять эти изменения ошарашенным влияющим персонам.
Ладно, всё это можно пережить. Но кое-что пережить нельзя: у проекта есть сроки, которые и без того нередко срываются, а эти ребята хотят сорвать их окончательно. Нет, мало ли что хотят эти разработчики! Лучше-ка я не дам времени на этот мутный рефакторинг и поставлю задачи поважней: пусть баги исправляют и фичи добавляют. А там, глядишь, и проект закончится. Как-нибудь проживём.
В связи с этим разработчики поумней просто завышают время на каждую задачу и — как часть задачи — делают рефакторинг. Это в целом неплохая практика. Все задачи слегка растягиваются, проект потихонечку улучшается, и все более-менее довольны.
В позициях разработчика и менеджера по этому вопросу виден чёткий и явный конфликт: между красотой кода и скоростью/стоимостью разработки. К слову, Unix писался долго, разными людьми, без ограничений по ресурсам. Просто мечта разработчика! Вообще-то, есть примеры проектов без ограничений по ресурсам, не менее ужасных, чем любой говнокод.
Just business: нужен ли красивый код заказчику?
Попробуем подняться на ступень выше, над разработчиком и менеджером.
Как правило, есть структура — компания, организация, государство, которой нужна некая программа. Как ни удивительно, этой структуре всё равно, как внутри работает код. Они его никогда не увидят — главное, чтобы код решал задачи. Если они поумней и поадекватней, то готовы смириться с небольшим количеством ошибок. Им главное заплатить поменьше денег за работающую систему автоматизации, которая опять-таки будет экономить их деньги.
Яркий пример: проект, который запомнился мне в качестве самого страшного говнокода в моей жизни, был коммерчески успешен.
Резюме: удобные ботинки первичнее красивых
Итак, разработчики зажаты между Сциллой и Харибдой: сроками и внутренним желанием писать красивый код. Чем больше давление в части сроков, чем больше проблем во внутренней организации разработки, чем больше изменений в процессе работы над проектом, — тем больше говнокода.
Часто не слишком опытные разработчики, особенно в больших проектах, грозятся «убить того, кто написал такой код». Это означает, что они не поняли те нюансы и ограничения, в которых работал автор «говнокода». Ведь он был такой же, как они, — одержимый желанием написать нечто разумное, доброе, вечное. Чаще всего не его вина, что он оказался в ситуации, когда это нереально.
Пятиминутка иронии: тот, кто громче всех кричит про говнокод, периодически и сам пишет говнокод, а иногда ещё и не отдаёт себе в этом отчёта.
Важный момент: разработчики нередко ставят красоту кода выше бизнес-нужд, а это совершенно неправильно (замечаю такое и за собой). Если ты мастеровой и шьёшь ботинки, прежде всего они должны быть тёплые, удобные, по мерке и в срок, а уже потом — с использованием самых лучших приёмов простёгивания кожи, непременно крокодиловой.
Красота красотой, но есть вещи более важные.
В этом и заключается культура кода: сначала разработчик должен сделать работающую вещь по заказу — а потом уже, если у него хватит умений, времени, пороху и прочего, сделать эту вещь красивой изнутри.
Ну а идеальный случай, когда грамотные разработчики пишут красивый код для адекватных заказчиков и укладываются в сроки, — это то, к чему все стремятся. И я тоже стремлюсь. И у меня тоже не всегда получается. По правде сказать, чаще не получается.
Публикация подготовлена при участии Натальи Провалинской
*Мнение колумнистов может не совпадать с позицией редакции.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.