Создайте здоровую офисную среду с помощью этих эффективных инструкций по проверке кода

1656641416 sozdajte zdorovuyu ofisnuyu sredu s pomoshhyu etih effektivnyh instrukczij po

от Шандора Дарго

pr1xuFhk-8cJaXvBr405hVrFJC6WbGSrqmn1
Счастливые программисты, здоровый офис. (источник)

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

Дополнительные сведения о рекомендациях см. в этой статье. Я, кстати, скоро его пересмотрю.

На этот раз я собираюсь сосредоточиться на проверке кода и соответствующих инструкциях.

Цель проверки кода

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

Итак, позвольте мне начать с самого важного правила, которое вы всегда должны помнить, когда начинаете просматривать запрос на получение или когда открываете полученный отзыв:

Никакой комментарий не должен быть личным. Об авторе или рецензенте нельзя делать комментарии. Обзор всегда должен касаться кода!

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

iwBJmQjVw5bLuAarwiexTTHpdZWktPyW-WEx
Код необходимо тщательно проверять

Элементы, которые необходимо проверить при проверке кода

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

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

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

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

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

Виды контрольных листов

Полный контрольный список процесса

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

  • Добавлены ли новые единичные/регрессионные тесты?
  • Есть новые предупреждения компилятора?
  • Или изменение функционально имеет смысл?
  • Много ли зависимостей?
  • Чистые ли сообщения комиттов?

Список принципов SOLID (объектно-ориентированного проектирования).

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

  • Принципы единой ответственности
  • Открытый/закрытый принцип
  • Принцип подстановки Лескова
  • Принцип разделения интерфейса
  • Принцип инверсии зависимостей

Контрольный список безопасности

Ваше приложение может быть или не быть критическим для безопасности. Как только его сломали один раз или он вышел из строя из-за какого-то беспорядочного входа, он им станет. Этот контрольный список может сильно зависеть от языка (я предоставляю вам один для C++). Список взят в основном из этого разговора о практике безопасного программирования на NDC Security Conference в 2018 году

  • Правильно ли обрабатывается внешний ввод?
  • Используются ли интерфейсы в стиле C?
  • Есть new оператор чрезмерно используется вместо распределения стека?
  • Есть ли много вычислений размера (подверженных ошибкам)?
  • Часто ли используются указатели?
  • Часто ли используются shared_ptrs?
  • Есть ли какие-нибудь темы?

Список лучших практик тестирования

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

Плохая новость состоит в том, что не существует единого способа, который бы подходил всем. Тем не менее, я бы посоветовал вам придерживаться цикла Test Driven Development. Хорошая новость состоит в том, что в проекте есть, по крайней мере, общее понимание того, что нужно делать.

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

Вот несколько моментов, которые следует уточнить по части тестирования:

  • Достаточно ли модульных тестов?
  • Достаточно ли нерегрессионных тестов?
  • Тесты проверяют что-нибудь одно?
  • Есть ли у них утверждение? (Тест может иметь несколько утверждений, но логически они утверждают одно)
  • Читаются ли они?
  • Как используются даты? (фиксированный против генерируемого)

Контрольный список читаемости кода

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

Рецензент кода несет здесь огромную ответственность. Если вы читаете запрос на получение, подумайте над следующими вопросами:

  • Имеют ли значение имена?
  • Достаточно ли малые классы/функции?
  • Читается ли код как проза?
  • Правильно ли отформатирован код?
  • Есть ли дублированный код?

Контрольный список обработки ресурсов, он же RAII

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

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

  • Выяснено ли право собственности на объект?
  • Уничтожены ли должным образом объекты/ правильно ли освобождена память?
  • Правильно ли обрабатываются новые поля?
  • Правильно ли инициализированы поля в конструкторах?
  • Обновлены ли операторы сравнения?
g5hd9nbvxcs2wVXZN-AmvzcLiYZeqQ9xUq2Q
Обзор предназначен для повышения качества и обучения друг другу

Кодекс поведения для рецензентов кода

Как было сказано ранее, комментирование чужого кода также является человеческой задачей, поэтому будьте вежливы своим коллегам-разработчикам. Вот несколько советов. Следуя им, вы значительно снизите вероятность того, что разработчики будут плакать или бросать друг в друга стульями в офисе. (Но последнего я никогда не видел – пока…)

Не стоит

  • Не обращайтесь к личным чертам и не осуждайте (например, воздержитесь от того, чтобы сказать, что вы/ваш код глуп…)
  • Не предъявляйте требований (по крайней мере, пожалуйста, и объясните, почему вы просите изменить)
  • Не будьте саркастическими, даже если вы друзья. Другие рецензенты/читатели могут считать некоторые комментарии неуместными
  • Никогда не говори никогда и всегда. Всегда будут исключения. Так что отнеситесь к этому правилу внимательно…
  • Избегайте выборочного владения кодом (т.е. не используйте «мой», «не мой», «ваш»…)

дос

  • Задавать вопрос.
  • Обращайтесь за разъяснениями.
  • Будьте очевидны. Помните, что люди не всегда понимают ваши намерения в Интернете.
  • Старайтесь понять точку зрения автора.
  • Если дискуссии становятся слишком философскими или академическими, перенесите дискуссию в автономный режим
  • Определите способы упрощения кода, решая проблему.
  • Сообщите, какие идеи вы чувствуете, а какие нет. Если вы просто выражаете свои преимущества, скажите, что это только ваши преимущества.
  • Воспитывать. Если вы что-нибудь предлагаете, поделитесь доказательствами, почему это лучше (например, статьи, исследования, книги и т.п.).
f1wn8KRB4zrj1SyBz3iMmvkGrv66l7hjr3Bb
Все мы, разработчики, являемся авторами

Правила для авторов

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

Призыв к действию

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

Эта статья была первоначально опубликована в моем блоге.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *