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

Оригинал

Сложность является основной проблемой при разработке больших информационных систем. Следуя Бруксу мы различаем случайную (accidental) и существенную (essential) сложности, но не разделяем его мнения, что в современных системах в основном осталась только существенная сложность. Мы изучили основные источники сложности и предлагаем общие подходы, позволяющие исключить случайную сложность. Конкретнее мы предлагаем подход минимизирующий сложность и основанный на функциональном программировании и реляционной модели данных Эдгара Кодда.

Введение

Кризис информационных технологий был зафиксирован впервые в 1968 году и в дальнейшем лишь усугублялся. Основная проблема разработки и поддержки больших систем это сложность - большие системы очень трудно понимать. По нашему мнению основным источником сложности в большинстве систем является управление состоянием (handling state) и сложность их анализа и понимания. Другими причинами являются объем кода и явное управление потоком выполнения.

Сегодня основными подходоми к управлению состоянием являются:

• объектно-ориентированное программирование, которое ведет к тесной связи состояния и поведения
• и функциональное программирование - которое в своих чистых формах вовсе избегает состояния и остаточных явлений (side effects)

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

Сложность

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

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

Актуальность проблемы сложности хорошо известна. Как говорит Дейкстра:

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

Проведенные экономистами исследования показали, что в экономике США убытки из-за проблем с информационными системами составляют приблизительно около $59 биллионов долларов ежегодно.

Способность понимать и изменять информационные системы критически важна. Опасность сложности и важность простоты стала популярной темой в заслуженных лекциях Фернандо Корбато:

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

В 1977 Бакус, говоря о сложностях и слабостях традиционных языков, заметил:

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

Во время своей речи при вручении награды Тюринга в 1989 Хоар сказал:

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

И это к сожалению правда - Добиться простоты сложно.

Но одна из целей этой статьи дать некоторые причины для оптимизма.

Два способа понимания

Мы уже говорили, что основная угроза от сложности это ее влияние на понимание системы. Поэтому интересно рассмотреть механизмы этого понимания:

• Черный ящик - когда мы смотрим на систему снаружи и заключаем о ней на основании наблюдения за ее поведением

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

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

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

Так же O’Keefe ("поймите свою проблему" и "элегантность не прихоть"):

Нашим ответом на ошибки должен быть поиск способов их избежать, а не жалобы на природу вещей!

Ключевая проблема с тестами, это то что если они проходят на одном наборе данных, абсолютно не означает, что система будет корректно работать с другим набором данных. Огромное количество возможных входных данных не позволяет протестировать их все. Поэтому единственное в чем вы можете быть уверены - это негативное знание, что система работает не корректно.

И опять Дейкстра:

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

Это не значит, что тестирование не должно использоваться. Подводя итог можно сказать, что все попытки понимания системы имеют свои ограничения: * неформальные - ограничены в объеме и точности * формальные - зависят от точности спецификации. Поэтому нужно пользоваться обоими подходами.

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

Четыре основные причины сложности

В любой нетривиальной системе есть сложность унаследованная от проблемы, которую система решает. Однако в реальных крупных системах мы часто сталкиваемся со сложностью, в происхождении которой можно усомниться.

Сложность связанная с состоянием.

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

Когда мы сталкиваемся с состоянием мы вынуждены согласиться с Бруксом:

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

Влияние состояния на тестирование

Продолжение следует...

06 Feb 2014 niquola