Краткое и краткое руководство по лучшим практикам проверки кода.

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

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

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

Стандартизация

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

В дидактических целях я разделил обзор кода на две темы: мягкий обзор, который напоминает термин soft skills в нашей области, и жесткий обзор, связанный с жесткими навыками и их применением в разработке.

Мягкий обзор

  • Выделите некоторое время на качество, чтобы вы могли уделить должное внимание обзору кода.
  • Поговорите со своим коллегой и попросите разъяснить сложность деятельности
  • Если возможно, читайте комментарии других рецензентов и участвуйте в обсуждениях.
  • Помните, что проверка кода не предназначена для того, чтобы рассказать, как это сделать «по-вашему».
  • Не все люди в команде имеют одинаковый уровень понимания языка или инструмента.
  • Мы все совершаем ошибки (много!), спрашивая коллегу об ошибке, постарайтесь проявить сочувствие и помочь
  • Модульных тестов недостаточно? Объясните их важность вашему коллеге
  • Ветка master сломалась? Нет проблем, архитекторы создавали приложения с учетом этих проблем.
  • Трубопровод застрял? Прокомментируйте, как это работает, с вашим коллегой и запросите мониторинг

Жесткий обзор

  • Могу ли я легко понять код?
  • Код там, где он должен быть?
  • Был ли код написан в соответствии со стандартами или рекомендациями по кодированию?
  • Был ли код написан с возможностью повторного использования, а не повторения?
  • Удалены ли методы console.log из кода?
  • Могу ли я легко протестировать или отладить код, чтобы найти основную причину?
  • Все ли модульные и компонентные тесты пройдены?
  • Эта функция или класс слишком велики?
  • У функции или класса много обязанностей?
  • Был ли код написан и проверен с помощью линтера?
  • Предупреждения о коде были рассмотрены и устранены?
  • Используются ли в коде постоянные значения или настройки вместо жестко заданных?
  • Похожие значения сгруппированы в файл перечисления или перечисления?
  • Нужны ли комментарии в коде, если они есть?
  • Разделены ли условия if и else на разные методы?
  • Используются ли инструменты фреймворка вместо чистого кода?
  • Применяются ли ленивая загрузка, асинхронная и параллельная обработка, когда это возможно?
  • Является ли написанный код перформативным с точки зрения алгоритмической сложности?
  • Является ли написанный код масштабируемым, несвязанным и расширяемым?
  • Есть ли недостижимый код, который никогда не запустится?
  • Действительно ли используются импортированные зависимости?
  • Являются ли сообщения коммитов семантическими и содержат ли они код задачи?
  • Соответствует ли код требуемому бизнес-требованию?
  • Работает ли код правильно в соответствии с вашей целью по требованию?

Заключение

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