Чем хуже, тем лучше

редактировать

Чем хуже, тем лучше, также называется Нью-Джерси стиль, был задуман Ричардом П. Гэбриэлем в эссе «Чем хуже, тем лучше» для описания динамики принятия программного обеспечения, но имеет более широкое применение. Это относится к утверждению, что качество не обязательно увеличивается с функциональностью - что есть точка, где меньшая функциональность («хуже») является предпочтительным вариантом («лучше») с точки зрения практичности и удобства использования. Программное обеспечение, ограниченное, но простое в использовании, может быть более привлекательным для пользователя и рынка, чем наоборот.

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

Эссе было включено в книга 1994 г. Справочник ненавистников Unix.

Содержание
  • 1 Источник
  • 2 Описание
    • 2.1 Подход MIT
  • 3 Эффекты
  • 4 См. также
  • 5 Ссылки
  • 6 Внешние ссылки
Происхождение

Габриэль был программистом на Лиспе, когда сформулировал эту концепцию в 1989 году, представив ее в своем эссе «Лисп: хорошие новости, плохие новости, как победить». Большой ». Раздел статьи, озаглавленный «Возникновение« хуже тем лучше »», получил широкое распространение, начиная с 1991 года, после того, как Джейми Завински нашел его в файлах Габриэля на Lucid Inc. и разослал его друзьям и коллегам по электронной почте.

Описание

Габриэль утверждал, что «Хуже того лучше» - это модель разработки и реализации программного обеспечения, которая имеет следующие характеристики (примерно в порядке убывания важности):

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

Габриэль утверждал, что ранние Unix и C, разработанные Bell Labs, являются примерами такого подхода к проектированию. Он также называет их «абсолютными компьютерными вирусами».

Подход MIT

Габриэль противопоставил свою философию тому, что он назвал «стилем дизайна MIT / Stanford» или «подходом MIT » (также известным как «Правый Вещь »), которую он описал следующим образом. Контрасты выделены жирным шрифтом:

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

Габриэль утверждал, что «Чем хуже, тем лучше» получается более успешное программное обеспечение, чем подход MIT: пока исходная программа в основном хороша, она будет на первоначальную реализацию потребуется гораздо меньше времени и усилий, и будет легче адаптироваться к новым ситуациям. Например, таким образом становится намного проще переносить программное обеспечение на новые машины. Таким образом, его использование будет быстро распространяться задолго до того, как программа, разработанная с использованием подхода MIT, получит шанс быть разработанной и развернутой (преимущество первопроходца ). Как только он распространился, возникнет необходимость улучшить его функциональность, но пользователей уже приучили принимать «худшее», а не «правильное». «Таким образом, программное обеспечение« хуже-лучше-лучше »сначала получит признание, во-вторых, заставит пользователей ожидать меньшего, а в-третьих, будет улучшено до такой степени, что это почти правильно. Конкретно, даже несмотря на то, что Lisp компиляторы в 1987 году были примерно так же хороши, как компиляторы C, гораздо больше экспертов по компиляторам, которые хотят сделать компиляторы C лучше, чем хотят сделать компиляторы Lisp лучше ».

Gabriel credits Джейми Завински за отрывки из «Лиспа: хорошие новости, плохие новости, как добиться большого успеха» о том, что хуже-лучше, и за отправку их по электронной почте своим друзьям в Университете Карнеги-Меллона, которые отправили их своим друзьям в Bell Labs, «которые отправляли их повсюду своим друзьям». Он, очевидно, соединил эти идеи с идеями Ричарда Столлмана и увидел связанные идеи, которые важны в философии проектирования Unix и в более общем плане движения за открытый исходный код, оба из которых сыграли центральную роль в разработке Linux.

Габриэль позже ответил на свое более раннее эссе эссе под псевдонимом «Никибен Бурбаки» (намек на Николя Бурбаки ).

См. Также
Ссылки
Внешние ссылки
Последняя правка сделана 2021-06-21 05:21:11
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте