Решил разбавить тематику и написать что-то вроде справочника, на который всегда можно дать ссылку и обновить. Некоторые вещи лучше не внедрять без объяснений. Нельзя сказать, завтра вы будете применять agile, парное программирование, tdd, так как это делают все крутые ребята.

Я не могу работать без код ревью, также как и писать код без тестов. Если из описания вакансии следует, что ребята не пишут тестов, не имеют практики проведения код ревью, мучаются с svn и так далее, я моментально закрываю страницу.

Причин такого “неадекватного” поведения несколько, попробую хотя бы половину вспомнить и перечислить.

Саморазвитие

Невозможно саморазвитие в индивидуальном творчестве. Теорию черпать можно от соседа или книжек. Практика хорошо улучшается, когда тебя критикуют другие, и когда ты смотришь чужой код. Так исчезают собственные помарки, и ты невольно перенимаешь что-то лучшее от соседа. Иначе ваш профессионализм превращается в самолюбование. Никто и никогда не скажет и не спросит: “что за гавно? что за ерунда написана? какой баран это написал?”. Да и если вы, глядя случайно в чей-то код, такое кричали, это не означает, что от вас мусора меньше, неправда ли?

Знание проекта

Знание проекта, того что в нем происходит, не проходит мимо тебя. Ты знаешь, что делает или сделал сосед. Иначе, можно дать просто права на push всем участникам, и каждый будет писать свой проект. Если вам не повезет, и каждый из участников проекта делает индивидуально большой кусок кода от 0 до 100 процентов, то через полгода вы не сможете вернуть свои глаза на место при необходимости внести даже небольшие изменения. Это равносильно тому, что программиста с улицы взять и посадить писать код. Будут только вздохи, охи, ахи, периодическая ругань. Одни эмоции и переживания, никакого кодинга. Возможна и другая ситуация, что вы железный дровосек без сердца, и можете только рубить лес от точки А до точки Б, не задумываясь о том, зачем этот лес посадили, и почему вы вырубаете именно эту часть леса.

Мы одна команда, одной крови

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

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

Со сложными примерами, когда какая-то логика приложения делается по-разному, результат еще более близок к могиле. Вы либо получаете дублирование кода, либо первый результат в более плачевном виде. Например, кто-то бросает эксепшины, кто-то возвращает true/false, кто-то в строковом виде сообщение об ошибке, четвертый создает методы “черные дыры”.

При код ревью команда самоорганизуется, выбирая те или иные правила, соглашения, best practice, и придерживается их. В результате сам код проекта — единое целое. Его можно теперь разделить по времени: “что мы вот так писали очень давно, были молоыде и не опытные, а вот так еще раньше”. Но невозможно будет сказать, что это Вася гавнокодит так, а это вот Петькина козюлька. Никаких личностей.

Звезда по имени Я

Проходит звездность, приходит профессионализм. Это чаще всего заметно на “новичках”. Всю жизнь ты писал так и никак иначе, а тут тебе на ревью: “что за ерунда?”. Главное правильно отнестись к этому. Через это все прошли, никто не родился архитектором, никто не получил опыт при рождении.

Банальности

В заключении стоит привести какие-то очевидные плюсы:

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

Парное программирование

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

Очень часто, вы что-то прочитаете, услышите, а применить и самому написать некогда. Большая вероятность, что сосед уже это пишет и вам нужно только просто глянуть ;).

Полезные ссылки

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