Соглашение над конфигурацией
Один из ранних девизов Rails звучал так: «Ты не красивая и уникальная снежинка». Девиз гласил, что отказываясь от индивидуальности можно обойти решение тривиальных проблем и добиться более быстрого прогресса в областях, которые действительно значимы.
Кого волнует, в каком формате описываются ваши первичные ключи в базе данных? Действительно ли это важно, если речь идет о «id», «postId», «posts_id» или «pid»? Достойно ли это решение постоянного обсуждения? Нет.
Часть миссии Rails состоит в том, чтобы размахивать мачете в густых и постоянно растущих джунглях повторяющихся решений, с которыми сталкиваются разработчики, создающие информационные системы для web. Есть тысячи таких решений, которые просто нужно сделать один раз, и если кто-то другой может сделать это за вас, тем лучше.
Мало того, что передача конфигурации в соглашение освобождает нас от обсуждения, она также предоставляет пышное поле для роста более глубоких абстракций. Если у нас есть возможность использовать зависимость класса Person от таблицы people, то мы можем использовать, то же самое преобразование, чтобы отобразить ассоциацию, объявленную как has_many: people, для поиска класса Person. Сила хороших соглашений заключается в том, что они приносят дивиденды в широком спектре использования.
Но помимо повышения скорости разработки для экспертов, соглашение также снижает порог входа для новичков. В Rails существует очень много соглашений, о которых новичку даже не нужно знать, но он может просто извлечь выгоду из своего невежества. Можно создавать отличные приложения, не зная, почему все работает именно так.
Крайне сложно, когда ваш фреймворк — это просто толстый учебник, а ваше новое приложение — чистый лист бумаги. Требуются огромные усилия, чтобы банально выяснить с чего начать. Половина усилий это поиски — найти правильную нить за которую можно потянуть.
То же самое происходит, когда вы понимаете, как все работает вместе. Когда есть очевидный следующий шаг для каждого изменения, мы можем переиспользовать многие части приложения, которые являются такими же или очень похожими, которые были до них. Место для всего и все на своем месте. Ограничения раскрепощают даже самые способные умы.
Как и во всем, сила соглашения не лишена подводных камней. Когда с помощью Rails вы делаете все настолько просто, чтобы сделать так много, то легко впасть в заблуждение, что каждый аспект приложения может быть сформирован с использованием только шаблонов. Но в большинстве приложений, есть особые элементы, которые уникальны. Это может быть 5% или 1%, от всего приложения, но такие вещи встречаются.
Самая трудная часть — это понимание того, когда стоит отклониться от курса соглашения. Когда причины достаточно серьезны, чтобы оправдать это решение? Я утверждаю, что большинство предпосылок к тому чтобы быть красивой и уникальной снежинкой еще плохо рассмотрены и цена ухода от использования Rails недооценивается. Этого достаточно для того, чтобы вы тщательно изучили их все.
Меню это омакасе
Какое решение вы принимаете, когда не знаете что выбрать из меню в ресторане? Что ж, вполне вероятно, что если вы позволите шеф-повару сделать выбор за вас, то он может приятно вас удивить, до того как к вам придет понимание того, что такое «хорошо». Это омакасе. Способ хорошо поесть, который не требует от вас экспертных знаний и к тому же позволяющий не рассчитывать на слепую удачу при выборе.
Для программирования преимущества этой практики заключаются в возможности позволить кому-то другому собрать ваш стек. Это аналогично с теми преимуществами которые мы получаем из Соглашение над конфигурацией, но на более высоком уровне. В то время когда Соглашение над конфигурацией занимается оптимизацией использования индивидуальных структур, омакасе занимается вопросом о том какие структуры существуют и как они взаимосвязаны друг с другом.
Это расходится с традицией, которая подталкивает программиста к тому чтобы принимать индивидуальные решение при выборе доступных инструментов.
Вы наверняка слышали и, скорее всего, кивнули в тот момент, когда кто-то вам сказал «используй лучший инструмент в работе». Это звучит столь элементарно, что не поддается даже обсуждению, но возможность выбрать «лучший инструмент» зависит от фундамента, который позволяет определить «лучше» с полной уверенностью. Это намного сложнее, чем кажется.
Это проблема, подобная ужину в ресторане. Как выбрать из восьми блюд, что ж выбор библиотеки или фреймворка не должно быть работой в одиночку. Цель в обоих случаях — рассмотреть весь вечер или систему.
Таким образом, в RoR мы решили сократить выбор, заменить индивидуальный выбор программиста отдельных инструментов на нечто большее: Лучший набор инструментов для всех. Дивиденды — это легион:
- Безопасность кроется в цифрах: когда большая часть людей использует Rails одинаковыми способами по умолчанию, у нас накапливается общий опыт. Это то, что облегчает обучение и помощь новичкам. Это закладывает фундамент для общения. Мы все смотрели одно и то же шоу прошлой ночью в 7, поэтому мы можем поговорить об этом на следующий день. Это способствует более сильному чувству общности
- Люди совершенствуют один и тот же базовый набор инструментов. В Rails в качестве full-stack фреймворка есть много подвижных частей, и то, как они работают вместе, так же важно, как и то, что они делают изолированно. Большая часть проблем в программном обеспечении исходит не от отдельных компонентов, а от их взаимодействия. Когда мы все работаем над облегчением общих проблем от компонентов, которые настроены и падают с ошибкой по разным причинам, у нас возникает меньше проблем.
- Замены по-прежнему возможны, но не требуются: хотя Rails — это стек omakase, он все же позволяет вам заменить определенные фреймворки или библиотеки альтернативами. Вам просто это не нужно. Это означает, что вы можете отложить эти решения до тех пор, пока не разработаете четкую персональную палитру “лучших решений”, вместо случайного набора инструментов.
Потому что даже самые образованные и опытные программисты, которые приходят и остаются в Rails, вряд ли будут возражать против всех вопросов меню (Если бы они были, они, вероятно, не были бы привязаны к Rails). Итак, они тщательно подбирают альтернативы и затем наслаждаются отдыхом от наставничества делясь стеком с сообществом.
Автор: dmitriy-strukov
