Комментарии 12
а где упоминали? поиск по тегам ничего не дал.
В «Списке полезных инструментов PHP-разработчика» – habrahabr.ru/blogs/php/68569/
а что такое NOC?
Не понял, чем этот инструмент полезен
Его можно использовать для оценки качества кода на PHP с точки зрения ООП – вы получаете как удобное графическое представление абстрактности/нестабильности пакетов, так и числовые значения, оценивающие наследование, сложность кода, его объем.
С помощью такого инструмента вы быстро получаете характеристики и на основании их значений можете делать определенные выводы. Например, что такой-то модуль нужно переработать.
В идеале вы определяете допустимые интервалы значений характеристик для ваших проектов (делаете таблицу допустимых интервалов) и потом, с целью управления разработкой, вы проверяете попадание в них реальных значений проекта. Если попадают – то код прошел такой объектно-ориентированный «ОТК». В противном случае вы знаете где нужно вносить исправления.
С помощью такого инструмента вы быстро получаете характеристики и на основании их значений можете делать определенные выводы. Например, что такой-то модуль нужно переработать.
В идеале вы определяете допустимые интервалы значений характеристик для ваших проектов (делаете таблицу допустимых интервалов) и потом, с целью управления разработкой, вы проверяете попадание в них реальных значений проекта. Если попадают – то код прошел такой объектно-ориентированный «ОТК». В противном случае вы знаете где нужно вносить исправления.
Как-то все очень строго получается…
Такой подход можно применять при написании публичных фреймворков.
На практика в отдельно-взятом приложении может быть оправдана:
очень жесткая связанность в нескольких компонентах
Говнокод в паре классов (быстродействие? другая оправданная негибкость?)
Number Of Classes — много (очень нужна гибкость, достигаемая делегированием и Dependecy Injection)
AHH — см предыдущий пункт
Average Number of Derived classes — см предыдущий пункт
В общем, видимо, утилита полезная, однако метрики, насколько я понимаю дело опасное. Не стоит метриками чрезмерно увлекаться!
Такой подход можно применять при написании публичных фреймворков.
На практика в отдельно-взятом приложении может быть оправдана:
очень жесткая связанность в нескольких компонентах
Говнокод в паре классов (быстродействие? другая оправданная негибкость?)
Number Of Classes — много (очень нужна гибкость, достигаемая делегированием и Dependecy Injection)
AHH — см предыдущий пункт
Average Number of Derived classes — см предыдущий пункт
В общем, видимо, утилита полезная, однако метрики, насколько я понимаю дело опасное. Не стоит метриками чрезмерно увлекаться!
На практика в отдельно-взятом приложении может быть оправдана:
очень жесткая связанность в нескольких компонентах
Говнокод в паре классов (быстродействие? другая оправданная негибкость?)
Number Of Classes — много (очень нужна гибкость, достигаемая делегированием и Dependecy Injection)
AHH — см предыдущий пункт
Average Number of Derived classes — см предыдущий пункт
Безусловно, в каждом проекте есть своя специфика, вы можете ее учитывать и применять исключения из правил.
однако метрики, насколько я понимаю дело опасное. Не стоит метриками чрезмерно увлекаться!
Дело скорее сложное (как на практике выбирать допустимые значения, как учитывать исключения и т.п.), чем опасное. Но примеры «метрик» из других отраслей доказали свою эффективность, что является поводом для оптимизма для софтверной разработки и для развития этого направления. Но, как вы верно заметили, в разумных пределах, конечно.
Интересно что Вы анализиовали, что Cyclomatic Complexity получилась такой большой :)
Дает ли этот инструмент РЕАЛЬНОЕ улучшение работы?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подробнее об анализаторе исходного кода PHP Depend