Гибкость добавляет сложность или убирает ее?

Когда я слышу что кто, то говорит “у нас очень гибкая система и код”, то меня это скорее пугает. Дело в том что любая гибкость увеличивает сложность. Чем гибче чем сложнее. Почему так получается?

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

Из недавнего опыта. Я искал для проектов Хекслета фронтенд систему, которая позволяет генерировать интерфейсы из готовых элементов в коде, чтобы не тратить время на ручное их написание там, где нам это не нужно. Например нам такое нужно во всех проектах, где делается бекенд, а фронтенд предоставляем мы сами. После изучения вопроса стало понятно что есть два основных решения: https://refine.dev/ и https://marmelab.com/react-admin/ Если посмотреть их документацию, то видно что первое решение более гибкое и например позволяет менять внешний вид так как работает с разными css-фреймворками. Но если посмотреть на код, эта гибкость дается дорого, количество кода, которое надо писать в refine, значительно больше чем в react-admin, где из коробки material который не поменяешь, но зато весь css скрыт на 100%. В итоге я выбрал react-admin, а реализация того что нам нужно составила около 100 строк кода (несколько крудов, аутентификация, связь с бекендом).

Все тоже самое проявляется и на более низком уровне:

⁃ Отсутствие внедрения зависимостей VS внедрение зависимостей (усложняет систему очень сильно)

⁃ Работа с конфигами из файлов VS универсальная штука загрузки конфигов

⁃ Модель с фиксированными полями VS модель с динамическим набором полей

⁃ Active Records VS Data Mapper

⁃ Работа с одной базой данных VS Поддержка любых баз данных (особенно если NoSQL смешивается с SQL)

Все это не значит что гибкость не нужна, но нужно правильно оценивать эту гибкость. Часто она дается настолько дорого, что лучше все же не обобщать. Хорошим примером может служить Java и Spring Boot где все сильно обобщено, есть множество интерфейсов на все случаи жизни, которые все реализуют. Огромная куча абстракций, которую не так то просто выучить. Зато все можно подменить и в теории это работает. С другой стороны находятся фреймворки динамических языков типа Django, Ruby On Rails, Laravel, где шли другим путем, давали готовые решения, которые не такие гибкие, но зато очень простые, легкие в изучении и использовании.

p.s. Какая концепция вам ближе? Spring Boot или Django/Rails/Laravel?

2 минуты

11 декабря 2023