Вопрос по горизонтальной доработке - очень в тему. Как раз такие "непредвиденные" сценарии очень часто и встречаются на долгоживущих проектах. Т.е. долгое время и бизнес и разработка и аналитики живут в той парадигме, допустим, что сервис может предоставляться только "клиенту банка", а потом приходит новый бизнес со светлой идеей, что можно предоставлять какие-то услуги "не клиентам" и тут же начинаются "чудеса на виражах", как эту доработку воткнуть в существующий ландшафт (уже немаленький и в котором уже нет никого, кто знал бы все процессы от и до) и ничего нигде и ни у кого не сломать. Также не до конца понятно про хранение данных и его оптимизацию. То, что код дублируется - это понятно. Но судя по тому, что и репозитории внутри пакетов дублируются и сущности, то скорее всего и все данные в БД тоже начинают жить в разных таблицах / схемах / базах. Про фиче-тоглы, т.е. про "флажки", тоже очень вскользь пробежались, как будто это тривиальная проблема и никаких подводных камней там не бывает. Хотя на практике зачастую ПО начинает обрастать этими флажками и ветвистым кодом. Старое по какой-то причине не удаляется и оно продолжает жить в этой парадигме и распухает и становится слабо поддерживаемым и слабо тестируемым.

@vaganov_vadim

Ай бұрын

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

@vadimkain8969

18 сағат бұрын

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

Уровень "экспертов" впечатляет. За такие доклады кто-то ещё деньги платит?

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

@vaganov_vadim

Ай бұрын

Не я докладчик, но вставлю 5 копеек: серебряной пули, как известно, не существует - это лишь один из инструментов решения задачи. Такой подход работает не только для банальных CRUD'ов, но наверняка можно придумать случаи, где такой подход может вызвать больше проблем, чем пользы. Под вот этим kzread.info/dash/bejne/fmaL0NNpc8uneaQ.html видео об архитектуре вертикального среза идут очень интересные обсуждения про репозитории, большие проекты и применимость подходов.

Следующий шаг - отказ от ООП в пользу процедурного стиля. А там и до go to не далеко.

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

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

Еретик

что это была за ерунда