Сделайте метрика программного обеспечения работает оба пути
Я только что начал работать на крупную компанию. в недавнем внутреннем аудите измеряя метрики, такие как Цикломатическая сложность и размеры файла оказалось, что несколько модулей включая тот, принадлежавший моей команде, имеют очень высокий индекс. таким образом на прошлой неделе мы все концентрировались на понижении этих индексов для нашего кода. путем удаления моментов принятия решения и разделения файлов.
возможно, я пропускаю что-то являющееся новым парнем, но, как это сделает наше программное обеспечение лучше?, я знаю, что метрика программного обеспечения может иметь размеры, насколько хороший Ваш код, но дозируйте его работа наоборот? наш код станет лучше просто, потому что, например, мы превращаем 10 000 файлов строк в 4 2 500 файлов строк?
5 ответов
Цель метрик - иметь больший контроль над вашим проектом. Они не являются самоцелью, но могут помочь повысить общее качество и / или выявить несоответствия в дизайне. Цикломатическая сложность - лишь одна из них.
Другой пример - тестовое покрытие. Однако хорошо известно, что вы можете получить высокий уровень тестового покрытия и при этом иметь плохой набор тестов или, наоборот, отличный набор тестов, сосредоточенный на одной части кода. То же самое происходит с цикломатической сложностью. Обдумайте контекст каждой метрики и подумайте, есть ли что-то, что можно улучшить.
Вам следует избегать случайной сложности , но если обработка имеет существенную сложность , ваш код в любом случае будет более сложным. Затем попробуйте написать поддерживаемый код с разумным балансом между количеством методов и их размером.
Хорошая книга, на которую стоит обратить внимание, - « Объектно-ориентированные метрики на практике ».
Зависит от того, как вы определяете "лучше". Маленькие файлы и меньшая цикломатическая сложность, как правило, облегчают обслуживание. Конечно, сам код все равно может ошибаться, и юнит-тесты и другие методы тестирования помогут в этом. Это лишь часть того, что делает код более удобным для сопровождения.
Код легче понимать и управлять меньшими кусками.
Хорошая идея - сгруппировать связанные биты кода в собственных функциональных областях для улучшения читабельности и связности.
Наличие целой большой программы в одном файле сделает ваш проект очень сложным для отладки, расширения и сопровождения. Я думаю, что это вполне очевидно.
Особая метрика на самом деле является лишь эмпирическим правилом и не должна соблюдаться религиозно, но она может указывать на то, что что-то не так приятно, как могло бы быть.
Нужно ли прикасаться к унаследованному рабочему коду и рефакторировать его - это то, что должно быть оценено. Если вы решите это сделать, то сначала следует подумать о написании тестов для него , таким образом вы быстро узнаете, не нарушили ли ваши изменения какое-либо требуемое поведение.
.] Это немного субъективно. Идея назначения максимального Цикломатического индекса сложности заключается в улучшении удобства обслуживания и читаемости кода.[
]. [] В качестве примера с точки зрения юнит-тестирования действительно удобно иметь меньшие "единицы". А избегание длинных кодов поможет читателю разобраться в коде. Нельзя гарантировать, что оригинальный разработчик будет работать над кодом вечно, поэтому с точки зрения компании справедливо присвоить такой критерий, чтобы код оставался "простым" [
]. [] []] Легко написать код, который может взять на себя компьютер. Труднее написать код, который может понять человек [
]. [
] Никогда больше не открывал свой собственный проект после нескольких месяцев? Чем больше и сложнее отдельные компоненты, тем больше задаешься вопросом, что гениально написал этот код и почему, черт возьми, он написал его таким образом. И никогда не бывает слишком много или даже достаточно документации. Так что, если компоненты сами по себе менее сложны и меньше, то их легче переосмыслить[
].