OberonCore

В связи с тем, что в некоторых моих модулях блоки IMPORT довольно объёмные и достигают полусотни элементов, пришла мысль - а можно ли судить по длине списка импорта о качестве проектирования модуля и вообще, подсистем?

Можно посчитать ряд метрик. И на основе нечеткого подхода соорудить систему оценки качества по метрикам.
Или на основе нейро-нечеткого подхода.

По-моему, от задачи зависит. Но из общих соображений, наверное, для особо длинного списка импорта стоит поискать обоснование.

По-моему, как ни упирайся, такие оценки будут слишком общие/поверхностные. (В смысле особо сильно упираться не стоит.)

P.S. Анализатор (DevAnalyzer) считает число операторов в модуле; кажется, в док-ии оно в контексте "метрика" упоминалась --- что-то типа возможность (относительно) оценить сложность модуля.

Да, обычно работающим программерам подобные метрики ни к чему. Но это же интереснейшая научная работа!
Снпачала, как тут было в одной теме, набираем факты: считаем метрики и связываем этот набор чисел с нечеткими значениями какого-нить показателя внутреннего качества. Например, модифицируемость. Поскольку экспертов несколько, и наборы метрик считать на многих проектах - собирается более-менее объективная статистика. А потом уже можно забацать систему - и пусть она оценивает, например, курсовой проект или дипломный. А то и тестовое задание при приеме в фирму...

Я бы насторожился при таких списках импорта.
Похоже, что не реализуется "разделяй и властвуй".
Может быть, много мелких модулей.

У меня в некоторых модулях тоже встречались здоровые списки импорта - под три десятка, наверное.
Если модуль несёт верхнюю логику, интегрирует, то ему обычно приходится работать с самыми разными типами объектов - и для всех тащить импорт их определений. Но таких модулей немного обычно, они самого верхнего уровня.

При обучении системы уровень сигнала будет неразличим на уровне шума. Ведь особенности конкретной задачи и личный стиль программиста гораздо существеннее сказываются на значениях метрик, чем качество программирования. Соответственно, выданные системой оценки будут абсолютно случайными. Shit in - shit out. Более того, соответствие программной архитектуры задаче, наличие проблемных мест в алгоритме, правильность выбора структур данных, полнота выявления возможных исключительных ситуаций, степень оптимизации по памяти и по времени - всё это не оценить автоматически рассчитываемыми метриками. Вывод: метрики бесполезны, а автоматизация оценки применима только к совершенно одинаковым задачам - при том, что оцениваются только конечные результаты (память, время) и прохождение множества тщательно сконструированных тестов.

Память и время - это внешнее качество ПО. А есть еще и внутренее... Признаки плохого кода существуют. Одна из первых попыток их как-то обозначить - "запахи" плохого кода в Рефакторинге. Так что обмеривать - возможно. Только это будет нечеткая система, естественно.

Посмотрел у себя -- похоже на то.

"Обмеры" дадут отклонения от усредненного эталона. А если задача сильно отличается от "средней", то "обмеры" покажут, что код "плохой", хотя на самом деле он может быть качественным. Это похоже на критерии женской красоты. Нравится стандартное, среднее по пропорциям и с качественным "материалом" (кожей, волосами, зубами и т.п.). Потом окажется, что красотка глупая, ленивая, эгоистичная, жадная, злобная, скандальная, беспринципная, неряшливая и безвольная. Но "метрики" этого не обнаружили.

Любая гипертрофированная по сравнению с усредненным эталоном часть лица делает его некрасивым - без учета функциональности в новых условиях. Попытка же оценить качество программы по ее "материалам" просто приводит к тривиальному выводу, что необходимо пользоваться "безопасными" подмножествами правильно выбранных языков и соблюдать правила по стилю. Хороший инструментарий (семантический редактор) автоматически улучшит качество "материалов" до теоретического максимума. А вот качество программной архитектуры не оценить никакими внутренними метриками.

Здесь, скорее, как со стат. отбором: есть ошибка пропустить ненужное, и есть ошибка отвергнуть нужное.
Только здесь речь, видимо, не о том, чтобы отвергнуть, а о том, когда смотреть глазами.

То есть если проблема в массовой проверке модулей, то с помощью метрик можно пытаться отлавливать что-то аномальное и подвергать оное спец. анализу, который слишком дорого делать для всего.

Не очень понятно, где это может быть нужно.

Коллеги, сейчас ведь никто не спорит о том, что паттерны в программировании нужны. Но ведь было время, когда большинство считало, что паттерны убивают творчество.
Так и с обмером и архитектурой. Просто еще нет опыта оцифровки подобных вещей. Когда-то и мосты строили на глазок.
Обмеры возможны, но нужно набирать статистику.
Естественно, что в разных сферах мы получим разную статистику. Но, например, обмеры типичных программистких курсовых работ могут быть очень полезны. Например, для выявления плагиата.

Да-да-да. Как с психологическим тестированием (Myers-Briggs etc.). Испробовать тысячи вопросов на статистике во многие десятки К, чтобы оставить сотню вопросов и полтора десятка категорий.

Другое дело, что ПО не так четко разделено на единицы, как люди

Почти бессодержательное утверждение если речь о паттернах вообще. И почти неверное утверждение если речь о каком-то одном ограниченном наборе паттернов раз и навсегда описанных некоторой одной группой авторов.