Объём кома грязи в программном коде напрямую влияет на снижение скорости разработки, увеличение количества внеплановых дефектов, увеличивающееся отставание от графика работ и снижение мотивации у разработчиков. Но признавать это как вескую причину никто не торопится. Продолжают говорить о чём угодно — о плохих коммуникациях в проекте, о недостаточном планировании (задачи не двигаются, план смещается ежедневно и это нужно фиксировать). Казалось бы — почему?
Начало истории в "Почему Code Review никому не нужно? Часть I"
Да потому что в программный код особо никто не лезет, кроме разработчиков, никто его не читает и не понимает. А проект при этом всё равно срывается. Начинают искать причину у людей и в самих людях — опросить людей легче, чем разбираться в самом продукте.
Поэтому не удивительно, что инициатива от Review программного кода начинает идти от самых низов — от самих разработчиков. Но одно дело — инициатива, а другое — реально его начать проводить. И вот здесь, помимо недопонимания значимости чистого кода, появляются проблемы иного характера, которые рассмотрим ниже.
Ревью кода — как и обычная задача — требует выделенного бюджета
Инициативы простого разработчика явно недостаточно, ведь на проверку кода и на исправление замечаний, выявленных в ходе проверки, требуется время. Иногда много времени. А учёл ли кто-то эти трудозатраты в плане разработки? Навряд ли. Когда разработчику проверять чужой код, если со своими задачами постоянно торопят?
А мы вообще уверены, что руководство будет в восторге от таких вот «непрофильных» задач? Да ещё в условиях горящего по срокам проекта или минимального бюджета. Скорее всего попросят забить на это и перейти по-быстрее к решению очередной задачи нулевого приоритета.
«А судьи-то кто?»
Так однажды сказала одна их моих уважаемых разработчиц. Мы не можем быть уверены, что нашу деятельность встретят с улыбкой, а замечания поторопятся сию же минуту исправлять. Более того — при опросе разработчиков нашему ревьюверу дадут скорее отрицательную обратную связь, нежели положительную. Как это, например, происходит в самом Яндексе. Потому что ревьювер якобы придирается по мелочам, блокирует поток работ и вообще — оказывает на команду деструктивное воздействие.
«Ревьювер всё за меня сделает»,
- факт, который, к сожалению, остаётся быть реальностью. Если сроки поджимают, ревьювер может не ожидать завершения задачи или исправлений, а сам её довести до конца. Один раз так сделал, другой — и вот, разработчик уже перестаёт напрягаться. А зачем? Ревьювер же сам её доделает, когда срок выполнения подожмёт его по самое не хочу. А все «плюшки» уйдут нерадивому разработчику. Ну разве это справедливо?
В чём тогда мотивация?
Мы рассмотрели уже три фактора, которые могут напрочь лишить желания проводить проверку программного кода. Тогда что же может двигать ревьювера в выполнении его задачи? Это может быть стремление к саморазвитию, получения морального удовлетворения от хорошо выполненной работы, получению опыта в создании надёжных, гибких программных систем. А, может, ревьювер имеет ответственность за реализованный функционал и не хочет работать по выходным и ночам, когда произойдёт очередная авария из-за халатности других разработчиков. В любом случае — это нелёгкая деятельность должна как-то поощряться.
А как думаете вы, что может замотивировать разработчика на проведению ревью кода?
Возможно, будет интересно почитать историю "А кто будет проверять работу аутсорсеров?".