Работают ли метрики программного обеспечения в обе стороны

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

Тестовое покрытие — еще один. Однако хорошо известно, что вы можете получить большое тестовое покрытие и при этом иметь плохой набор тестов или, наоборот, отличный набор тестов, сосредоточенный на одной части кода. То же самое происходит и с цикломатической сложностью. Рассмотрите контекст каждой метрики, и есть ли что-то, что нужно улучшить.

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

Отличная книга для ознакомления: "Объектно-ориентированные метрики в практика".

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

Код легче понять и управлять небольшими фрагментами.

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

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

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

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

Никогда больше не открывали ни один из собственных проектов через несколько месяцев? Чем крупнее и сложнее отдельные компоненты, тем больше задаешься вопросом, какой гений написал этот код и какого черта он написал его таким образом. И никогда не бывает слишком много или даже достаточно документации. Поэтому, если сами компоненты менее сложны и меньше, их легче понять заново.

Это немного субъективно. Идея присвоения максимального цикломатического индекса сложности состоит в том, чтобы улучшить ремонтопригодность и читабельность кода.

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

Легко написать код, понятный компьютеру. Сложнее написать код, понятный человеку.

как это сделает наше программное обеспечение лучше?

Выдержка из статей Борьба со сфабрикованной сложностью относится к инструменту для разработчиков .NET NDepend. NDepend хорошо помогает команде управлять большой и сложной базой кода. Идея состоит в том, что метрики кода хороши тем, что уменьшают сфабрикованную сложность в реализации кода:

Во время моего интервью по Code Metrics, проведенного Скоттом Хансельманом по Software Metrics, у Скотта было особенно важное замечание.

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

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

Сложность программного обеспечения — это субъективная мера по отношению к когнитивным способностям человека. Что-то сложно, когда оно требует усилий, чтобы быть понятым человеком. Дело в том, что сложность ПО — это двумерная мера. Чтобы понять фрагмент кода, нужно понимать оба:

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

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

как это сделает наше программное обеспечение лучше?

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

Станет ли наш код лучше только потому, что, например, мы превращаем файл из 10 000 строк в 4 файла по 2500 строк?

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

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