Что я узнал, провалив первую проверку кода

Что я узнал, провалив первую проверку кода

Практические советы, основанные на моем опыте работы Front End Developer

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

Мой опыт разработки. Почему вам следует прислушаться к моему совету?

Я Front End разработчик, последние 5 лет в основном занимаюсь JavaScript, но с общим опытом работы 10 лет. До того, как я стал JS-разработчиком, я работал в основном с HTML и CSS, добавляя немного PHP для хорошей меры. Я работал в широком диапазоне сред разработки; от единственного разработчика интернет-магазина до работы в небольших группах разработчиков в цифровых агентствах и перехода к более формальной среде Agile-разработки.

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

Соблюдайте четкие правила кодирования, с которыми согласна вся команда

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

Мои первые попытки просмотреть код

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

JavaScript (в то время использовался ReactJS с ES5)

· Убедитесь, что используются все вары

· Объявление Var должно быть по одному в каждой строке.

· Убедитесь, что используются все функции require ()

· Убедитесь, что нет лишних ","

· Удалить все журналы консоли

· Удалите весь ненужный закомментированный код

· Удалите все жестко запрограммированные переменные, которые могут быть заменены значениями переменных конфигурации.

· OnChange должен быть выше методов рендеринга

CSS (с использованием SCSS)

· Убедитесь, что между селекторами есть разрыв строки

· Используйте $ font-family… из _settings.scss

· Убедитесь, что нет пустых селекторов

· Убедитесь, что вы правильно используете модификаторы и селекторы при именовании классов

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

Используйте эффективные инструменты проверки кода

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

Не ожидайте, что станете экспертом с самого начала

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

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

Подумайте о более широкой картине

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

Выделите время, чтобы сосредоточиться на обзоре

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

Будьте уважительны, оставляя отзывы

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

Положительный настрой никому не повредит

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

Примите участие в процессе проверки кода

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

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

Какой у вас был опыт работы с процессом проверки кода? Я хотел бы услышать их в комментариях ниже.