Недавно ко мне в руки попала статья "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 более пластична и менее чувствительна к изменениям в техническом задании. Более того, она гораздо больше приспособлена к инкрементальной разработке, чем первая.
Наверное это все, что я хотел сказать. Засим благодарю коллег за внимание и прошу прокомментировать сказанное автором и сказанное мной.
