Будучи младшим инженером-программистом, я всегда просматривал комментарии к обзору кода, чтобы узнать, как стать лучшим программистом. Но когда пришло время попробовать свой первый обзор кода, я понял, что мой опыт не подготовил меня к тому, чтобы быть на другой стороне.
У меня развился тяжелый случай синдрома самозванца, который спускался вниз с вопросами: следует ли мне комментировать эту строку кода или она того не стоит? Должен ли я найти статьи в поддержку каждого комментария? Могу ли я закрыть сайт, одобрив это? Будут ли они ненавидят меня? Ладно, я признаюсь, что довольно быстро закручиваюсь Но поговорив с некоторыми сотрудниками, я понял, что не одинок в своих заботах.
Младшие инженеры-программисты могут быть вовлечены в рецензирование кода с предположением, аналогичным «вы знаете, как читать книгу, так что вы знаете, как написать книгу, что не соответствует действительности», - говорит Джессика Руддер, опытный инженер в GitHub.
Существуют ожидания, связанные с проверкой кода, и этот процесс может вызывать нервы. Итак, я взял интервью у семи других инженеров-программистов, чтобы собрать советы о том, как построить анализ мышления.
1. Подумайте об общем воздействии
Как правило, хороший запрос на удаление (PR) должен затрагивать только ограниченную часть кодовой базы. Однако ограниченная область не должна мешать вам думать об изменении кода в контексте большей кодовой базы.
Найджел Муньос, бывший инженер по стеку в Muse и нынешний независимый инженер-программист, рекомендует рецензенту подумать о том, «как это изменение влияет на большую и меньшую картину». Учитывая, что в целом картина включает в себя поиск технических долгов - ищите код это повторяется, не является модульным или не соответствует последним стандартным соглашениям, а также анализирует изменения в архитектуре кодовой базы.
Сэм Доноу, ведущий разработчик в Hudson River Trading, считает, что «нет ничего слишком большого или слишком маленького, чтобы комментировать. Предложения по небольшим улучшениям могут привести к большим улучшениям во многих частях кодовой базы ».
Вы можете использовать PR-комментарий на GitHub, чтобы предоставить положительный отзыв, а также указать, где код может отличаться от стандартных соглашений фреймворка React.
Например, во время одного из моих собственных обзоров кода я получил комментарий, что некоторые свойства компонента React сбивают с толку, что вызвало более широкие вопросы о том, как этот компонент используется. В конечном итоге я удалил свойства из исходного компонента и создал отдельный компонент, чтобы прояснить поведение каждого из них и убедиться, что оба могут использоваться в большем количестве мест.
2. Подумайте о безопасности
Не забывайте, что некоторые изменения могут повлиять не только на кодовую базу. Руддер рекомендует оценить, может ли пользователь «использовать эту функциональность для оскорбления кого-либо или может злоупотреблять системой». Например, если новая функция в запросе на получение доступа включает в себя ввод пользователя, поиск SQL-инъекций, доступ к данным, межсайтовый скриптинг и другие уязвимости безопасности.
3. Сосредоточьтесь на ошибках
Ваши коллеги-авторы кода - независимо от того, насколько роботоподобными они могут показаться - люди, и люди могут сломать или забыть о функциональности. Поэтому убедитесь, что вы «просматриваете тесты с той же важностью, что и остальной код», советует Абхишек Пиллай, технический руководитель в Teachers Pay Teachers. «Они предотвратят появление новых ошибок и послужат формой документации для всех, кто работает над этим в будущем».
Чтение тестов может помочь вам понять функциональность новой функции и увидеть различные случаи, которые она будет представлять, а анализ тестов поможет вам указать пропущенные случаи и найти функции, не включенные в этот PR. Если в изменение кода не включены тесты и они кажутся актуальными, целесообразно запросить их в обзоре.
Но тесты это еще не все. «Не надейтесь слишком сильно на систему», - предупреждает Донов. «То, что тесты были выполнены, не означает, что ошибок нет».
Вы также можете захотеть «запустить приложение локально, чтобы функционально протестировать его и убедиться, что оно работает. Если это не сработает, то нет смысла проводить дальнейшую проверку », - говорит Райан Вернер, разработчик программного обеспечения в 8th Light. Хотя некоторые рецензенты не считают, что ручное тестирование должно быть частью процесса проверки кода - отчасти из-за времени, которое на это требуется - Вернер считает, что это быстрый способ определить, стоит ли тратить больше времени на рецензирование, а также стратегию, которая поможет сократить рост отставания от ошибок.
4. Будь командным игроком
Клише приобретает новое значение, когда дело доходит до пересмотра кода. «Потратьте время на рецензирование, потому что это кодовая база каждого», - говорит Вернер, который выступает за чувство «коллективной собственности». Вы, как рецензент, должны работать над тем, чтобы защитить накопившиеся ошибки от увеличения с целью дать вашим команда меньше работы по линии.
Пиллаи использует гифки для празднования одобренных и готовых к объединению пиарщиков своих товарищей по команде.
В то же время Чарльз Лакстон, технический руководитель The Muse, призывает рецензента понимать и помнить приоритеты команды. В связи с быстрым приближением сроков и разногласий, иногда создается список дел для отставания, который гарантирует внесение улучшений в будущем, а добавление комментария к рассматриваемому коду в это время - это бандит, необходимый для того, чтобы держи свою команду счастливой
Наконец, если вы спросите себя, будет ли этот код понятен кому-то, кто только что присоединился к команде и читал ее в течение первых нескольких недель, это поможет сделать ваш код читабельным и понятным.
5. Используйте процесс обучения и обмена знаниями
Процесс обзора дает всем заинтересованным сторонам возможность получить более полное представление о базе кода, языках, инфраструктурах и передовых практиках.
Мэтт Джеффри, технический руководитель The Muse, советует рецензенту «понять изменения в архитектуре. Один из способов - прочитать имена файлов, поскольку они помогают создать контекст. Например, если вы смотрите на изменение уровня доступа к данным Вы знаете, что не имеете дело с бизнес-логикой или пользовательским интерфейсом. "
Вы можете использовать PR-комментарий на GitHub, чтобы поделиться документацией.
Когда вы учитесь на изменениях кода, у вас также есть возможность поделиться знаниями. «Лучше всего объяснить свое мнение и подкрепить его документацией», - говорит Лакстон. Ссылки, которые вы предоставляете на подтверждающие доказательства и заслуживающие доверия статьи, не только помогают рецензенту и составителю кода исследовать различные подходы при принятии окончательного решения, но и укрепляют их знания в области программирования.
Помня об этих советах, помните также, что рецензирование - это время для тренировки ваших навыков. «Дайте людям возможность усомниться в том, что они думают об их подходе, и укажите разные возможности, пытаясь рассеять обороноспособность», - говорит Руддер. «Я оставляю комментарии повсюду и заключительный комментарий - вот что здорово, вот что можно улучшить, вот что нужно изменить перед слиянием».
При таком подходе вы будете не только защищать свою кодовую базу от технических долгов, угроз безопасности и ошибок, но и будете создавать свою команду.
