Как и многие другие молодые разработчики, я начал свой путь с не связанных с кодированием аспектов моей работы (включая обзоры кода) не на той ноте. Тот факт, что я был под наставничеством мастера кодирования с коротким запалом, тоже не помог.
Однако переход от простого написания кода к полной проверке кода был для меня непростым шагом. Как и любой другой начинающий разработчик, я считал весь процесс пустой тратой времени.
Я больше так не думаю.
За последние пару лет я извлек ряд хороших уроков, касающихся ревью кода. Я действительно считаю, что контекст или специфика моих уроков не имеют отношения ни к кому, кроме меня. С этой целью я избавлю вас от всей истории и перейду сразу к делу.
Вот некоторые вещи, которые я узнал о проверке кода.
Подумайте о подотчетности
Я считаю, что в наши дни многие молодые разработчики используют довольно личный подход к написанию кода и обзору кода в целом. На самом деле нетрудно понять, почему: менеджер проекта поручает мне задачу, я выясняю объем, я провожу исследование , Я смотрю на влияние и я проверяю, я нахожу наилучший из возможных подходов. Так почему же тогда вы просто приходите и «просматриваете» что-то явно продуманное и почти идеальное?
Позвольте мне спросить вас: что, если ваш идеальный фрагмент кода не работает в производственной среде? Что, если 0,001% произойдет и приведет к огромным потерям как с финансовой точки зрения, так и с точки зрения доверия пользователя к системе?
Вы несете единоличную ответственность за эту потерю?
Этот бизнес работает не так. На самом деле (большую часть времени) компания, в которой вы работаете, несет ответственность. Как правило, вы всегда должны помнить: вы несете единоличную ответственность за код, который у вас есть на месте, однако, как только он дойдет до проверки кода, ответственность перекладывается на всю команду. Наконец, когда этот замечательный фрагмент кода попадает в рабочую среду, ответственность за него ложится на саму компанию.
Зная это, я думаю, становится немного легче понять, почему многие опытные разработчики или руководители команд уделяют этому процессу много внимания. Во многих отношениях одобрение проверки кода означает признание ответственности за отправленный код.
Расставляйте приоритеты, но не упускайте из виду
Я думаю, что мы все были в этом. Команда проходит исключительно продуктивный спринт, и количество проверок кода постоянно накапливается. В конце концов наступит день расплаты, когда у вас будет десять, двадцать таких проверок кода. Что теперь?
Ну, во-первых, сделай глубокий вдох и пристегнись. Ты в порядке? Хорошо !
Пора расставить приоритеты. Я знаю, что многие из нас склонны уделять первоочередное внимание собственной проверке кода. Что ж, давайте сделаем шаг назад, посмотрим на картину в целом и начнем задавать вопросы.
Что кажется самым важным для команды?
Что является высшим приоритетом для менеджера проекта?
А как насчет клиента?
Помните, что всегда полезно спросить, если вы не знаете, с чего начать.
Однако приоритет - это только половина дела. Другая половина обращается к игнорированию. Игнорирование происходит, когда некоторые проверки кода всегда остаются в очереди с низким приоритетом. Я не буду вдаваться в подробности, почему слишком долго откладывать проверку кода - плохая практика, но скажу, что это никому не нужно. Во всяком случае, помните: Низкий приоритет не означает ненужность!
Смотрите на код, а не на человека
Если заголовок был недостаточно ясным, позвольте мне быстро распаковать его. Вы являетесь частью команды, независимо от того, являетесь ли вы стажером или старшим разработчиком. В составе указанной команды вы и ваши коллеги работаете над достижением одной цели. Мы все действительно хотим писать чистый код, эффективный код и высококачественный код. Однако я думаю, будет справедливо предположить, что никто не делает это все время.
Это когда комментарии начинают появляться в ваших обзорах кода или, смещая перспективу, это когда вы начинаете писать отзывы о обзорах кода. Помните, что здесь упор сделан на «обратную связь» и «код».
Важно понимать два вышеупомянутых аспекта. Вы не должны проверять или оценивать код на основании того, кто его отправил. Ко всему коду необходимо относиться справедливо, независимо от того, написан ли он стажером или старшим разработчиком. Попробуйте ненадолго отделить эти две сущности (код, лицо), и я гарантирую, что весь опыт станет лучше.
Таким образом вы сможете избежать двух распространенных проблем, связанных с проверкой кода. Во-первых, мы склонны автоматически доверять коду, представленному нашими коллегами, которые, кажется, имеют больше опыта, чем мы, - не очень хорошо. Во-вторых, мы склонны более жестко относиться к коду, представленному нашими коллегами, у которых меньше опыта, чем у нас, что тоже нехорошо.
Самостоятельная проверка
Допустим, вы только что выполнили задачу, проверили ее в последний раз и, наконец, открыли проверку кода. Пришло время двигаться дальше, выпить чашку кофе и перейти к следующей функции. Правильно ? Эм, погоди минутку там.
Я полагаю, мы все заметили, что код в обзоре кода немного отличается от того, над которым вы работали. Во-первых, все эти красивые цвета, аккуратно расположенные отступы и опции быстрой навигации отсутствуют. Во-вторых, большая часть контекста файлов, всего, что связано с вашей функцией, не выделяется при проверке кода. Наконец, вы не помните, что писали так много, не так ли?
Что ж, здесь в игру вступает самопроверка.
Я не против перерывов на кофе, поймите меня правильно. На самом деле, я думаю, вы это заслужили. Однако когда это закончится, давайте еще раз взглянем на код и посмотрим, как он выглядит вне вашей локальной среды. Есть ли в этом смысл? Как вы думаете, размах понятен всем? Вы уверены, что это не вызовет у ваших коллег головную боль?
Будут проводиться обзоры кода, где на все вопросы ответят «да». А как насчет других?
Для всех остальных мы можем предпринять некоторые шаги.
Во-первых, не стесняйтесь добавлять комментарии или пояснения к собственному обзору кода. Вы можете дать некоторое представление о масштабах, попросить обратить особое внимание на некоторые части, объяснить некоторые сложные строки и даже описать процесс принятия решения. Это может занять у вас немного времени, но уверяю вас, оно того стоит.
Во-вторых, прикрепите снимки экрана или соответствующие файлы. Это наиболее полезно, если вы работаете над некоторыми функциями пользовательского интерфейса или внешнего интерфейса. Я думаю, будет справедливо сказать, что у большинства разработчиков нет встроенного в мозг интерпретатора css или html. Наличие наглядного пособия, которое поможет им понять ваш выбор стиля, может сэкономить всем кучу времени.
В-третьих, убедитесь, что вы указали, что некоторые файлы могут быть исключены из процесса проверки. В большинстве современных языков программирования для вас уже есть много готового. Это может быть фактический код миграции или снимок контекста. Это может быть список пакетов или даже несколько отчетов в формате CSV. Целью обзора должен быть написанный вы код, а не созданный на его основе материал. Убедитесь, что вы указали это четко, поскольку иногда это может быть неочевидно для всех.
Это было не так уж сложно, не так ли?
Спасибо за уделенное время. Вторая часть скоро выйдет.
А пока желаю удачного кодирования!