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

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

Цель этих статей — дать вам представление о том, как сделать проверку кода более приятной, независимо от того, к какой категории вы относитесь. Итак, без лишних слов, вот еще несколько вещей, которые я узнал о проверке кода.

Оцените влияние

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

Погружаясь здесь немного глубже, воздействие обычно имеет два нюанса:

Во-первых, у вас есть очевидное влияние, меняется цвет фона, в базе данных появляется дополнительный столбец, что-то исправляется. Обычно это совпадает с требованиями большинства задач. Это то, что вы обычно просматриваете, и мы не будем беспокоиться об этом в этой статье.

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

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

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

Давайте посмотрим поближе. Один из лучших способов выяснить скрытое влияние для рецензента – перенести код на свой компьютер и начать его проверять. Таким образом, то, как мы воспринимаем код, изменится, поскольку тесты, которые мы можем запускать, а также потоки кода, которые мы можем проверять, выходят далеко за рамки всего, что мы могли бы заметить в обычном режиме.

Приветствуются вопросы

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

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

Хотя я не против хороших исследований и любопытства, вы должны признать: это не самый эффективный способ сделать это, тем более что, делая это, вы можете в конечном итоге замедлить весь процесс. Намного проще спросить.

Вы можете подумать, что публикация вопросов и предоставление ответов еще больше замедлит проверку кода, но, по моему опыту, это совсем не так. По правде говоря, самый лучший и быстрый способ понять сложность и, если уж на то пошло, научиться — это задавать вопросы. Кроме того, я еще не встречал разработчика, который не хотел бы объяснять ход своих мыслей за каким-то сложным фрагментом кода.

Предлагайте аргументы, а не только мнения

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

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

Смысл проверки кода заключается не только в проверке представленной функциональности, но и в решении таких вопросов, как эффективность, ремонтопригодность, чистота и многие другие. Зная это, нетрудно понять, почему обзоры кода иногда становятся местом, где возникают разные мнения. Поясню: другое мнение не является чем-то плохим по своей сути. Во многих отношениях это просто означает, что вы являетесь частью команды, которая может видеть вещи с разных сторон и перспектив.

Предоставление другого мнения в обзоре кода тоже не является чем-то плохим. Однако мы должны стараться помнить о том, как мы выражаем эти мнения. По моему опыту, лучший способ сделать это — заключить и обосновать свое мнение вескими аргументами. Если вы сделаете это, весь разговор сместится от конфликта мнений к выбору наилучшего возможного подхода с учетом представленных аргументов. Я также добавлю, что самые надежные и хорошо построенные фрагменты кода создаются именно так.

Снова сделайте проверку кода интересной

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

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

Итак, как мы можем изменить наш взгляд на проверку кода с этого, казалось бы, жесткого и тяжелого процесса, на то, что нам может доставлять удовольствие?

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

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

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

Спасибо за уделенное время. Первую часть этой серии вы можете найти здесь.