Мы живем в мире, где код вездесущ. Любой программный продукт состоит из кода, и часто кодовая база огромна. Благодаря этому, в большинстве случаев, над ним работает больше людей вместе. Именно здесь проверка кода играет решающую роль. Несмотря на то, что существует множество способов проверки кода, в этой статье я хотел бы рассказать об инструментах (таких как GitHub), что означает, что рецензент назначается для запроса на вытягивание, созданного коллегой.

Что такое проверка кода?

После того, как разработчик получит тикет, независимо от того, является ли это ошибкой или новой функцией, будет создан некоторый код. После того, как работа сделана, согласно практике, следует отправить запрос на включение в апстрим. Это когда ваш коллега или кто-то более «старший», чем вы, должен проверить этот код и дать отзыв.

В чем смысл код-ревью?

Многие люди могут иметь в виду что-то вроде: «Эй, но я видел, что это работает. Есть ли необходимость в том, чтобы кто-то проверил мой код?». Несмотря на то, что в некоторых случаях это может быть справедливо, и мы склонны чрезмерно опекать нашу работу, очень важно принимать конструктивную обратную связь для роста и обучения. Поначалу может быть немного неприятно получать много комментариев к своей работе, но со временем — вы адаптируетесь и, самое главное, научитесь (что и должно быть нашей целью!). Кроме того, проверка кода предназначена не только для разработчика, отправившего запрос на извлечение. Другие члены команды также должны увидеть, что вы сделали, и приблизиться к аспекту вашей работы, относящемуся к предметной области. Короче говоря — освойте кодовую базу. Это помогает им понять, что произошло и почему это произошло.

Преимущества код-ревью

Оптимизация кода

Каким бы старшим не был разработчик, никто не всегда может найти самое оптимальное решение. Это происходит в основном из-за монотонного характера нашей работы. Мы не всегда работаем над передовыми решениями; часто мы повторяем работу, которую проделали в прошлом. Так что очень легко упустить из виду лучшее решение, поскольку оно «работало в прошлом».

Поиск пограничных случаев

Давайте предположим, что вы создали некоторые функции, у вас были свои требования и вы работали над чем-то, что делали в прошлом. В такие моменты легко забыть, как люди будут взаимодействовать с результатом вашей работы. Во время проверки кода кто-то другой обычно смотрит немного шире и может легко вписаться в шкуру пользователя и подумать о некоторых пограничных случаях, которые вы не учли (и это хорошо!).

Обучение

Во время проверки кода вы должны получать конструктивные отзывы и предложения о том, как можно было бы сделать решение по-другому. Это не означает, что вы должны реализовать это таким образом, но это может быть то, о чем вам еще предстоит подумать и что вы захотите использовать в будущем. Таким образом, мы можем учиться друг у друга. Возможно, кто-то, просматривая ваш код, тоже не видел такого решения? Это может спровоцировать дискуссию, которая в итоге приведет к росту.

Держим других в курсе

Итак, я упомянул, что проверка кода предназначена не только для создателя запроса на включение. Всегда рекомендуется включать других коллег в запрос на вытягивание, независимо от того, являются ли они новичками в проекте или были в нем уже какое-то время. Это позволяет людям узнать, над чем вы работали. Теперь вы можете подумать: «Но у нас есть встречи для этого, и мы видим билеты на доске» — это верно, но это еще не все. Если кто-то новичок или работает над другой частью приложения, ему будет полезно увидеть, как ваш код интегрируется со всем, каковы практики и т. д. Особенно новые разработчики, которые могли использовать разные подходы и методы. Это помогает им набрать скорость.

Личная перспектива

На протяжении всей своей карьеры я обнаружил, что существуют определенные для каждой команды правила, помогающие им лучше проводить проверки кода. Когда я могу просмотреть примерно 100 файлов, становится очень сложно, если возможно, предоставить точную и содержательную обратную связь. В командах, с которыми я работаю, я всегда стараюсь установить максимальное количество строк кода, подлежащих проверке. В моем случае это 200 плюс-минус. Это позволяет мне проверять код на предмет сложности и, что наиболее важно, предметно-ориентированного аспекта, который в некоторых случаях может иметь решающее значение.

Краткое содержание

В заключение, не бойтесь обзора кода, потому что его цель не в том, чтобы подорвать ваши способности или каким-либо образом напасть на вас. Вместо этого его цель — гарантировать масштабируемость, чистоту и оптимизацию исходного кода. Это также позволяет обеим сторонам учиться и быть в курсе всего, что происходит в проекте! Главный вывод — не относиться к этому процессу лично, а работать в команде, чтобы обеспечить качество продукта.