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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tl; dr :

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

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

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

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

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

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

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

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

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

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

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

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