Рекомендации по возврату качественного кода
Обновлен: Ноябрь 2007
В следующем списке содержится ряд рекомендаций по возврату качественного кода.
Обязательные действия
Настаивать на качественном возврате.
Не принимайте низкого качества при возврате кода; это приводит к возникновению проблем на последующих этапах жизненного цикла продукта. Следует понимать, что группы, как правило, не исправляют слишком сложные или слишком запутанные проблемы, а также проблемы, которые выявляются на поздних этапах жизненного цикла продукта.
Использовать контрольные списки.
Отслеживайте типичные для себя ошибки и используйте их в качестве контрольного списка при последующем написании кода. Контрольный список можно начать с общих ошибок, допущенных группой или подразделением, а затем индивидуализировать его для личного использования.
Проводить проверки кода.
Проверки кода дают его автору возможность описать и лучше понять свой собственный код, а другим позволяют взглянуть на проверяемый код по-новому.
Писать модульные тесты.
Наилучший способ обеспечения качества — это написание тестов, направленных на проверку данных и алгоритмов и исключающих возможность повторения предшествующих ошибок. Модульные тесты бывают четырех видов:
В положительных модульных тестах код применяется по назначению с последующей проверкой правильности полученного результата.
В отрицательных модульных тестах код намеренно применяется не по назначению с целью проверки его надежности и правильности обработки ошибок.
В нагрузочных тестах код доводится до предела прочности с целью выявления неявных ошибок, связанных с ресурсами, временем или повторным использованием.
Тесты с внесением неисправностей выявляют отклонения в обработке ошибок.
Дополнительные сведения см. в разделе Практическое руководство. Создание модульного теста.
Использовать средства анализа кода.
Самый простой способ раннего обнаружения ошибок заключается в повышении уровня предупреждений в компиляторе и использовании средств анализа кода. Важно никогда не пропускать предупреждения и всегда вносить исправления в код.
Дополнительные сведения см. в разделах Выявление и исправление дефектов кода C/C++ и Выявление и исправление дефектов управляемого кода.
Не использовать неуместный язык в исходном коде.
Следует исключить использование неуместного языка и ссылок в исходном коде. Многие клиенты из разных стран очень чувствительно относятся к определенным фразам или именам, в особенностям к ссылкам на политические организации, статус которых может носить спорный характер. Проверьте исходный код на отсутствие политически окрашенных ссылок и выражений и сообщите обо всех найденных ошибках.
Создавать рабочие элементы.
Не забывайте о незавершенной работе; обязательно создавайте рабочие элементы для комментариев типа TODO, REVIEW, BUG и UNDONE. Дополнительные сведения см. в разделе Практическое руководство. Добавление новых рабочих элементов.
Нерекомендуемые действия
Создавать функции без спецификации.
Не пишите код без спецификации. Сначала напишите спецификацию и отдайте ее на проверку. Без спецификации группа тестирования не может знать, что работает верно, а что нет. При написании кода без спецификации существует опасность недопонимания между разработчиком и проверяющими, неправильного понимания потребностей заказчика, а значит, поставки продукта низкого качества. Дополнительные сведения см. в разделе Командные проекты Team Foundation.
Достичь середины первого этапа проекта без установки продукта на месте.
Группа тестирования должна иметь возможность установить продукт на своих компьютерах, даже если это будет всего лишь установка прототипа. Дополнительные сведения см. в разделе Общие сведения о Team Foundation Build.
Рекомендуемые действия
Придерживаться единообразного стиля при написании кода.
Когда вся группа придерживается единого стиля при написании кода, продукт характеризуется надежностью, согласованностью, удобством сопровождения и высоким качеством. Конкретные подробности самих рекомендаций не так важны. Важно составить определенные рекомендации и сделать так, чтобы группа добросовестно следовала им. Основными преимуществами, которые дает выбор определенного стиля, являются согласованность и простота распознавания шаблонов кодирования. Поэтому выработайте свой стиль и придерживайтесь его.
Писать модульные тесты до написания кода.
Разработка через тестирование является ключевой методикой, взятой из принципов гибкой разработки и экстремального программирования. Первоначальное написание модульных тестов позволяет добиться нескольких целей по качеству:
Гарантировать написание модульных тестов.
Гарантировать простоту тестирования кода, что зачастую приводит к повышению связности кода и гибкости связей между модулями.
Наиболее удачное проектирование работы зачастую получается, когда сначала продумывается, как проект будет тестироваться.
Дополнительные сведения см. в разделе Практическое руководство. Создание модульного теста.
Обеспечить возможность переноса кода на другие платформы.
Проектирование и кодирование с ориентацией на переносимость повышает надежность кода, даже если фактический перенос кода на другие платформы не планируется. Делая код переносимым, разработчик:
улучшает предположения;
лучше понимает типы данных и цели проекта;
повышает вероятность того, что код будет поддерживать новые платформы в будущем.
Оптимизировать существующий код, разбив его на более мелкие функции.
Оптимизация способна дать старому коду новую жизнь. Пытаться внести исправления в крупные старые системы может быть нелегко, потому что некоторые из таких систем настолько сложны по схеме взаимодействия, что даже изменение комментария вызывает трудности.
Для успешной оптимизации сначала необходимо провести серьезное модульное тестирование, чтобы убедиться в том, что оптимизация не вызовет новых ошибок. Затем следует разделить крупные функции на наборы более мелких функций, не внося никаких изменений в саму функциональность. Общие рекомендации таковы:
Каждая мелкая функция должна выполнять только одну задачу, например доступ к интерфейсу пользователя или к базе данных, COM-взаимодействие с отдельным интерфейсом и пр.
После завершения оптимизации всех функций внутри подсистемы можно приступать к изменению отдельных мелких функций без воздействия на всю систему целиком. Функции следует добавлять, удалять или совершенствовать по одной.
Дополнительные сведения см. в разделе Оптимизация классов и типов.
Проверять существующий код.
Ошибки зачастую скапливаются в определенных модулях. Если новый код не содержит ошибок, но в отдельных модулях со старым кодом скрытия ошибки, проверьте только эти модули. Если новый код слишком сильно переплетается со старым, устранить ошибки часто помогает оптимизация. Дополнительные сведения см. в разделах Выявление и исправление дефектов кода C/C++ и Выявление и исправление дефектов управляемого кода.
Выполнить все ветви кода в отладчике.
Одним из самых лучших способов проверки кода является его выполнение в отладчике. На каждой строке убедитесь в том, что ожидаемые события действительно происходят. Выполнение всех ветвей кода в отладчике похоже на построковый модульный тест. Данная процедура трудоемка, но является эффективным способом проверки ожидаемой работы.
Нерекомендуемые действия
Использовать документацию с требованиями в качестве спецификации.
Не пытайтесь найти спецификацию в документации с требованиями. Истолкование может отличаться от истолкования руководителя проекта или тестировщика. При разнице в истолковании ваша реализация не оправдает ожиданий других участников проекта.