Практика, которой нужно следовать: code review

Марк Чу-Кэролл, PhD в области computer sciences и инженер по разработке ПО, ранее работавший в Google, в одном из постов в своём блоге поднимает тему о важности code review в серьёзной разработке ПО, при этом признавая бесполезность данной практики в отлове багов. Какой на самом деле толк от практики code review и о чём надо помнить, когда вам самим придётся просматривать код ваших коллег в рамках данного процесса, – в свободном переводе небольшой статьи Марка. "Код Google так хорош в первую очередь благодаря code review. Конечно, это не какое-то ноу-хау, code review – идея не новая и давно зарекомендовавшая себя на практике. Но я не знаю другой такой крупной компании, где бы данный метод использовался столь повсеместно и универсально. В Google код для любого продукта, для любого проекта будет проверяться до тех пор, пока не получит положительного ревью. Каждый разработчик должен делать code review. И это не значит, что данный процесс какой-то неформальный и зависит от собственных желаний и устремлений, проведение code review – это универсальное правило серьёзной разработки программного обеспечения. Не просто код продукта, а вообще весь код, любой. На самом деле тут не так много работы, но разница в конечном результате получается значительная. Начнём с очевидного самого понятия code review: вторая пара глаз просматривает код перед тем, как он отправится на проверку на баги. Это наиболее широко встречаемая, упоминаемая и признанная практика code review. Но, по моему личному опыту, польза от code review по нахождению багов достаточно невелика. Подавляющее большинство багов, которые обнаруживаются при подобном просмотре кода, если говорить откровенно, примитивны и очевидны, и сам автор кода с лёгкостью и сам бы нашёл и поправил их за пару минут. А те баги, которые действительно достаточно сложны и требуют времени на нахождение, обычно при подобном code review не обнаруживаются. На самом деле code review несёт больше всего пользы в явлении "социализации" кода. Если вы программируете, зная, что ваши коллеги будут потом просматривать ваш код, вы программируете немного по-другому, нежели обычно. Вы пишете более аккуратный, более организованный и документированный код, потому что вы знаете, что люди, чьё мнение вам важно (а это ваша репутация), будут просматривать ваш код. Без code review вы знаете, что рано или поздно кто-то будет смотреть и разбираться в вашем коде, и это произойдёт не сразу, нет того уровня срочности и вовлечённости вашей команды в вашу работу. Соответственно, и стиль кодирования у вас будет попроще и "под себя". Есть ещё один неоспоримый бенефит от code review. Code review помогает распространению знаний о проекте. В большинстве команд у каждого программиста есть свой ключевой компонент, разработку которого ведёт он и за который, собственно, несёт ответственность. А пока компоненты коллег особо не пересекаются с его кодом, разработчик о них имеет весьма смутное представление. В результате код каждого компонента хорошо знает только один человек. И если такой человек уходит в отпуск или, прости господи, совсем покидает команду, никто толком не знает, что и как реализовано в его компоненте. Используя code review, у вас в каждом случае будет уже как минимум два человека, знакомых с кодом – автор и, так сказать, рецензент-ревьюер. Конечно, последний не знает код в той же степени, что и автор, но понимает структуру и дизайн компонента, что очень важно в случае необходимости быстро разобраться в каком-то вопросе относительно этого кода. Конечно, не всё так просто. Из своего опыта могу сказать, что должно пройти определённое время, прежде чем вы научитесь быстро и качественно просматривать код. На этом пути есть определённые подводные камни, о которые часто спотыкаются неопытные ревьюеры, и, соответственно, у них складывается отрицательное впечатление о данной практике, а неудачи становятся барьером на принятии концепции code review. Самое главное правило code review: вы ищите проблемы в коде перед тем, как он будет закоммичен, ваша цель – корректность кода. Наиболее распространенная ошибка, обычно свойственная новичкам, – это то, что они судят о том, как код написан исходя из своих собственных представлений о решении данной задачи. Для любой проблемы обычно существует добрая дюжина возможных решений, а для каждого решения – миллион вариантов реализации в коде. Ваша работа как ревьюера не в том, что убедиться, что код написан так, как вы бы его написали. Он всё равно таким не будет. Ваша задача убедиться в том, что написанный вашим коллегой код – корректный. И если этому правилу не следовать, само собой разумеется, что все участвующие будут разочарованы, и могут возникнуть даже какие-то обиды, а это уже совсем нехорошо. Возникновение подобной ошибки – явление по своей природе абсолютно закономерное. Вы программист и когда смотрите на проблему – видите решение, и впоследствии во время code review исходите именно из своего увиденного ранее решения. Но забудьте о своём решении, для хорошего code review оно вам не нужно, и вам надо это понимать. Второй основной подводный камень в бурном потоке code review – это чувство обязанности что-то сказать. Вы знаете, что автор потратил много времени и усилий, работая над кодом, и вы же должны ему сказать хоть что-то по коду, не так ли? Нет, не так. Нет ничего плохого в том, чтобы просто сказать "Ок, нормально". Если вы постоянно нацелены на поиск каких-либо зацепок для критики, то тем самым вы только разрушаете собственный авторитет в глазах у коллег. Когда вы раз за разом критикуете только для того, чтобы сказать хоть что-то, люди быстро поймут, что вы говорите всё это только для того, чтобы заполнить тишину, и ваши комментарии независимо от их адекватности не будут впоследствии приниматься серьёзно. А третья проблема – скорость. Не следует торопиться, но нельзя и затягивать процесс. Ваши коллеги ждут вас. И если вы и остальная команда не хотят проводить ревью, и проводить быстро, сама практика просмотра кода приведёт только к всеобщему разочарованию. Code review не должен выглядеть вмешательством в рабочий процесс вроде "а сейчас все всё бросят и будут ревьюить". Нет смысла бросать все дела, если кто-то попросил вас сделать code review. Через пару часов после того, как вы разберетесь со своей задачей, возьмёте паузу для чашки кофе или беседы с коллегами и только потом примитесь за ревью – вы сделаете его и сделаете достаточно быстро. И никому не придётся болтаться без дела в ожидании, пока вы сможете заревьюить код".

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.