Comments 3
Как измерить каждый параметр? Какое значение ок, а какое не ок? Что делать, если не ое? Как отличить каждый перечисленный *able от not *able? На глазок? На чей глазок? Почему его?
Ну это уже более детальный уровень. Я сегодня говорил про общий подход. А если в деталях, то каждую метрику нужно обсуждать и можно по каждой отдельный текст писать. Кроме того, там все очень индивидуально и зависит от компании, объема, качества и истории кода и т.д.
По моему мнению, вопрос предыдущего комментатора справедлив: до того, как обсуждать реализацию метрик в деталях, нужно понять: а они вообще реализуемы?
Загвоздка состоит в том, что в этой статьи перечислены свойства (желаемые) проекта, которые, во-первых, имеют только качественное описание, а во-вторых - сильно зависят от многих других параметров (например от квалификации и привычек коллектива разработчиков). А метрики - это все-таки числа, измеряемые по более-менее стандартизированным процедурам, эти параметры не учитывающим.
К примеру, настоящие программисты (те самые, которые не используют Паскаль ) будут работать эффективно по опредлению, не обращая внимания на метрики ;-) .
Мысли о разумном Maintainability в этом несовершенном мире