Комментарии
Говорят, в Царской России, при испытании нового железнодорожного моста под него ставили всех разработчиков, а сверху пускали поезд. Мосты век могли простоять. А разработчик — либо герой, либо — труп. К сожалению, столь действенные меры в наше время утратили популярность.
Code Review, или добавляем контроля
Говорят, в Царской России, при испытании нового железнодорожного моста под него ставили всех разработчиков, а сверху пускали поезд. Мосты век могли простоять. А разработчик — либо герой, либо — труп. К сожалению, столь действенные меры в наше время утратили популярность.
Владимир Завертайлов
Владимир Завертайлов
Красноярский железнодорожный мост. Фото: архив Красноярского края krskstate.ru

Особенно печально в сайтостроительстве. И если с дизайном все более-менее ясно (проблемы и достоинства видно сразу), то с внутренней частью (кодом) сайтов все несколько сложнее. Множество сайтов, написано «на пехепе и майэскуэле» вчерашними студентами, без какой-либо структуры, или наоборот, вопреки ей. Код некоторых, даже популярных, систем управления — кошмарен. А ведь именно на нем учатся будущие web-разработчики. Что же можно сделать, чтобы руководителю web-студии не краснеть за тот код, который отдается заказчику?

Один из методов повышения качества, которое мы взяли на вооружение, называется Code Review (инспекция кода, ревизия кода). Давайте попробуем понять, когда и как принимать эту витаминку радости и счастья.

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

1. На каких проектах это оправдано?

Исходя из моего опыта, делать Code Review имеет смысл на проектах, продолжительность разработки (программирования) которых превысила 40 человеко-часов.

2. Кто делает Code Review?

Это должен делать самый опытный специалист — тимлид, или проджект менеждер (если он обладает соответствующим опытом). Для выявления типовых уязвимостей, Code Review может так же осуществляться скриптами (у нас не применяется).

3. Сколько это занимает времени?

Увы, но чуть больше чем дохрена. У меня занимает примерно 1-2 часа вычитать недельный код команды из двух человек. То-есть примерно полтора процента от затрат на программирование. Сколько времени займет устранение того, что найдено — заранее сказать сложно. В запущенных случаях может потребоваться день-два (а это уже 10-12% затрат).

4. Когда этим заниматься?

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

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

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

5. Когда это выгодно?

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

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

В-третьих, анализ кода позволяет выловить и пресечь «велосипедостроение».

6. Что делать после Code Review?

Это тоже очень щепетильный и непростой вопрос. Допустим, вы закончили проект, все работает, но Code Review показал, что нужно, скажем, еще неделю на полировку кода. Как быть? Заказчик за это дополнительно не платит, времени обычно лишнего нет. Приходится идти на компромисс, с надеждой на то, что в следующий раз разработчики не допустят ляпов, который были найдены сейчас. Обычно мы исправляем только на часть задач из Code Review, а остальные — принимаем к сведенью.

7. Что позволяет выловить Code Review?

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

8. Когда Code Review НЕ НАДО делать?

Code Review по сути противоречит краткосрочным бизнес-целям web-студии. Явной прибыли он не приносит, а время кушает порядочно. Нафиг он не нужен на коротких проектах, типа «натянуть дизайн на Joomla». Нафиг он не нужен на проектах, где критична скорость запуска, а не чистота кода. (Например стартап: делаем быстро грязный работающий прототип, запускаем. Если идея выстрелила — может быть перепишем красиво (обычно так никогда не бывает). Если нет — зачем время тратить).

Итак, контроль над качеством кода — это проблема. Однако отсутствие контроля — это две проблемы. Мы решили оставить себе одну :)