Как вы оцениваете сложность дизайна, оценивая его?

Если ваше приложение создано, вы можете измерить его с точки зрения времени (сколько времени потребуется для выполнения конкретной задачи) или вычислений (сколько кода выполняется каждый раз при запуске задачи).

Если у вас есть только проекты, вы можете посмотреть, сколько компонентов вашего дизайна необходимо для выполнения данной задачи или для выполнения средней задачи. Например, если вы используете MVC в качестве шаблона проектирования, то для большинства задач задействовано как минимум 3 компонента, но в зависимости от реализации дизайна у вас могут появиться десятки компонентов (кеш в дополнение к 3 слоя, например).

Вот мои:

1) Насколько сложно объяснить кому-то, кто понимает проблему, но не думал о ее решении? Если я объясню проблему кому-то в зале (который, вероятно, уже понимает проблему, если он находится в зале) и могу объяснить решение, то это не слишком сложно. Если на это уйдет больше часа, велика вероятность, что решение слишком продумано.

2) Насколько глубоко нужно углубляться во вложенные функции? Если у меня есть объект, которому требуется свойство, принадлежащее объекту, принадлежащему другому объекту, то велики шансы, что то, что я пытаюсь сделать, слишком далеко от самого объекта. Эти ситуации становятся проблематичными при попытке сделать объекты потокобезопасными, потому что будет много объектов разной глубины от вашего текущего положения для блокировки.

3) Вы пытаетесь решить проблемы, которые уже были решены ранее? Не все проблемы новы (и некоторые утверждают, что на самом деле нет). Есть ли какой-либо шаблон или группа шаблонов, которые вы можете использовать? Если не можешь, почему бы и нет? Придумывать собственные новые решения - это хорошо, и я полностью за это, но иногда люди уже решили проблему. Я не собираюсь переписывать STL (хотя в какой-то момент я пробовал), потому что решение уже существует, и оно хорошее.

Когда я посетил семинар по моделированию сложных систем в Институте сложных систем Новой Англии (http://necsi.org/), одной из мер, которые они использовали, было количество состояний системы.

Например, если у вас есть два взаимодействующих узла, A и B, и каждый из них может иметь значение 0 или 1, ваши возможные состояния:

A B
0 0
1 0
0 1
1 1

Таким образом, система только одного взаимодействия между компонентами бинарной системы может фактически привести к 4 различным состояниям. Дело в том, что сложность системы не обязательно увеличивается линейно с увеличением числа взаимодействий.

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

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

Примеры:

.- файлы свойств, конфигурация базы данных, файлы xml для хранения связанной информации.

.- десятки тысяч классов с интерфейсами и отображениями баз данных

.- очень длинный и сложный файл сборки (build.xml, Makefile, другие ..

Есть формальные метрики. Прочтите, например, Цикломатическая сложность.

Редактировать.

Также посмотрите Функциональные точки. Они дают вам не интуитивно понятное количественное измерение сложности системы.

Наконец то, что LOC действительно может помочь в измерении? :)

Я думаю, что сложность лучше всего рассматривать как количество вещей, которые должны взаимодействовать.

Сложный дизайн будет иметь n ярусов, тогда как простой дизайн будет иметь только два.

Сложность является необходима для решения проблем, которые простота не может преодолеть, поэтому это не всегда будет проблемой.

Существует проблема с определением сложности в целом, поскольку со сложностью обычно связана задача. Что-то может быть сложным для понимания, но простым для восприятия (например, очень сжатый код) Количество взаимодействий, передающих эту веб-страницу с сервера на ваш компьютер, очень сложно, но абстракция протокола http очень проста.

Таким образом, наличие задачи (например, техническое обслуживание) перед выбором меры может сделать ее более полезной. (т.е. добавление файла конфигурации и ведение журнала в приложение увеличивает его объективную сложность [да, только немного], но упрощает обслуживание).