Как бы вы оценили «качество» кода в большом проекте? - PullRequest
Новая
       22

Как бы вы оценили «качество» кода в большом проекте?

8 голосов
/ 30 августа 2009

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

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

Пока у меня есть список, который выглядит так:

  • Процент покрытия кода во время полнофункциональных тестов
  • Рецидив отказов BVT
  • График зависимости / оценка, основанный на каком-либо инструменте, таком как nDepend
  • Количество предупреждений о сборке
  • Количество найденных / подавленных предупреждений FxCop / StyleCop
  • Количество операторов "catch"
  • Количество шагов ручного развертывания
  • Количество проектов
  • Процентная доля кода / проектов, которые "мертвы", например, нигде не упоминаются
  • Количество WTF во время проверки кода
  • Всего строк кода, возможно, с разбивкой по уровню

Ответы [ 5 ]

6 голосов
/ 31 августа 2009

Вы должны организовать свою работу по шести основным характеристикам качества программного обеспечения: функциональность, надежность, удобство использования, эффективность, удобство обслуживания и портативность. Я поместил диаграмму онлайн , которая описывает эти характеристики. Затем для каждой характеристики определите наиболее важные метрики, которые вы хотите и сможете отслеживать. Например, некоторые показатели, такие как показатели Chidamber и Kemerer, подходят для объектно-ориентированного программного обеспечения, другие, такие как цикломатическая сложность, более универсальны.

2 голосов
/ 30 августа 2009

Может быть, вы найдете интересный или проницательный анализ: Сказка о четырех ядрах
Редактировать: схема и соответствующие запросы

1 голос
/ 30 августа 2009

Если вы взяли на себя задачу повышения общего качества кода. Вы можете взглянуть на:

  • Сколько открытых проблем у вас есть в настоящее время и сколько времени они занимают их разрешение?
  • Какой процесс у вас есть для сбора требований?
  • Следуют ли ваши сотрудники передовой практике?
  • Определены ли у вас sop для описания методологии программирования ваших компаний.

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

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

Когда ваши сотрудники работают более эффективно, следуя правилу, время разработки должно сокращаться.

Вы можете получить все метрики, которые вы хотите, но я говорю, сначала вы должны посмотреть, как все делается:

Какие у вас практики разработки?

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

1 голос
/ 30 августа 2009

Цикломатическая сложность - достойный показатель качества. Я уверен, что разработчики могли бы найти способ «игры», если бы это был единственный показатель! :)

А затем есть C.R.A.P. метрика ...

P.S. NDepend имеет около десяти миллиардов метрик, так что на это стоит обратить внимание. См. Также CodeMetrics для отражателя.

D'Oh! Я только что заметил, что вы уже упомянули NDepend.

Было бы интересно отслеживать количество зарегистрированных ошибок ...

0 голосов
/ 30 августа 2009

Количество программного клонирования / дубликата кода , чем меньше, тем лучше. (Ссылка обсуждает клоны и различные методы их обнаружения / измерения.)

...