Недавно ко мне в руки попала статья "Lisp: Good News, Bad News, How to Win Big." (Richard P. Gabriel, AI Expert, 1991)

В ней автор рассказывает о двух традициях дизайна программного обеспечения, автор называет их условно "the right thing" и "worse-is-better". Далее я привожу пару цитат из статьи, в которых автор характеризует основные особенности каждой из этих традиций.

The right thing.

- Simplicity—the design must be simple, both in implementation and
interface. It is more important for the interface to be simple than that
the implementation be simple.
— Correctness—the design must be correct in all observable aspects.
Incorrectness is simply not allowed.
— Consistency—the design must not be inconsistent. A design is
allowed to be slightly less simple and less complete to avoid inconsistency.
Consistency is as important as correctness.
— Completeness—the design must cover as many important situations
as is practical. All reasonably expected cases must be covered.
Simplicity is not allowed to overly reduce completeness.

Worse-is-better.

- Simplicity—the design must be simple, both in implementation and
interface. It is more important for the implementation to be simple
than the interface. Simplicity is the most important consideration in
a design.
— Correctness—the design must be correct in all observable aspects. It
is slightly better to be simple than correct.
— Consistency—the design must not be overly inconsistent. Consistency
can be sacrificed for simplicity in some cases, but it is better to
drop those parts of the design that deal with less common circumstances
than to introduce either implementational complexity or
inconsistency.
— Completeness—the design must cover as many important situations
as is practical. All reasonably expected cases should be covered.
Completeness can be sacrificed in favor of any other quality. In fact,
completeness must be sacrificed whenever implementation simplicity
is jeopardized. Consistency can be sacrificed to achieve completeness
if simplicity is retained; especially worthless is consistency
of interface.

Далее в статье говорится о том, что у worse-is-better есть много недостатков, но он более приспособлен к жизни, чем the right thing (после чего идут апокалиптические рассуждения о 1995-ом годе как о годе финальной победы Unix и C++...)

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

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

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

Очевидно, что система построенная по принципу worse-is-better более пластична и менее чувствительна к изменениям в техническом задании. Более того, она гораздо больше приспособлена к инкрементальной разработке, чем первая.

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

Здравствуйте, sch, Вы писали:

sch>Наверное это все, что я хотел сказать. Засим благодарю коллег за внимание и прошу прокомментировать сказанное автором и сказанное мной.

Я делю задачи на два типа: прикладные задачи и задачи, обеспечивающие работу прикладных задач. Второй тип — это библиотеки, фреймворки, компиляторы и т.п. Пока не могу подобрать правильное обобщённое название.

Не всегда можно (да и нужно) добиваться простоты задач второго типа. Главное, чтобы они обеспечивали простоту реализации задач первого типа.

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

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

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

Здравствуйте, sch, Вы писали:

sch>The right thing.
sch>Worse-is-better.

sch>К сожалению, автор не потрудился дать удовлевотворительного доказательства этому утверждению, которое, кстати говоря, лично для меня интуитивно-понятно и принято как правильное.

sch>Очевидно, что система построенная по принципу worse-is-better более пластична и менее чувствительна к изменениям в техническом задании. Более того, она гораздо больше приспособлена к инкрементальной разработке, чем первая.

ИМХО, right thing не может появиться сама по себе из ничего. Right thing это следствие тчательного анализа и последующего удачного синтеза. Которому предшествует не одна итерация в стиле worse-is-better.

Предположим, что нам нужно взять данные A и преобразовать их в B. Делаем. Нам кажется, что у нас получается решение в стиле right thing. Проходит время и выясняется, что короме B нужное еще делать B1, B2, ..., Bn. Модифицируем. Получаем уже не такой right thing, но еще и не worse-is-better. Затем оказывается, что кроме A еще нужно учитывать A1, A2, ..., Am. Учитываем. Еще дальше ушли от right thing. Выясняется, что кроме Bi нужно еще и C делать. Делаем. Затем узнаем, что кроме Aj на входе может быть и D. Еще раз переделываем. Имеем полный и жестокий worse-is-better. Но тут, взглянув на полученный результат с высоты накопленного опыта и выкурив некоторое количество ядреной травы мы обнаруживаем, что есть совсем другой способ решения этих задач, который и является right thing. Ура, мы нашли его! Отныне для классов задач с Aj, Dk на входе и Bi,Cl на выходе есть right thing решение и правильный, оптимальный, минималистический дизайн. Плохо то, что решений в этой области и так накоплено очень много, можно выбирать на любой вкус и цвет. Да только выбирать-то и не за чем. Большинство подобных задач уже решено.

А в это время, совсем в другой области появляется задача взять на вход данные F и получить на выходе J. Как это делать никто не знает. Кто-то берется и делает решение. Пока это right thing. До тех пор, пока не выясниться, что кроме J есть еще и J1, J2, ..., Jn...

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