Какие показатели мы должны использовать для оценки качества кода?

Question

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

Как вы думаете, можно ли указать "ок"? Что важно? Зависеть от метрик? Тестовое покрытие? Комментарии? Стиль кодирования? Документация

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

Answer 1

Я думаю, что для любого нетривиального проекта вы должны иметь руководящие принципы кодирования (стиль, комментарии и т. Д.) И метрики, чтобы знать, соблюдаются ли они или нет. Список, который вы обрисовали, очень хорошее начало.

Answer 2

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

Люди, особенно новые люди в проекте, всегда привносят свой собственный стиль. Обзоры кода помогают андрогинизировать код.

Answer 3

Вы смешиваете две разные вещи.

Вы говорите о стиле кодирования, но затем упоминаете тестовое покрытие, метрики и т. Д.

Стиль кодирования, безусловно, может быть указан - все требования документа должны указывать, что «В целях поддержания и согласованности кода этот проект будет следовать этим стилям и стандартам кодирования».

Однако, как правило, большинство проектов просто требуют «Надлежащей отраслевой практики» и «согласованного стиля кодирования для всего проекта» и оставляют фактическое определение и реализацию этого на усмотрение разработчиков.

Однако, другие вопросы, которые вы обсуждаете, плохой код, требующий рефакторинга, тесты, покрытие и т. Д. (Я бы также добавил LINT и статический анализ), должны быть явно указаны и обязательны. Нет причин оставлять их вне спецификации - они являются жесткими метриками, которые показывают, какой тип ошибок кодирования (или попадание на нечеткую грань между стилем и плохим кодом, какой тип шаблонов кодирования могут привести к ошибочному коду) в любом конкретном коде, насколько хорошо он работает и насколько хорошо тесты показывают правильную работу.

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

Итак, в общем, да, все это можно (и нужно, ИМХО) указывать для любого значимого проекта.

-Adam

Answer 4

Некоторые рекомендации (стиль менее важен, чем контент IMO), например лучшие образцы / практики, но, что более важно, ОБЗОРЫ КОДА.

Answer 5

StyleCop ... также, FxCop ...

Команда должна абсолютно стандартизировать свои стили. Есть место для личного выбора, но команда должна абсолютно стандартизировать свои стили. Код более читабелен, более удобен в обслуживании, более легко просматривается и т. Д. И т. Д. И т. П.

Answer 6

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

1. Управление требованиями. Есть некоторый процесс, чтобы применить контроль качества к вашим требованиям. Они имеют смысл? Кто просил об этом? Являются ли они правильными людьми, чтобы сделать эти запросы.

2. Дизайн теста. Создайте свои тесты в соответствии с требованиями, а не реализацией. Не позволяйте вашим кодерам проводить тестирование!

3. Проверьте все - каждый раз. Пройдите полный цикл тестирования для каждого выпуска, не существует такого понятия, как вспомогательный выпуск.

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

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

Answer 7

Есть так много вещей, которые можно назвать атрибутами хорошего / хорошего кода.

• без ошибок или предупреждений при компиляции

Есть также несколько других тем на этой теме ...