Code Review, или добавляем контроля

Красноярский железнодорожный мост. Фото: архив Красноярского края.

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

Особенно печально в сайтостроительстве. И если с дизайном все более-менее ясно (проблемы и достоинства видно сразу), то с внутренней частью (кодом) сайтов все несколько сложнее.

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

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

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

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

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

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

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

Я встречал рекомендации делать Code Review непосредственно после реализации каждой новой фичи проекта. Такой подход имеет три больших недостатка:

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

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

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

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

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

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

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

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