Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/03f27.shtml

ФАКТ 01

Факт 27
       Лучшее проектное решение задачи программирования редко бывает единственным.

Обсуждение
       В данной формулировке два ключевых слова: единственное и лучшее.
       Для большинства задач в программировании можно найти несколько решений. Это по поводу слова единственное. А уж узнать, является ли найденное решение "лучшим", даже если бы оно было единственным, крайне трудно. Это по поводу слова лучшее.
       Этот факт немного обескураживает, но, пожалуй, не очень удивляет. Маловероятно, что группа хороших проектировщиков, решая некую задачу, придет к одному и тому же оптимальному решению. (Одно из любимых мною высказываний о программистах звучит так: "Если в комнате сидят несколько классных проектировщиков ПО и двое из них согласны друг с другом, то они образуют большинство".) Вспомните, что говорилось в предыдущих фактах о сложности процесса решения и лавинообразном росте требований в процессе проектирования. Все это наводит на мысль, что проектирование - это сложный и запутанный процесс - процесс, в котором не прибегают к простым или безусловно не лучшим методам решения.
       Данное наблюдение не добавляет оптимизма, ведь было бы просто здорово, если бы все заботы проектировщиков ограничивались тем, чтобы искать решение, пока не отыщется лучшее. (Конечно, если они никогда его не найдут, то задача так и не будет решена корректно.)
       Рассмотрим этот факт в контексте одного из принципов экстремального программирования. Экстремальное программирование предлагает выбирать максимально простые проектные решения. Данный факт не противоречит этому принципу, но означает, что многие задачи не будут иметь подобного простого решения (Факт 28, в котором речь идет о сложности проектирования, лишь утверждает нас в этом мнении). Однако рассматриваемый подкрепляет этот принцип экстремального программирования и другим образом. Если лучшего проектного решения нет, то простое решение, найденное в рамках экстремального программирования, может быть настолько же удачным, как и любое другое (если только простое при этом не превращается в упрощенное).

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

Источники
       Любимую мной, приведенную выше фразу: "Если комната заполнена классными проектировщиками ПО..." на одной из конференций по технологии программирования произнес Билл Кертис (Bill Curtis).
       Пожалуй, лучшие материалы на тему проектирования вообще и о данном факте в частности подготовлены Кертисом и его коллегами в исследовательской компании МСС (Концерн микроэлектроники и компьютеров), а также Эллиоттом Соловьем (Elliott Soloway) и его коллегами из Йельского университета более десяти лет назад. В то время обе группы изучали лучшие практические методы проектирования. Команда Кертиса, во всяком случае, занималась этим, надеясь создать набор инструментов для поддержки и, может быть, даже автоматизации процесса проектирования, который они обозначили в своем исследовании. К сожалению, обе группы пришли к выводу, что процесс проектирования оппортунистичен (вызывает ассоциации с массой значений, при этом одно из них трактуется как противоположность методичности или предсказуемости), но они имели в виду, что создать подобный набор средств почти не представляется возможным. Мне неизвестно, чтобы какие-нибудь исследователи попытались согласовать свои усилия в данной области после завершения проектов Кертиса и Соловья.
       — Curtis, В., R. Guindon, Н. Krasner, D. Walz, J. Elam, and N. Iscoe. 1987. empirical Studies of the Design Process: Papers for the Second Workshop on Empirical Studies of Programmers". MCC Technical Report Number STP-260-287.
       — Soloway, К, J. Spohrer, and D. Littman. 1987. "E Unum Pluribus- Generating Alternative Designs". Dept of Computer Science, Yale University.


<<< Пред. Оглавление
Glass Robert L.
Начало раздела
След. >>>



<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/03f27.shtml