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

Рецензирование кода

Маттиас Карлссон

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

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

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

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

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

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

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

Пиши код с умом

Йехиль Кимхи

Попытки доказать корректность программного обеспечения вручную приводят к формальному доказательству, которое длиннее самого кода и содержит ошибки с большей вероятностью, чем сам код. Желательно применять автоматизированные средства, но это не всегда возможно. Ниже описывается срединный путь: полуформальное доказательство корректности.

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

Фрагменты следует выбирать таким образом, чтобы в конечной точке блока состояние программы (а именно счетчик адреса команд и значения всех «живых» объектов) удовлетворяло простому в описании свойству, а функциональность этого фрагмента (преобразование состояния) легко описывалась в виде одной независимой задачи. Соблюдение предложенных правил упрощает ведение доказательства. Такие свойства конечной точки фрагмента обобщают понятия пред-условий и пост-условий для функций, а также инвариантов для циклов и классов (в отношении экземпляров классов). Необходимо стремиться, чтобы фрагменты как можно меньше зависели друг от друга, что облегчает доказательство и очень пригодится, если предполагается изменять эти фрагменты.

Многие хорошо известные (хотя и, видимо, реже применяемые) и имеющие статус «качественных» практики написания кода также облегчают проведение доказательств. Таким образом, одно лишь намерение провести в будущем доказательство корректности своего кода способствует улучшению его стиля и структуры. Не стоит удивляться, что большинство подобных практик проверяется статическими анализаторами кода:

• Избегайте операторов goto, потому что они создают сильную зависимость между фрагментами, разнесенными в коде.

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

• Область видимости каждой переменной должна быть наименьшей из возможных. Например, локальный объект можно объявить непосредственно перед первым использованием.

• Делайте объекты неизменяемыми (immutable), где это возможно.

• Улучшайте читаемость кода посредством пробелов — как горизонтальных, так и вертикальных. Например, выравнивайте отступы для родственных структур и разделяйте фрагменты кода пустыми строками.

• Пишите самодокументируемый код, выбирая содержательные (но достаточно короткие) имена для объектов, функций, типов и т. д.

• Если фрагмент оказывается вложенным, превратите его в функцию.

• Каждая функция должна решать единственную задачу и быть короткой. Ограничение длины функции 24 строками, введенное много лет назад, по-прежнему действует. Размер и разрешение экрана по сравнению с 60-ми годами прошлого века увеличились, но человеческие возможности восприятия остались прежними.

• У функции не должно быть много аргументов (хорошая практика — не более четырех). Это не ограничивает объем передаваемых функции данных: объединение родственных аргументов в одном объекте локализует инварианты объекта, что упрощает доказательство в плане проверки согласованности и состояний объектов.

• В общем случае каждая единица кода, начиная с фрагмента и заканчивая целой библиотекой, должна иметь ограниченный интерфейс. Сокращение потока информации упрощает доказательство. Это означает, что следует избегать методов, возвращающих внутреннее состояние (getters). Нужно не запрашивать у объекта информацию для обработки, а требовать, чтобы он выполнил работу с той информацией, которая у него уже есть. Иными словами, инкапсуляция — это ограниченные интерфейсы, и только они.

• Чтобы сохранить инварианты класса, следует избегать методов, присваивающих значения (setters). Они часто влекут нарушение инвариантов, определяющих состояния объекта.

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

Комментарий о комментариях

Кэл Эванс

На моем первом занятии по программированию в колледже преподаватель выдал нам по два бланка для составления текста