Не нажимайте просто "Одобрить"
Проверка кода - это клей любой эффективной команды разработчиков программного обеспечения. Обзор кода - это этап, на котором инженер просит внести свои изменения в основную ветку разработки. Во время проверки кода другие товарищи по команде и высшее руководство могут комментировать и предлагать изменения в ваш код с помощью систем контроля версий, таких как Git и GitLab.
Анализ кода - это переломный момент, когда изменения отдельного инженера превращаются в общий вклад команды в создание центральной базы кода.
Самая важная часть обзора кода находится в рамках этого перехода. Проверка кода начинается с индивидуального владения одним или двумя разработчиками и заканчивается коллективным владением. После объединения этого кода любые будущие ошибки или проблемы не будут проблемой отдельного человека - это проблема команды.
В эпоху полностью удаленных технологических команд проверка кода важна как никогда. Чрезвычайно важно уделить должное время (бонусный совет), чтобы просмотреть код товарища по команде. Команда, у которой есть эффективная проверка кода, получает преимущества, связанные с соблюдением отраслевых стандартов, более быстрым привлечением новых разработчиков и созданием надежного программного обеспечения, и это лишь некоторые из них.
При всем вышесказанном, компетентность в проверке кода критически важна для того, чтобы стать опытным инженером-программистом. Если вы похожи на меня и слишком часто просто нажимаете «Утвердить», то пора нам собраться вместе и выучить пять правил для каждой проверки кода!
1. Всегда делитесь своими мыслями
Как бы очевидно это ни звучало, вы должны критически осознавать свои мысли, когда участвуете в проверке кода. Если вы новичок и не понимаете, что делает код, вы должны выразить свое недоумение. В этой ситуации вы можете связаться со своими товарищами по команде через свою систему обмена сообщениями, прежде чем комментировать запрос на слияние.
Однако я также видел, как бесчисленное количество старших разработчиков неоднократно просили разъяснений. Решение может быть таким простым, как добавление комментария для некоторой манипуляции с байтами, или оно может включать в себя полный рефакторинг алгоритма. Это должно иметь смысл для команды.
Представьте, что все старшие разработчики в вашей компании решили, что они ничего не скажут, если не поймут код в мерж-реквесте. Это был бы полный кошмар! Вот почему так важно - особенно для младших разработчиков - высказать свои мысли. Если вы никогда не спросите, вы никогда не узнаете!
Независимо от результата, неплохо показать свое замешательство. плохо оставлять свое замешательство без ответа.
2. Понять критерии приемки (AC)
Это правило действует двояко. Во-первых, вам, очевидно, нужно знать цель и задачи мерж-реквеста. Во-вторых, вам необходимо понять, насколько эти цели достигаются благодаря внесенным изменениям. Когда дело доходит до понимания AC, все сводится к детализации каждого уровня абстракции.
Первый шаг, который вы могли бы предпринять, чтобы понять AC, - это просмотреть билет, связанный с запросом на слияние. Оттуда в заявке должны быть описаны общие цели и детали реализации.
Если вы являетесь автором MR, вы можете оставить дополнительную информацию вместе с любыми ошибками в описании вашего мерж-реквеста. Может быть, вы даже зайдете так далеко, что оставите свои собственные комментарии на своем MR для любых запутанных фрагментов кода, что упростит жизнь вашим товарищам по команде!
И наоборот, если вы просматриваете MR, не менее важно понимать AC. Хотите знать, что не помогает понять код? Просмотр списка изменений в GitLab. Вместо этого опустите саму ветку и поработайте с новыми изменениями. Поэкспериментируйте, запустите тестовые примеры или проверьте, не занимает ли база кода необычно много времени для создания или выполнения. Если вы обнаружили что-то не так или запутались, обязательно оставьте комментарий в обзоре кода и следуйте правилу №1.
3. Делайте изменения как можно меньше
Лично меня ужасно удручает открытие мерж-реквеста, содержащего более 1000 строк кода. Никто из вашей команды не будет просматривать столько кода - точка. В идеале ваш MR должен содержать от десяти до 100 строк кода.
Хотя поначалу это может показаться пугающим, есть практические шаги, которые могут помочь в краткой проверке кода. Первый шаг - убедиться, что ваш .gitignore файл в порядке. Этот файл предупреждает систему контроля версий Git обо всех файлах, которые следует игнорировать. Они могут иметь отношение к вашей IDE или основываться на зависимостях, возникших в результате использования веб-фреймворка, такого как Angular.
Вот репозиторий полезных .gitignore шаблонов для вашего удобства:
Еще один совет, который вы можете сразу использовать, - продвигать ежедневные обзоры кода. Если вы используете GitLab, вы можете изменить заголовок своих MR, чтобы начать с «WIP» (незавершенная работа) или «черновик». Это позволяет вашей команде начать изучать и комментировать изменения вашего кода, но с ограничением, заключающимся в том, что вы не можете выполнить слияние в нужную ветку.
Ежедневные обзоры кода повышают осведомленность вашей команды об изменениях, которые вносятся каждый день. Это позволяет вашей команде избегать гигантских проверок кода, когда никто не знает, что происходит, и способствует большему общему коллективному владению и пониманию ваших кодовых баз.
4. Сделайте стандарты команды понятными
Вы знаете, использует ли ваша команда camelCase или underscore_case для Angular (это camelCase)? Вы знаете, есть ли ограничение на функциональную строку для облегчения тестирования? Каков минимальный порог покрытия кода? Есть ли место для общей функциональности и кода?
Предполагая, что вы являетесь частью команды, вы должны знать ответы на эти и многие другие вопросы. Лучше всего, если у вашей команды есть специальное место для документирования стандартов, когда речь идет о передовых методах разработки. Если у вас нет такого документа, предложите изготовить его самостоятельно.
Если вы потратите время на то, чтобы задокументировать стандарты своей команды, вы поможете своим товарищам по команде конкретным документом и познакомитесь с передовыми методами работы команды из первых рук!
5. Найдите свой баланс
Проверка кода - непростая задача. Вы должны быть подробно изложены в своих ответах, но не спамить товарищам по команде. Вы должны быть уважительными, но правдивыми. Более того, вам нужно проявлять инициативу, а не реагировать. Проверки кода - это балансирующее действие, когда одни товарищи по команде получают удовольствие от диалога, а другие его ненавидят.
Но, в конце концов, все проверки кода сводятся к владению. После того, как этот код объединен, это код команды, и нельзя обвинять или хвалить кого-то одного. Вам решать, как лучше всего внести свой вклад в процесс проверки кода, но если вы будете следовать любому из этих правил, приведенных выше, первое правило - всегда делиться своими мыслями - должно быть вашим главным приоритетом.
Так что в следующий раз, когда вы будете заниматься проверкой кода, задавайте вопросы. Если у вас нет вопросов, предложите предложения или даже похвалите чей-нибудь код. Я знаю, что всякий раз, когда кто-то оставляет отзыв (хороший или плохой) о моих запросах на слияние, это заставляет меня чувствовать себя намного лучше, чем отсутствие отзывов вообще.
Заключение
Надеюсь, вам понравилась статья и вы узнали новый совет для собственных обзоров кода. Если вы нашли что-то проницательное или у вас есть какие-то ежедневные практики, которые вы применяете самостоятельно, я рекомендую вам оставить комментарий ниже!
Спасибо за прочтение.
