Проверка кода, или, как ее еще можно назвать, коллегиальная проверка, – это деятельность по обеспечению качества программного обеспечения, которую привлекают один или несколько человек для проверки частей кода.
Эта статья является своего рода руководством о том, на что обращать внимание при проверке кода, чтобы кодовая база могла быть более качественной, чтобы рецензенты и автор могли извлечь из нее уроки.
Функциональность
Первое, на что нужно обращать внимание при проверке кода, — это функциональность. Для функции рецензенты могут искать крайние случаи, потенциальные проблемы, чтобы убедиться, что очевидные ошибки не видны, просто взглянув на код.
Вы можете проверить изменения. Попробуйте эту функцию или запустите демонстрацию, чтобы увидеть, есть ли какие-либо ошибки, связанные с проблемами производительности.
Сложность
Вы когда-нибудь видели функцию или компонент, которые слишком сложны, чтобы их можно было понять даже с первого взгляда? Даже если код может работать нормально, но рецензенты не могут понять его достаточно быстро, это может быть логической проблемой. Потенциальные ошибки могут быть, если часть кода слишком сложна, и отладка будет еще более болезненной.
Мы можем назвать это чрезмерным проектированием, когда в части кода есть вещи, которые в данный момент не нужны системе, инженеры должны сосредоточиться на вещах, которые им нужно сделать в данный момент, а не на проблемах. которые могут понадобиться для решения в будущем.
Именование
Имя переменной хорошее? Имя функции хорошее? Хорошо ли называются классы? Хорошее имя должно быть достаточно длинным, чтобы полностью объяснить, что представляет собой код или что он делает, но не настолько длинное, чтобы его было трудно читать.
Комментарии
На мой взгляд, комментарии обычно плохие. Поэтому всякий раз, когда я вижу комментарии во время просмотра кода, у меня часто возникает много вопросов о его существовании. Я написал об этом статью, прямо здесь
Короче говоря, разработчик написал четкие комментарии без ошибок? Все ли комментарии действительно необходимы? Если код недостаточно ясен, чтобы его можно было объяснить, его следует упростить.
Есть некоторые исключения (например, регулярные выражения и сложные алгоритмы часто выигрывают от комментариев, которые объясняют, что они делают), но в основном комментарии предназначены для информации, которую сам код не может содержать, например, для обоснования решения.
Стайлинг
Соглашения по написанию кода – это набор рекомендаций для определенного языка программирования с рекомендуемым стилем и практикой программирования.
Рецензенты должны убедиться, что изменения соответствуют соответствующим руководствам по стилю.
Тесты
Если изменения не являются оперативными исправлениями, рецензенты должны запросить модульные, интеграционные или сквозные тесты.
Рецензенты должны убедиться, что тесты полезны, ясны и правильны.
Не забывайте, что тесты также являются кодом, мы должны обращать внимание на все вышеперечисленное при проверке тестов.
Комплименты
Если код выглядит хорошо, не стесняйтесь, мы можем рассказать об этом автору. Это может побудить разработчиков продолжать делать хорошие вещи.
