Как бы вы измерили качество кода в большом проекте

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

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

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

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

software-quality
person askheaves    schedule 30.08.2009    source источник
comment
Наличие мидохлорианов.   -  person cletus    schedule 30.08.2009
comment
stackoverflow.com/questions/84556/ < / а>   -  person z -    schedule 30.08.2009

Ответы (5)


arrow_upward
6
arrow_downward

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

person Diomidis Spinellis    schedule 30.08.2009

arrow_upward
2
arrow_downward

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

person Nick Dandoulakis    schedule 30.08.2009

arrow_upward
1
arrow_downward

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

А еще есть показатель C.R.A.P. ...

P.S. NDepend содержит около десяти миллиардов показателей, так что, возможно, стоит взглянуть на них. См. Также CodeMetrics для Reflector.

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

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

person TrueWill    schedule 30.08.2009
comment
Щелчок. Об этом CodeMetrics PS, возможно, стоит спросить. - person askheaves; 30.08.2009
comment
У нас есть много людей, которые внутренне открывают и отслеживают ошибки. Десятки из тысяч ошибок в моем приложении и другие в выпуске. Как я уже сказал ... БОЛЬШОЙ. - person askheaves; 30.08.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

person Community    schedule 30.08.2009
comment
Мне нравится этот ответ, потому что он говорит о другой стороне моей проблемы ... какие стандарты я устанавливаю для разработки? Думаю, я смотрел на показатели, определяющие эти стандарты, но мы можем прийти к этому с обеих сторон. - person askheaves; 30.08.2009

arrow_upward
0
arrow_downward

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

person Ira Baxter    schedule 30.08.2009
comment
Предупреждающий о проезде: вы могли бы любезно объяснить, почему вы возражаете против этого. - person Ira Baxter; 31.03.2013