Что такое самоуверенное программное обеспечение?

Ответ 1

Если структура упрямна, она блокирует или направляет вас к их способу делать вещи.

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

Другой пример (взятый из ссылки на сигналы), относится к wiki. У дизайнеров вики было много мнений. Они считали, что HTML слишком сложный для людей, чтобы писать, поэтому они придумали то, что, по их мнению, было более естественным способом обновления контента. Они также лишили его причудливого дизайна, потому что они чувствовали, что фокус должен быть больше на содержании, чем на дизайне.

У Apple есть сильные мнения, когда он разрабатывает свои продукты.

Непринужденный дизайн программного обеспечения больше похож на PERL/PHP. Это позволяет разработчику и надеется, что разработчик примет правильные решения и поставит больше контроля в свои руки.

Я бы также поставил Microsoft в колонку, не связанную с этим. Хороший пример среды Microsoft, которая не рассматривается: .NET. Открыв CLR и спецификации, он открыл его для всех видов языков и стилей реализаций.

Ответ 2

Мнение программного обеспечения означает, что есть в основном один способ ( правильный путь и торговля;) делать что-то, и попытки сделать это по-другому будут сложными и расстраивающими. С другой стороны, делая вещи правильный путь & trade; может очень легко развиваться с помощью программного обеспечения, так как количество решений, которые вы должны сделать, уменьшается, а способность разработчиков программного обеспечения концентрироваться на работе с программным обеспечением увеличивается. Мнение программного обеспечения может быть здорово использовать, если все будет хорошо, если ваша проблема хорошо отобразится в решении. Это может быть реальной болью для решения тех частей вашей проблемы, которые не отображаются на предоставляемые инструменты. Примером здесь может быть Ruby on Rails.

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

Мой идеал - это ненавязчивая структура, но с сильными соглашениями. Я бы поставил ASP.NET MVC в эту категорию. На самом деле все программное обеспечение в некоторой степени усугубляется (хотя, возможно, и не PERL). MVC имеет сильные соглашения в своем выборе модели, но предлагает множество различных способов решения проблем в рамках этих конвенций. Некоторые из этих способов могут даже нарушить модель. Правильное использование, однако, в соответствии с конвенциями, развивающимися в таких рамках, может быть настоящей радостью.

Ответ 3

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

Rails, вероятно, является каноническим примером укрупненной структуры: вы делаете все по-своему, и все гладко. Если вы этого не сделаете, у вас будет какая-то боль. Но это нормально - если вы не хотите делать что-то по-своему, вы не хотите использовать Rails.

Ответ 4

Для баланса я дам (довольно упрямое) описание, более благоприятное для упрямого подхода (в отличие от некоторых других ответов).

Мнение разработанных рамок обеспечивает "золотой путь", который, как предполагается, является наилучшей практикой для большинства людей и большинства сценариев (в глазах авторов).

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

Менее самоуверенные рамки предоставляют множество различных вариантов и оставляют за собой решение.

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

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

Ответ 5

Мнение программного обеспечения построено и спроектировано таким образом, что это позволяет сделать что-то определенным образом. Это способствует некоторым шаблонам проектирования больше, чем другим. В этом процессе трудно уклониться от стиля разработки программного обеспечения, для которого он был разработан. Другой способ сказать, что он одобряет "Конвенцию по конфигурации". то есть параметры конфигурации очень ограничены, поскольку программное обеспечение предполагает многие аспекты конфигурации. Мнение программного обеспечения, как правило, быстрее освоить после понимания предположений.

Неопроверенное программное обеспечение, с другой стороны, делает несколько предположений. И, как следствие, рамки разработки программного обеспечения/программного обеспечения, которые не используются, часто имеют множество вариантов конфигурации. Разработчик обычно должен принимать множество решений в отношении различных аспектов программного обеспечения. Часто разрабатываются различные инструменты, чтобы облегчить доступ к этим огромным возможностям. например Visual Studio.NET для .NET, Eclipse IDE для Java и т.д. Незапрошенное программное обеспечение, как правило, занимает больше времени, чем упрямое программное обеспечение.

Ответ 6

Многие люди ссылаются на ASP.NET MVC как на "unopinionated" framework, и я просто хотел взвесить пару соображений по этому поводу.

Верно, что ASP.NET MVC не требует слишком многого; вы можете использовать любое решение для сохранения, которое вам нравится, будь то Linq-to-SQL, ADO.NET Entities, NHibernate и т.д.

С другой стороны, структура MVC, как правило, предпочитает "соглашение по конфигурации", чтобы процитировать Фила Хаака, который в значительной степени предлагает следовать заданному шаблону для определения контроллеров, представлений, моделей и другого кода. Хотя вы можете изменить это поведение, вам легче плавать с текущим, а для большинства людей нет проблем с этим.

Также окружающие ASP.NET MVC - это много людей, склонных к самоуверенности, которые, как мне кажется, приводят к множеству предвзятых учебников, которые настаивают на покрытии, например. модульное тестирование и инъекция зависимостей; Я все для хорошего тестирования и разделения проблем, но я понимаю, что такие темы немного сбиты одним горлом, часто опережая более полезные основы.

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

Ответ 7

Это количество соглашений, реализованных в фреймворке и количество принятых решений.

Если, например, существует 5 (или более) разных способов отправки данных формы в действие контроллера (что имеет место в ASP.NET MVC), структура кажется довольно "ненаучной" - решение зависит от вас!

Если, однако, структура позволяет (либо путем прямого отключения других способов, либо путем сильного поощрения) только один способ сделать это (что имеет место с Fubu MVC), вы могли бы сказать, что решение принято в рамках этой структуры, тем самым усугубляя структуру.

Ответ 8

Пример, который вы сейчас увидите, - это структура ASP.NET MVC. Это удивительно расширяемо, но это его падение в некотором отношении, для него нет мяса. Хотите сделать доступ к данным? Тебе придется написать это сами. Хотите, чтобы AJAX продолжался? То же самое.

Однако, поскольку он является очень расширяемым, если вы основываетесь на нем, вы можете превратить его в укромную структуру. Это то, что нравится MVCContrib, они дают вам определенные методы выполнения действий, что означает, что вам нужно писать меньше кода.

Это означает, что если вы хотите отказаться от мнений, часто приходится делать больше работы, чем если бы вы работали над версией ванили. Однако это сценарий 80/20. Если вы правильно выбрали свою структуру с уверенностью, вы только захотите выйти из мнений в 20% случаев, и в 80% случаев вы будете очень продуктивны.

Ответ 9

TL;DR:

• Мнение: например. Рубин на рельсах. Есть один особенно предпочтительный способ сделать что-то, и вы получаете большую поддержку в этом. Делать другие вещи трудно, или для некоторых систем невозможно (Кассандра приходит на ум).
• Непринужденный: например. Perl 5. Вы можете делать все, что угодно, любым способом, в любом стиле. Все стили одинаково открыты, действительны и поддерживаются.