Количество «страниц» или «областей», к которым у пользователей будет доступ
Проблема : Эту проблему можно решить, разделив части на разные страницы или разделы, когда было бы гораздо разумнее объединить их в единый интерфейс «центра управления».
Количество классов
Задача : Это не учитывает сложность (или простоту) некоторых классов по сравнению с другими. У вас может быть один класс, который содержит два свойства и метод, в то время как другой класс может быть хардкорным.
Количество таблиц без поиска
Проблема : Это не будет учитывать сложность вашего программного обеспечения, а только уровень данных, на котором оно лежит. Некоторые из тех же проблем, связанных с количеством классов, также могут быть применены здесь с точки зрения того, что некоторые таблицы являются более сложными, чем другие.
Строки кода
Проблема : Это довольно стандартная метрика, но она придает гораздо более позитивный оттенок программам с большим количеством строк вместо поощрения более эффективного и элегантного кода.
Сколько человеко-часов ушло на разработку
Проблема : Нет двух разработчиков, имеющих одинаковые наборы навыков, и никакие два разработчика, вероятно, не будут тратить одинаковое количество времени (или следовать по одному и тому же пути), когда дело доходит до создания часть программного обеспечения. Таким образом, одному разработчику может потребоваться столько же времени, сколько команде из 3 менее квалифицированных / опытных разработчиков, чтобы набрать одинаковое количество кода. Кроме того, весь «Мифический человеко-месяц» может начать поднимать голову, если вы начнете привлекать к проблеме больше людей, чем это действительно необходимо.
В целом, я думаю, что самая большая проблема с метриками заключается в том, что они пытаются измерить некоторое количественное свойство программного обеспечения, когда в действительности программное обеспечение имеет качество вместо количество , и это где метрики действительно терпят неудачу.