На моем первом боевом проекте на React я работал в команде из ещё двух разработчиков миддл-уровня. Мне, махровому джуну, они казались всезнающими экспертами. И, как-то раз, обсуждая уже не помню какую библиотеку, один из них сказал следующее: «Эта библиотека мне не нравится, она opinionated».
Я расспросил подробнее что такое «опиньёнейтед» и потом ещё немного погуглил. Разобравшись с терминами, молодой фронтендерский мозг проявил гибкость и адаптивность, поэтому в голове раз и навсегда отпечаталось — «opinionated — это плохо». Так сказал старший!
Но в самом ли деле это настолько плохо?
Что такое opinionated, на примере открытия шаурмичной
Представим, вы разочаровались в айти, и решили открыть шаурмичную. Время есть, деньги есть. Как будем открывать?
Два возможных подхода
- Купить франшизу крупной сети, получив готовые технологические карты, нормативы, инструкции по приготовлению блюд, форму одежды для персонала, его обучение бренд-бук. Взамен вы заплатите паушальный взнос и, вероятно, будете перечислять какое-то роялти
- Имея гриль, лаваш, мясо, овощи и соус, найти свой путь в мире заворачивания начинки в лаваш и его пропекания
Первый подход — не что иное, как opinionated-решение. Второе — unopinionated. Вот и всё. В первом случае мы имеем жесткие рамки (opinionated), во втором — полную свободу (unopinionated).
Что значит «software has opinions»?
Когда говорят, что то или иное решение являются opinionated, это означает, что создатели этого инструмента навязывают пользователям своё видение того, как должна быть устроена архитектура приложения.
Они не просто дают ящик с инструментами, они, например, утверждают: «Мы считаем, что компоненты должны лежать в директории components, называться с большой буквы, страницы — в pages, при этом название директории будет отражать pathname этой страницы в URL». И если вы захотите сделать как-то по-своему, инструмент будет активно сопротивляться, «плеваться» ошибками или просто упадет с полотном ошибок при попытке запустить проект.
От спагетти к стандарту
Когда с абстрактными примерами покончено, вернемся к фронтендерской конкретике. На ум сразу приходит сравнить React и Next.js.
- React (скорее unopinionated). библиотека, которая содержит в себе кучу строительных блоков, но не содержит инструкций по сборке. Вы можете построить всё что угодно. Но вам самим придется решать, как организовывать проект, как работать с роутингом, данными. Это свобода. Но за свободу приходится платить личной ответственностью за код и высоким профессионализмом. При этом порог входа очень небольшой. Каждый пишет по своему.
- Next.js (100% opinionated). Next.js жестко диктует: страницы клади в папку
pages, картинки оптимизируй так, а если хочешь загрузить данные с сервера — следуй этой инструкции. Отклонение от инструкции либо невозможно, либо требует нечеловеческих усилий. Порог входа повыше (нужно внимательно прочитать документацию), но зато все пишут плюс-минус по одним и тем же правилам.
Так действительно ли плох opinionated подход?
С точки зрения взрослого человека, который финансирует проект или управляет командой разработки, ответ очевиден: для крупных, долгоиграющих проектов opinionated — это благо.
- Предсказуемость. Когда все пишут по единому шаблону, проект превращается в структурированный набор файлов. Если один разработчик увольняется, новый сотрудник не гадает, «что хотел сказать автор», а просто скачивает проект из SCM и видит типовую, знакомую себе структуру.
- Снижение стоимости разработки. Opinionated-фреймворки берут на себя ответственность за архитектуру. Неопытный разработчик может не знать, как «правильно» спроектировать приложение. Фреймворк просто не даст ему сделать это неправильно.
- Скорость разработки. Стандартизация ускоряет конвейер. Вам не нужно тратить время на созвоны чтобы обсудить какие-либо стандартны написания кода и организации проекта. Вы просто делаете так, как говорит фреймворк.
Однако не всё так гладко. Есть и недостатки, а именно
- Не подходит для решения нетиповых задач. Если ваш проект — это уникальный портал с инновационной функциональностью, opinionated-решения будут только мешать. Они будут накладывать правила, которые просто придется обходить. Так проект обрастет костылями.
- Вендор-лок (зависимость от поставщика). Время вложенное в работу с opinionated-решениями превращается в вашу зависимость от их поставщика. При этом уровень абстракции может быть достаточно высоким и тогда вы еще и базовые навыки работы с технологией можете потерять. Если придется переучиваться, это будет больно.
Заключение
Создатели opinionated-инструмента говорят вам: «Мы знаем, как делать надежно и быстро для 80% стандартных задач. Следуй нашим правилам, и ты получишь стабильный продукт с минимальными усилиями по архитектуре». Разработчики unopinionated-библиотек говорят: «Вы крутые и независимые, справитесь сами».
Поэтому называть их «плохими» или «хорошими» — бессмысленно. Это вопрос контекста. Для стартапа, где нужно быстро проверить гипотезу, opinionated-решения — идеальны. Для создания уникального раздела гигантского медиапортала они могут стать тяжелыми кандалами.
Мой старший и более опытный коллега был не до конца прав в те далекие доковидные годы. Opinionated-решения — это приговор, это контракт который подписывается добровольно. И наша задача заключается не в том, чтобы избегать opinionated-решений, а в том, чтобы выбирать такие, чье «мнение» совпадает с нашими целями.
