В этой статье слишком много ссылок на первоисточники . ( Октябрь 2011 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения ) |
Чем хуже, тем лучше (также называемый стилем Нью-Джерси [1] ) - термин, придуманный Ричардом П. Габриэлем в одноименном эссе для описания динамики принятия программного обеспечения. Это относится к аргументу о том, что качество программного обеспечения не обязательно повышается с функциональностью: есть точка, где меньшая функциональность («хуже») является предпочтительным вариантом («лучше») с точки зрения практичности и удобства использования. Программное обеспечение, ограниченное, но простое в использовании, может быть более привлекательным для пользователя и рынка, чем наоборот.
Что касается оксюморонического названия, Габриэль называет его карикатурой, заявляя, что стиль плохой по сравнению с "The Right Thing". Однако он также заявляет, что «у него лучшие характеристики выживания, чем у правильного» стиля разработки, и он превосходит «подход Массачусетского технологического института», которому он противопоставил его. [2]
Эссе было включено в книгу 1994 года The UNIX-HATERS Handbook и упоминается как создатель концепции концептуального разделения между разработчиками на восточном и западном побережьях Соединенных Штатов. [3]
Происхождение [ править ]
Габриэль был программистом на Лиспе, когда сформулировал эту концепцию в 1989 году, представив ее в своем эссе «Лисп: хорошие новости, плохие новости, как добиться большого успеха». Раздел статьи, озаглавленный «Рост« хуже тем лучше »», получил широкое распространение с 1991 года, после того как Джейми Завински нашел его в файлах Габриэля в Lucid Inc. и отправил по электронной почте друзьям и коллегам. [2]
Характеристики [ править ]
Стиль Нью-Джерси [ править ]
В книге «Чем хуже тем лучше» Габриэль утверждал, что «Хуже того лучше» (также «стиль Нью-Джерси» или «восточное побережье» [3] ) - это модель разработки и реализации программного обеспечения, которая имеет характеристики (примерно в порядке убывания важности):
- Простота
- Дизайн должен быть простым как по реализации, так и по интерфейсу. Более важно, чтобы реализация была простой, чем интерфейс. Простота - самое важное в дизайне.
- Правильность
- Дизайн должен быть правильным во всех наблюдаемых аспектах. Лучше быть простым, чем правильным.
- Последовательность
- Дизайн не должен быть чрезмерно противоречивым. В некоторых случаях согласованностью можно пожертвовать ради простоты, но лучше отказаться от тех частей дизайна, которые имеют дело с менее распространенными обстоятельствами, чем вносить сложность или непоследовательность в реализацию.
- Полнота
- Дизайн должен охватывать как можно больше важных ситуаций. Должны быть охвачены все разумно ожидаемые случаи. Полнотой можно пожертвовать в пользу любого другого качества. Фактически, нужно пожертвовать полнотой всякий раз, когда ставится под угрозу простота реализации. При сохранении простоты можно пожертвовать согласованностью для достижения полноты; особенно бесполезна единообразие интерфейса.
Подход MIT [ править ]
Габриэль противопоставил свою философию тому, что он назвал «стилем дизайна MIT / Stanford» или « подходом MIT » (также известным как подход «западного побережья» [3] или «правильная вещь»), который он описал как:
- Простота
- Дизайн должен быть простым как по реализации, так и по интерфейсу. Более важно, чтобы интерфейс был простым, чем реализация.
- Правильность
- Дизайн должен быть правильным во всех наблюдаемых аспектах. Некорректность просто недопустима.
- Последовательность
- Дизайн должен быть последовательным. Допускается, чтобы дизайн был немного менее простым и менее полным, чтобы избежать несогласованности. Последовательность так же важна, как и правильность.
- Полнота
- Дизайн должен охватывать как можно больше важных ситуаций. Все разумно ожидаемые случаи должны быть покрыты. Простота не должна чрезмерно снижать полноту.
Габриэль утверждал, что ранние версии Unix и C , разработанные Bell Labs , являются примерами подхода к проектированию «хуже - значит лучше». Он также называет их «абсолютными компьютерными вирусами».
Эффекты [ править ]
Габриэль утверждал, что «Чем хуже, тем лучше» создает более успешное программное обеспечение, чем подход MIT: до тех пор, пока исходная программа в основном хороша, для ее реализации на начальном этапе потребуется гораздо меньше времени и усилий, и будет легче адаптироваться к новым ситуациям. Например, таким образом становится намного проще переносить программное обеспечение на новые машины. Таким образом, его использование будет быстро распространяться задолго до того, как программа, разработанная с использованием подхода MIT, получит шанс быть разработанной и развернутой ( преимущество первопроходца ). Как только он распространится, возникнет необходимость улучшить его функциональность, но пользователи уже были приучены принимать «худшее», а не «правильное»: [4]
Таким образом, программное обеспечение «хуже-лучше-лучше» сначала получит признание, во-вторых, заставит пользователей ожидать меньшего, а в-третьих, будет улучшено до такой степени, что это почти правильно. Конкретно, хотя компиляторы Lisp в 1987 году были примерно так же хороши, как компиляторы C, гораздо больше экспертов по компиляторам хотят сделать компиляторы C лучше, чем хотят сделать компиляторы Lisp лучше.
Габриэль благодарит Джейми Завински за то, что он взял разделы «Лисп: хорошие новости, плохие новости, как добиться большого успеха» и отправил их по электронной почте своим друзьям из Университета Карнеги-Меллона , которые отправили их своим друзьям в Bell Labs. , "которые отправляли их своим друзьям повсюду". [5] Он, по-видимому, связал эти идеи с идеями Ричарда Столлмана и увидел связанные идеи, которые важны для философии проектирования Unix и, в более общем смысле, для движения за открытый исходный код , оба из которых были центральными в развитии Linux .
В декабре 2000 года Гавриил ответил на его раннее сочинение с одним названием хуже , тем лучше хуже [6] под псевдонимом «Nickieben Бурбаки» (намек на Николя Бурбаки ), в то же время сочиняя хуже действительно лучше? , применяя эту концепцию к успеху C ++ в области объектно-ориентированного программирования, несмотря на существование более элегантных языков, разработанных на основе этой концепции. [7]
Справочник UNIX-HATERS включает в себя приложение « Чем хуже, тем лучше» , и формулирует концепцию с точки зрения «хуже - значит лучше» в форме того, что Unix «эволюционно превосходит» своих конкурентов. [8]
См. Также [ править ]
- Минимально жизнеспособный продукт
- Меньше - больше
- Идеальное - враг хорошего
- Прогрессивное раскрытие
- Удовлетворительный
- Философия Unix
Ссылки [ править ]
- ^ Лучше хуже, чем лучше.
- ^ a b Чем хуже, тем лучше, Ричард П. Габриэль
- ^ a b c Хуже того, Джим Уолдо, инженер Sun Microsystems
- ^ Лисп: хорошие новости, плохие новости, как выиграть по-крупному, Ричард П. Габриэль
- ^ Даниэль Вайнреб . «Идея« Чем хуже, тем лучше »и будущее Lisp») . Архивировано из оригинала на 11 июня 2009 года.
- ^ Хуже лучше хуже (PDF), Ричард П. Габриэль , как «Nickieben Бурбаки»
- ^ На самом деле хуже, чем лучше, Ричард П. Габриэль
- ^ Крейнин, Йоси (11 августа 2012). «Что на самом деле значит« Хуже лучше против правильного »» . Правильная фиксация . Проверено 24 ноября 2018 .