Как выбрать код для проверки?

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

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

Вот некоторые из факторов, которые я могу придумать, которые могут повлиять на выбор:

• Язык: C, Java, SQL, PL / SQL
• Возраст кода: новый код против старого кода
• Использование кода: часто используемый код против (эффективно) мертвого / малоиспользуемого кода
• Важность кода: Критический код против некритического кода
• Разработчик: младший код разработчика против старшего кода разработчика

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

Некоторые периферийные вопросы:

• Подходы к проверке кода (Упоминания о критических разделах и новом коде разработчика)
• Должны ли мы попытаться просмотреть весь наш код?

В общем, вы должны рассмотреть все . Если новая заявка имеет 2 000 LOC, все 2 000 LOC должны быть рассмотрены.

Вот почему нет лучшей практики о том, как выбирать, что проверять.

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

• на базе кода (один монолитный код будет сложнее переписать / просмотреть, чем набор отдельных компонентов и т. д.),

• ваш контекст (можете ли вы прекратить все, над чем вы работаете, и потратить три месяца (три года?), работая только на переписывание / рецензирование, или вы должны делать это небольшими перерывами, только когда у вас есть свободное время)?

• тип проверки, которую вы делаете (у вас есть контрольный список вещей для проверки? В зависимости от пунктов контрольного списка, вы можете сначала просмотреть некоторые части).

На вашем месте я бы:

• следуйте принципу 80% -20%, упомянутому в первом комментарии ко второму вопросу, с которым вы связаны.

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

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

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

Начните с просмотра всех изменений, которые вы вносите в код; это остановит проблему еще хуже. Затем начните просмотр кода на основе частоты изменений; это будут «проблемные» области.

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

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

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

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

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

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

Если есть известные области, требующие рефакторинга, но это займет много времени (например, 1 неделя или более). Затем создайте рабочий элемент для этого рефакторинга и добавьте его как элемент для работы.

Начните с просмотра всего нового кода и изменений в существующем коде.

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

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

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

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

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

В моем проекте мы включаем проверку кода как обязательную в большинстве случаев для любого разрабатываемого задания / пользовательской истории / ошибки. Мы используем процессы scrum / agile, и тикет / история не переносятся в build (что является отставанием для QA) до написания модульных тестов и проверки кода.

Для этой цели мы используем анализ Atlassian FishEye и анализ кода Crucible, интегрированный с JIRA + SVN.

Когда разработчик регистрирует код для определенной истории, он создает новый обзор кода в FishEye, где он выбирает других членов команды для проведения обзора.

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

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

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