CodeReview – классная штука, не правда-ли? Если отвлеченно подумать об открывающихся возможностях и количестве потенциальных ошибок, найденных при проведении CodeReview, то начинает казаться что практика просто великолепна и мега полезна.
Обычно, путь к внедрению этой практики извилист и тернист, но ништяки, которые по легенде ожидают прошедшего, заставляют забыть о сложной дороге.
Как ни странно, первым делом, обычно, создается стандарт кодирования. Думаю, это вызвано тем что любая уважающая себя компания должна иметь собственный стандарт. В стандарте обязательно нужно прописать где ставить скобочки, а где пробелы, какие индентификаторы писать с прописной буквы, а какие со строчной. Стандарт просто необходимо согласовать, проревьювить раз надцать и утвердить. После этого весь код будет однородным и очень красивым, не зря же стандарт составляли лучшие из лучших компании!
К сожалению, после появления стандарта возникает ощущение незавершенности. Т.е. стандарт вроде и создали, но разработчики положили на него болт. И вот тут, кто-то наиболее начитанный вспоминает магическое слово CodeReview. Причем все понимают что это самое ревью не только охреневших разработчиков на место поставит, но еще и избавит от кривых алгоритмов, защитит от утечек памяти и, как говорят гуру CodeReview даже спасет от Экрана Смерти (ну либо от пиники ядра, это кому как повезет). Осознав все это, просто нельзя не сделать дружного рывка для внедрения столь необходимой практики.
Реализация процесса CodeReview обычно варьируется от компании к компании, но при этом общие черты остаются. Все максимально автоматизируется, на версионное хранилище вешается как можно больше триггеров, разыскиваются наиболее навороченные инструменты. Чисто теоретически, благодаря этому качество кода будет несравненно лучше, а код не соответствующий стандарту кодирования в репозиторий больше не попадет. Разве не прелесть?
Только вот реали, к сожалению, сильно отличаются от теории. Само собой, техническая сторона этого вопроса вносит наименьше количество проблем. Все необходимые инструменты уже написаны, а документацию по внедрению найдет даже ленивый. Проблему тут вносят люди, психологический аспект.
Начинается все с того, что ревьювер неожиданно для себя выясняет что выискивать на ревью реальные проблемы в коде очень тяжело, не всем дано да и тупо влом. А если вспомнить о том, сколько дел ждет… Ведь куда проще заняться поиском опечаток, лишних заголовков, несоответствий стандарту. Тем более что автоматическая система все стерпит, занес туда баг и хорошо, долг-то выполнен. Правда при этом 5-10% рабочего времени ревьювера и автора кода тратится на откровенную херню, но кого бы это волновало? Ведь практика как-бы внедрена, баги есть, и можно даже кого-нить наградить/наказать по результатам. Ну а то что реального выхлопа от этого практически никакого, так в этом участники ревью виноваты и как следствие ответ на один из извечных русских вопросов найден.
Хотя, в одной из компаний где мне довелось работать, я видел нормально поставленный процесс CodeReview. Проходил он потрясающе просто, без каких-либо технических ухищрений, систем контроля и и прочих плодов технического прогресса. Когда возникала необходимость в проведении ревью (например, собирались коммитить критичный код), автор и еще пара разработчиков собирались за одним компьютером и вместе пристально рассматривали новорожденный шедевр. Что интересно процессе обсуждения находили почти все закравшиеся косяки, ведь не будешь же живого человека исключительно неправильно расставленными скобками доставать, он же и нахер послать может. Да и о времени потраченном на ревью жалеть поздно, итак уже оторвался от рабочего места.
Все же основная ошибка, которая допускается при внедрении CodeReview – это игнорирование психологии людей. Общение с человеком напрямую, и заполнение страницы в сети воспринимаются людьми совершенно по-разному. Никогда нельзя забывать об этом.