2010-09-19

Сложность

Большинство систем построены по принципу "так уж исторически сложилось". Все связано со всем, чтобы что-то переделать надо все разобрать, потом все собрать. Сломалось одно - не работает ничего. Чтобы добавить фичу, надо поправить все файлы. Сложность растет как экспонента от количества фич. В какой-то момент добавить уже ничего нельзя, все ломается, мало кто понимает как оно работает, проще написать заново, чем переделать. Назовем это мултипликативной, или экспоненциальной сложностью.

Более умный подход состоит в разработке инфраструктуры, когда отдельные фичи могут добавляться независимо. Хороший пример: кодеки видео или аудио. Или приложения для iphone. Есть базовая система, а остальное - приложения. Это аддитивная или линейная сложность. Проблема приложения - это его проблема. На другие приложения это не влияет.

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

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

Проще всего второй, линейный подход. Пусть все пишут кодеки, фильтры, плагины, приложения. С простым интерфейсом к нашей системе. Мы даже специально можем ограничить или предотвратить взаимодействие таких плагинов-приложений. Чтобы их связи не создавали мультипликативной сложности. Пользователю тоже все понятно. Фича - приложение, видео формат - кодек.

Это в точности то, что делает Apple в iOS. Приложения никак между собой не взаимодействуют, кроме самого минимума. Эплу так проще сохранять контроль над системой, хотя нам это и не всегда удобно. А Микрософт в своем WP7 решил попробовать поиграть в логарифмические игры, которые, как мы знаем, кончаются экспонентой. Посмотрим, посмотрим.

3 comments:

SKuznetsov said...

Ложность сложности.
Существует ЦПТ о стремлении к нормальному закону распределения суммы многих независимых случайных величин. Аналогично бардак в системе нарастает от "независимых" изменений. Если продумана стратегия развития системы, специфицированы свойства и интерфейсы блоков, и определены полномочия разработчиков каждого уровня, то бардака нет при любой внутренней организации системы. За это отвечает архитектор системы. Вроде как FreeBSD стремится не выпускать вожжи...

Valery Tolkov said...

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

SKuznetsov said...

Встреча парадигмы с реальностью всегда заканчивается смертью парадигмы - либо от старости, либо от раковых изменений. Вопрос в потомстве.