Рекомендации по анализу проекта и кода
Ниже представлен ряд рекомендаций и способов анализа проекта и кода.
Требуется
Проводить проверку не спеша.
Цель проверки заключается в тщательном разборе и анализе проекта и кода. Проверке следует посвятить до половины времени, затраченного на первоначальное написание кода или планирование проекта.
Позволить проверяющим руководить проверкой.
Проверка должна основываться на действиях и комментариях проверяющих. Если разработчикам разрешено руководить проверками своей работы, другие проверяющие могут пропустить ошибки.
Знакомиться с документацией по коду или проекту перед собранием, посвященным проверке.
За исключением собраний для проверки незначительных изменений, готовьтесь к собраниям, посвященным проверкам, заранее. Собрания по проверкам, к которым проверяющие не готовятся заранее, не знакомясь с кодом или с проектом, являются пустой тратой времени для всех участников.
Использовать портал командного проекта группы для проведения групповых проверок.
Публикуйте документы по проекту на портале проекта, где они будут доступны для всеобщего доступа и просмотра. Отправьте указатель на опубликованный документ проверяющим и попросите их добавить свои комментарии при помощи функции обсуждения обозревателя Internet Explorer. Если требуется проверка кода схожим образом, вставьте код в документ Word и опубликуйте его также на узле SharePoint. Дополнительные сведения см. в разделе Планирование и отслеживание проектов.
Пользоваться контрольным списком.
Зачастую проверяющий концентрируется на отдельных аспектах проверки, например только на безопасности, обработке ошибок или стиле. Может возникнуть желание перейти к другим задачам после завершения проверки по отдельному аспекту. Контрольные списки напоминают обо всех аспектах, на которые нужно обратить внимание во время проверки.
Отслеживать все ошибки, обнаруженные при анализе кода.
Документируйте ошибки как рабочие элементы, комментарии в коде или ошибки в документации по проекту. Если этого не делать, проблемы можно потерять, и никакой пользы от анализа кода не будет. Дополнительные сведения см. в разделе Создание рабочего элемента.
Нерекомендуемые действия
Вносить изменения в код или проект без ведома проверяющих.
Существует вероятность обнаружения ошибок в проекте или коде после его отправки проверяющим. Однако не следует поддаваться искушению и исправлять ошибки до проведения собрания, посвященного проверке. При внесении изменений в код или проект до собрания результаты проверки приведут всех в замешательство и могут обидеть проверяющих. Вместо этого рассматривайте найденные ошибки с позиций проверяющего; помечайте их и отслеживайте вместе со всеми остальными комментариями по проверке.
Рекомендовано
Привлекайте представителей разных дисциплин.
Несмотря на то, что не всегда представляется возможным обеспечить наличие различных дисциплин помимо разработки и проверки проекта и кода, представители разных дисциплин могут помочь обнаружить трудно выявляемые ошибки. Достаточно будет одного или двух человек из каждой дисциплины. Привлечение большего количества людей затягивает процесс проверки и делает его трудноуправляемым.
Проверять весь код и все проекты.
Чтобы обеспечить качество конечного продукта, проверки кода и проектов необходимо проводить по всей выполненной работе. Проверки должны включать анализ кода, модульные тесты и документирование проекта с самых ранних этапов.
Для управления анализом кода рекомендуется создать наборы отложенных изменений.
При этом можно создать набор отложенных изменений, содержащий только изменения, которые должны изучить проверяющие. Создание набора отложенных изменений позволяет предоставить к ним доступ проверяющим без возврата этих изменений в систему управления версиями. Дополнительные сведения см. в разделе Работа с наборами отложенных изменений.
См. также
Основные понятия
Анализ качества приложений с помощью средств анализа кода
Улучшение качества кода с помощью политик возврата командного проекта