Григорий Петров: Стандарт оформления кода: и не стандарт, и не оформления, и не только кода

Во многих компаниях первый рабочий день программиста начинается с изучения «стандарта оформления кода», он же «стандарт кодирования», «coding standard» или «coding convention». Обычно это монструозный многостраничный документ, в котором подробно описано, как именно принято писать код в компании. Очень подробно.

Составление и правильное использование стандарта кодирования — очень важная задача тим лида. Такой документ может стать мощным оружием в борьбе со сложностью, базой знаний компании и хорошим вводным курсом для новых разработчиков. Это если знать что и как делать. А если не знать, то эта замечательная практика превращается в «карго культ» и, в лучшем случае, игнорируется разработчиками, а если не повезет, то просто вредит работе и команде.

Зачем нужна эта штука

Как я уже писал, над программистами довлеет страшный Кошелек Миллера. Чтобы бороться со сложностью, разработчики тренируют навыки работы с «типовым» кодом. Почти так же, как шахматисты постоянно разыгрывают этюды, чтобы не тратить внимание на их распознавание. Только вместо шахматных позиций разработчики тренируются писать код в определенном стиле, с выбранным набором готовых библиотек и фреймворков. Читая в дальнейшем такой код, они не тратят внимание на известные фрагменты и могут, как шахматисты, фокусироваться на более важных вещах.

В отличие от шахмат, в разработке нет ограничения на размер доски и набор фигур. Десятки языков программирования, сотни фреймворков, тысячи библиотек и подходов к написанию кода провоцируют каждого программиста на изобретение собственного «стиля игры». Стандарты кодирования появились в командах разработки естественным образом, как попытка привести создаваемый код к единому стилю. Первые стандарты кодирования были очень просты и описывали только оформление кода: как называть идентификаторы, сколько табов или пробелов использовать для отступов, куда писать комментарии и тому подобное. Даже такие стандарты приносили огромную пользу: через несколько месяцев привыкания разработчики начинали тратить гораздо меньше сил на чтение и понимание кода, который создали их коллеги.

Со временем разработчики поняли, что сложность кроется не только в том, как код выглядит, но и в том, что он делает. Стандарты кодирования эволюционировали и стали включать в себя не только правила оформления, но и правила написания кода. Современный стандарт кодирования содержит весь накопленный командой опыт о том, как надо и как не надо писать код. Кроме вопросов оформления, он также включает в себя список лучших и худших практик разработки, принятые в команде стратегии для работы с типовыми задачами, список используемых фреймворков, библиотек и многое другое. Особенно в этом плане отличились крупные системные интеграторы и компании по заказной разработке, стандарты кодирования в которых зачастую содержат сотни страниц подробнейших инструкций, фиксирующих вообще все, включая «единственно правильную» версию Java.

Кнут, пряник и учебник под одной обложкой

Стандарты кодирования возникли естественным образом, практика прижилась, доказала свою пользу и теперь используется намного шире, чем просто внутреннее соглашение по оформлению кода. Эти документы является замечательным «внутренним учебником» для введения новых разработчиков в курс дел. Информация в таком документе накапливается постепенно, дополняясь и меняясь вместе с тем, как эволюционирует разработка в компании.

Тот факт, что новые разработчики будут читать стандарт кодирования, позволяет поместить в него не только обязательные для следования правила, но и минимальную теорию о разработке программного обеспечения. Например, кратко изложенные концепции о борьбе со сложностью, о способах ее выноса в разные места и принятых в компании на этот счет практиках.

Высшим пилотажем является составление такого стандарта кодирования, который будет ненавязчиво подталкивать разработчиков в сторону правильных практик создания кода. Для этого хорошо подходит концепция коридоров, о которой я уже писал. Это намного лучше, чем пытаться заниматься микроменеджментом и расписывать на сотне страниц все, с чем потенциально может столкнуться разработчик.

Советы по созданию стандарта кодирования

Каждый разработчик хочет переписать все с нуля, и это естественно. Хороший стандарт кодирования всегда начинается со вступления, где вы рассказываете про сложность, про борьбу с ней, и о том, чем полезен стандарт кодирования. Если этого не сделать, то есть риск быть непонятным, и новый разработчик отнесется к вашим знаниям как к «блажи потерявшего связь с реальностью тим лида». Будет очень обидно, да?

Интегрируйте стандарт кодирования в «onboarding» новых разработчиков. Внимательно относитесь к их вопросам, так как они смотрят на ваш стандарт свежим, «незамыленным» взглядом. Каждый новый разработчик, читающий ваш стандарт кодирования — это возможность что-то улучшить, переписать более понятным языком, внести ответы на часто задаваемые вопросы.

Разбейте стандарт кодирования на обязательные для исполнения правила; рекомендованные, но не обязательные; и просто рекомендованные. Слишком большой объем обязательных для исполнения правил в клочья разрывает кошелек Миллера новым разработчикам, понижает им удовольствие от работы и способствует возникновению напряженности в команде. Обратная сторона медали — если все правила будут только «рекомендациями», то многие разработчики будут игнорировать их из-за лени. Постарайтесь подобрать баланс между обязательными и необязательными правилами так, чтобы оставить разработчикам свободу творчества, но при этом дать им возможность понимать код друг друга и не изобретать слишком много велосипедов.

Составление и поддерживание стандарта кодирования — задача тим лида. Наблюдая каждый день за работой команды, и читая написанный разработчиками код, он лучше всех видит возможности направить разработку в общее русло. При этом тим лиду не следует пытаться вынести в стандарт кодирования весь свой опыт. В чужие головы свои мозги не вставить, а слишком сложные вещи будут просто непонятны большинству разработчиков со средним опытом и навыками. Лучше всего выделить «ядро» простых правил и подкрепить их автоматикой в виде статического анализа. В такой ситуации разработчик, отгрузивший «не по правилам» написанный код получит автоматический ответ от системы непрерывной интеграции. А героем, сломавшим билд, никто быть не хочет.

Напоследок скажу традиционное. Стандарт кодирования, как и многие другие описанные мною практики — это всего лишь инструмент для решения определенных задач. Только понимание этих задач, а также сильных и слабых сторон используемых инструментов, поможет вам сделать процесс разработки чуть более стабильным и предсказуемым. А там, глядишь, и релизы начнут вовремя случаться.