Были ли вы когда-нибудь в ситуации, когда вас просили пересмотреть код проекта, в котором почти не было руководящих правил или принципов? Летят искры, разбиваются сердца, и оправдания летят в вас, как пули. Вы рискуете создать мелодраму малой интенсивности. Как сторонний наблюдатель, даже если вы вежливы, вежливы и проявляете понимание, вы не можете провести обзор кода, не вызвав некоторого уровня негодования, и да - предлагая некоторые ужасные переписывания кода. С одной стороны, у вас есть менеджеры и заинтересованные стороны, которые взволнованы тем, как продукт будет достигать новых высот, а с другой стороны, у вас есть код, который не позволяет продукту развиваться.

Скорее всего, ваши предложения никогда не будут реализованы, потому что:

  1. Это ставит под сомнение фундаментальную предпосылку, на которой они построили код, и потребует неоплачиваемых трудозатратных усилий, чтобы переопределить его в соответствии с вашими правилами.
  2. Команда не в настроении соглашаться с вами, потому что их интеллект был поставлен под сомнение.

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

Проверка кода происходит только в том случае, если код соответствует определенному условию пригодности для проверки кода. Без этого начального условия проверка кода требует серьезных изменений в структуре кода и становится трудоемким делом. Если вы не можете просмотреть код за 1/20 от того времени, когда разработчик его написал, то это становится церемонией, которой нет места в проекте.

У меня очень простое правило: взглянув на код всего за 30 секунд, если я не понимаю бизнес-цели кода, я не проверяю его, пока код не будет переписан на проясните намерение.

Вам нужны не подробные стандарты кодирования, а соглашение об уровне качества кода.

Соглашение об уровне качества кода (CQLA)

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

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

Он должен иметь максимум 3 уровня предварительных условий, на которых код может быть отклонен для проверки.

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

Преимущества соглашения об уровне качества кода

Устанавливает планку, которую можно поднять

При проверке кода может показаться, что вы застряли во временной петле, и одни и те же проблемы возникают снова и снова. По мере того, как проект прогрессирует, и команда становится все более зрелой, планка пригодности Core-Review может быть повышена путем расширения или редактирования CQLA. Вы не будете зацикливаться на черных вещах в коде, и внимание будет все больше и больше смещаться в сторону качества на более высоком уровне и повышать уровень мышления команды.

Команды перестанут думать в терминах технологий и больше об организации кода.

Делает процесс антихрупким

Мы делаем ошибку, потому что думаем, что правила, которые мы устанавливаем для команды или проекта, будут работать и для других команд и проектов. CQLA делает процесс проверки кода адаптивным. Он учится на ошибках и динамике команды. Он становится сильнее с каждым циклом.

Придает смысл проверке кода

Чтобы анализ кода был значимым, контекст должен быть установлен в начале. Без контекста проверка кода подобна прыжку с парашютом в зону боевых действий.

Разработчики очень бережно относятся к своему коду и защищают его. CQLA не разрушит стены, но, по крайней мере, поможет вам и разработчикам наводить мосты через стены друг друга.

Сокращает время, необходимое для проверки

Компании-разработчики программного обеспечения изо всех сил пытаются найти время для разработки. Блокирование большого количества драгоценного времени для простого просмотра кода становится практически невозможным.

Если код не может быть рецензирован за 1/20 от того времени, когда он был написан, то это становится церемонией, которой нет места в проекте.

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

Как рецензент вы растете вместе с командой и проектом

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

CQLA добавляет чувство причастности к команде. Это дает им почувствовать себя партнерами в построении процесса.

Рекомендации CQLA: ожидайте, что они будут проигнорированы

Что вы делаете, когда разработчик неоднократно нарушает правило? Найдите причину этого. Скорее всего, разработчик понимает правило, но не может применять его в ситуациях реального времени. Остановите проверку, еще раз объясните правило и причину, по которой его следует соблюдать, и попросите разработчика проверить наличие таких экземпляров и вернуться с улучшенным кодом.

Ведите еженедельный подсчет отказов. То, что нельзя измерить, нельзя улучшить. Часть ответственности за каждый отказ также ложится на рецензента.

Рост за счет отказов

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

Заключение

Анализ кода должен быть рассчитан на долгосрочное развитие. Мы должны смотреть на проверку кода не как на застойную деятельность, а как на то, что со временем поможет улучшить возможности команды по кодированию и проверке. Проверка кода должна помочь команде понять, что код написан для людей, а не для компьютеров. С каждым поднятием планки достоинства Code-Review появляются новые вещи, требующие внимания, и на них можно сосредоточиться.