Столпы качественного кода: руководство по улучшению код-ревью

Как наставник по коду и член команды разработчиков программного обеспечения, я являюсь субъектом проверки кода и провожу ее. Однако я заметил, что много раз люди, делающие обзор, не имеют четкого представления о том, что искать. Это приводит к обсуждению таких вещей, как стиль и микрооптимизация. Поскольку я сам был там, я хотел бы предложить некоторые идеи о вещах, которые вы могли бы искать, делая обзор кода. Хочу поделиться своим личным стандартом качества. Для меня качество кода измеряется тремя аспектами: понятностью, пластичностью и правильностью.

Понятность

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

Качественный код прост. Важно отметить, что существует существенная сложность (присущая проблеме сложность) и случайная сложность (сложность решения). Я имею в виду последнее. Стремитесь к тому, чтобы ваши решения были простыми. Я обнаружил, что общение здесь является основной идеей: кратко ли код передает идеи?

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

Пластичность

Из Маленькая библиотека Тюдоранса:

Свойство быть физически податливым; свойство чего-либо, что можно обрабатывать, ковать или формовать, не ломая

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

Жесткий код лучше объясняет дядя Боб:

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

Я часто ищу ссылки, которые связывают модули, объекты и проекты без необходимости.

Правильность

Под этим я подразумеваю максимальное отсутствие ошибок.

Обычно мы имеем дело с 3 типами ошибок: синтаксическими, семантическими и ошибками времени выполнения.
Поскольку компилятор обычно обрабатывает синтаксические ошибки, давайте сосредоточимся на семантических ошибках и ошибках времени выполнения.

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

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

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

Заключительные мысли

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

Кстати, TDD продвигает простой, гибкий и правильный код, но об этом в другой раз 😉

Итак, на что вы обращаете внимание, проводя код-ревью? оставляйте свои комментарии ниже