Обеспечение качества вашего программного обеспечения и кода

Question

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

Постарайтесь сосредоточиться на программировании, а не на понимании предметной области или любых других предварительных этапов программирования (в ответе!).

Это следующие шаги, по которым я живу:

Написание юнит-тестов

• Сделать не удалось (без кода)
• Make it Work (рабочий код)

Анализ абстракции

• Способы извлечения
• Извлечение интерфейсов

Рефакторинг

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

Вопрос; Какой следующий шаг?

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

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

Однако не гарантирует какого-либо качества продукции.

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

Answer 1

Самое главное, что вы и ваши коллеги - опытные программисты. Никакие правила или рекомендации не сделают продукт лучше, если программисты не обладают высокой квалификацией.

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

Обзор кода имеет две цели:

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

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

Answer 2

Filip

Мне тоже нужен какой-то инструмент, но я нашел один очень эффективный способ сделать это:

1. пусть другой разработчик разработает юнит-тест
2. проведет совещание по рассмотрению короткого кода внутри команды, где каждый член команды сможет прокомментировать и высказать свое мнение о коде.

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