97 этюдов для программистов. Опыт ведущих экспертов полностью

Все мы научились не жалеть времени на выбор подходящих имен — согласитесь, это приближает наш код к выразительному описанию выполняемых действий и отличает его от простого перечисления шагов. Верстка кода — другая составляющая такой выразительности. Прежде всего необходимо, чтобы вся команда разработки согласилась использовать программу автоматического форматирования для основных конструкций. Собственные поправки в форматирование кода я могу вносить вручную во время кодирования. Если не возникает острых разногласий, команда быстро приходит к общему стилю, «доведенному вручную». Средство автоматического форматирования не в состоянии понять мои намерения (мне ли не знать, я когда-то сам написал такую программу), а мне более важно, чтобы переносы строк и группировка строк отражали смысл кода, а не синтаксис языка. (Кевин Макгвайр[6] вылечил мою рабскую зависимость от средств автоматического форматирования кода.)

Компактный формат

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

Мой друг (непрограммист) однажды заметил, что код похож на стихи. У меня возникает такое же ощущение при виде действительно хорошего кода: каждый фрагмент текста имеет свое значение и помогает мне понять замысел автора. К сожалению, написание кода не слывет таким же романтичным занятием, как сочинение стихотворений.

Проводить рецензирование кода (code review) необходимо. Почему? Оно повышает качество кода и снижает относительную долю дефектов. Но вы, возможно, неверно представляете себе, почему так происходит.

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

Возможно, в некоторых организациях действительно необходим такой строгий и формальный процесс, но таких меньшинство. В большинстве же организаций подобный подход контрпродуктивен. Авторы рецензируемого кода словно предстают перед комиссией по досрочному освобождению. Рецензирующим требуется успевать и читать код, и отслеживать все особенности эволюционирующей системы: они могут быстро стать узким местом всего процесса, так что процесс вскоре деградирует.

Рецензирование кода должно быть не просто методом исправления ошибок в коде, а средством распространения знаний и установления общих основ написания кода. Дав другим программистам познакомиться со своим кодом, вы тем самым делаете каждого совладельцем кода. Пусть любой из участников команды пройдется по коду вместе с остальными. Не нужно искать ошибки; при рецензировании кода нужно стараться изучить его и понять, как он работает.

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