Советы по проверке кода.

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

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

- Википедия

Золотое правило

Итак, обо всем по порядку, давайте запомним золотое правило: ценить время ваших рецензентов.

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

Это подводит меня к самому первому принципу.

Принцип 1: сначала просмотрите свой собственный код

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

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

Принцип 2: автоматизация простых вещей

Ни вы, ни ваш рецензент не должны тратить время на поиск отсутствующих фигурных скобок, скобок или исправления синтаксиса вашего кода. Вот для чего нужны автоматические тесты! Эти тесты должны быть частью стандартного рабочего процесса вашей команды, и все проверки кода должны выполняться после того, как ваш код пройдет автоматические тесты в среде CI / CD.

Однако, если команда / фирма, в которой вы работаете, не работает с процессами CI / CD (в отличие от меня), я все еще могу использовать эффективный способ убедиться, что наша разработка окружающая среда соответствует надлежащим соглашениям. Способ заключается в использовании линтеров и форматеров.

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

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

Принцип 3: отвечайте на вопросы с помощью самого кода

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

Через шесть месяцев в нашей компании появился новый сотрудник, которому был поручен тот же проект, над которым я работал раньше. Теперь, когда я просматривал мою часть кода, эта новая девушка задала мне несколько вопросов, которые оказались теми же самыми вопросами, которые мой рецензент задавал мне во время наших начальных сессий проверки кода. Ну вот уже полгода, кто помнит все, что делали полгода назад !!! Более того, в то время у меня не было времени «успеть» задокументировать свой код (как у большинства разработчиков).

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

Принцип 4: атомарные коммиты

Иногда, работая над реализацией новой функции, мы склонны пересматривать наш старый код, который мы могли написать несколько месяцев назад. Однако, будучи развитым разработчиком в то время, мы ставим под сомнение наши старые методы, и теперь, изучив некоторые новые и лучшие способы решения проблем, мы думаем про себя, пока я уже здесь, вносю некоторые изменения в этот файл , Я мог бы также исправить эту другую вещь. Однако мы не думаем о том, что из-за этого шага нашему рецензенту кода будет сложно понять, какие изменения служат цели A, а какие изменяют цель сервера B. Следовательно, действительно важно сделайте ваши изменения атомарными.

Разделение несвязанных изменений позволит вам отправлять разные фрагменты кода разным людям и заставлять их просматривать эти изменения одновременно.

Принцип 5: функциональные и нефункциональные изменения

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

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

Принцип 6: любезно реагируйте на критику

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

Принцип 7. Будьте терпеливы, даже если виноват ваш рецензент

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

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

Принцип 8: искусно запрашивайте недостающую информацию

Если вы получили сообщение вроде «Это сбивает с толку!» От вашего редактора кода. Каков был бы ваш первый ответ? Что ж, у большинства людей первое желание - задать дополнительный вопрос, который будет примерно таким: «Что в этом сбивает с толку?» Но поверьте мне, это может показаться немного ворчливым. Вместо этого для получения дополнительной информации от рецензента, чтобы он не казался сварливым, лучше задать следующий вопрос: какие изменения помогут!

К тому времени, когда ваш рецензент ответит, вы можете еще раз взглянуть на свой код, обычно всегда есть что-то или другое, что вы можете исправить, чтобы улучшить ясность кода. Редакция сообщит вашему рецензенту, что вы открыты для изменений (даже если это не совсем то, что они имели в виду).

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

Первоначально опубликовано на https://www.theimmigrantprogrammers.com.