На практика в отдельно-взятом приложении может быть оправдана:
очень жесткая связанность в нескольких компонентах
Говнокод в паре классов (быстродействие? другая оправданная негибкость?)
Number Of Classes — много (очень нужна гибкость, достигаемая делегированием и Dependecy Injection)
AHH — см предыдущий пункт
Average Number of Derived classes — см предыдущий пункт
Безусловно, в каждом проекте есть своя специфика, вы можете ее учитывать и применять исключения из правил.
однако метрики, насколько я понимаю дело опасное. Не стоит метриками чрезмерно увлекаться!
Дело скорее сложное (как на практике выбирать допустимые значения, как учитывать исключения и т.п.), чем опасное. Но примеры «метрик» из других отраслей доказали свою эффективность, что является поводом для оптимизма для софтверной разработки и для развития этого направления. Но, как вы верно заметили, в разумных пределах, конечно.
Его можно использовать для оценки качества кода на PHP с точки зрения ООП – вы получаете как удобное графическое представление абстрактности/нестабильности пакетов, так и числовые значения, оценивающие наследование, сложность кода, его объем.
С помощью такого инструмента вы быстро получаете характеристики и на основании их значений можете делать определенные выводы. Например, что такой-то модуль нужно переработать.
В идеале вы определяете допустимые интервалы значений характеристик для ваших проектов (делаете таблицу допустимых интервалов) и потом, с целью управления разработкой, вы проверяете попадание в них реальных значений проекта. Если попадают – то код прошел такой объектно-ориентированный «ОТК». В противном случае вы знаете где нужно вносить исправления.
Да, но только если менеджмент ставит задание — сделайте мне вот такую Ж, исправить могут только уж очень прямые руки, а если менеджмент провтыкал все сроки, то уже никакие руки не помогут. Хотя зная какие бывают исполнители, то менеджмент им уже не поможет.
Я имею в виду не конфликт «менеджер-исполнитель», а высказываюсь на тему «какова проблема многих компаний, особенно молодых?» с позицией «изначально она не в менеджменте».
Это тоже мой любимый момент ;)
У него более 4,5 миллионов фолловеров.
Безусловно, в каждом проекте есть своя специфика, вы можете ее учитывать и применять исключения из правил.
Дело скорее сложное (как на практике выбирать допустимые значения, как учитывать исключения и т.п.), чем опасное. Но примеры «метрик» из других отраслей доказали свою эффективность, что является поводом для оптимизма для софтверной разработки и для развития этого направления. Но, как вы верно заметили, в разумных пределах, конечно.
С помощью такого инструмента вы быстро получаете характеристики и на основании их значений можете делать определенные выводы. Например, что такой-то модуль нужно переработать.
В идеале вы определяете допустимые интервалы значений характеристик для ваших проектов (делаете таблицу допустимых интервалов) и потом, с целью управления разработкой, вы проверяете попадание в них реальных значений проекта. Если попадают – то код прошел такой объектно-ориентированный «ОТК». В противном случае вы знаете где нужно вносить исправления.
P.S. PCI = Programming Collective Intelligence
Инфляцию в США по годам смотрел на www.rateinflation.com/inflation-rate/usa-historical-inflation-rate.php?form=usair
Я имею в виду не конфликт «менеджер-исполнитель», а высказываюсь на тему «какова проблема многих компаний, особенно молодых?» с позицией «изначально она не в менеджменте».
Я о том, что сначала нужно учиться программировать, а только потом – менеджерить.