Максим Морев, Газпромбанк.Тех - Код, которого не должно быть: Vertical Slice Architecture в Пузырьке
ฝัง
- เผยแพร่เมื่อ 7 พ.ค. 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Сейчас много задач по рефакторингу или импортозамещению, разработчики собирают информацию по частям из хранимых процедур, описаний. Поделюсь своим опытом рефакторинга и переосмысления легаси-систем.
Как написал Эрик Эванс в своей книге «Предметно-ориентированное программирование (DDD). Структуризация сложных программных систем»: «Привести в соответствие фактическое поведение, смысловое содержание и внешнюю форму кода - все это требует дисциплины и определенного взгляда на архитектурное проектирование программы».
Как это сделать так, чтобы не сломать существующий код и не толкаться с разработчиками в репозитории, если они будут работать над параллельными процессами? Максим рекомендует использовать следующий набор инструментов: Bubble context, Vertical Slice Architecture, Feature toggles. На примерах спикер делится опытом, как можно улучшить легаси, в котором часто идут доработки.
Доклад будет полезен мидлам и старшим разработчикам.
Скачать презентацию с сайта JPoint - jrg.su/UWqbBr - วิทยาศาสตร์และเทคโนโลยี
Вопрос по горизонтальной доработке - очень в тему. Как раз такие "непредвиденные" сценарии очень часто и встречаются на долгоживущих проектах. Т.е. долгое время и бизнес и разработка и аналитики живут в той парадигме, допустим, что сервис может предоставляться только "клиенту банка", а потом приходит новый бизнес со светлой идеей, что можно предоставлять какие-то услуги "не клиентам" и тут же начинаются "чудеса на виражах", как эту доработку воткнуть в существующий ландшафт (уже немаленький и в котором уже нет никого, кто знал бы все процессы от и до) и ничего нигде и ни у кого не сломать.
Также не до конца понятно про хранение данных и его оптимизацию. То, что код дублируется - это понятно. Но судя по тому, что и репозитории внутри пакетов дублируются и сущности, то скорее всего и все данные в БД тоже начинают жить в разных таблицах / схемах / базах.
Про фиче-тоглы, т.е. про "флажки", тоже очень вскользь пробежались, как будто это тривиальная проблема и никаких подводных камней там не бывает. Хотя на практике зачастую ПО начинает обрастать этими флажками и ветвистым кодом. Старое по какой-то причине не удаляется и оно продолжает жить в этой парадигме и распухает и становится слабо поддерживаемым и слабо тестируемым.
Вопросы совершенно валидные и злободневные! Каждый из них - тема как минимум для статьи. Про фича-флаги: действительно всё не так тривиально, особенно про их жизненный цикл. Про всё за 15 минут не рассказать, увы. Думаю, что тему как раз можно хорошенько прокачать ответами на ваши вопросы.
как быть тогда в таких ситуациях? как можно избежать таких ситуаций и чем предстоит пожертвовать?
Уровень "экспертов" впечатляет. За такие доклады кто-то ещё деньги платит?
Очень рваная подача материала и очень однобокая точка зрения. Тяжело слушать и неявно появляются вопросики к эксертности докладчика. Представленный подход не про упрощение, он про примитивные проекты, где такие трюки действительно могут ускорить разработку без шанса поломать общие инварианты, например какой нить тупой CRUD.
Не я докладчик, но вставлю 5 копеек: серебряной пули, как известно, не существует - это лишь один из инструментов решения задачи. Такой подход работает не только для банальных CRUD'ов, но наверняка можно придумать случаи, где такой подход может вызвать больше проблем, чем пользы. Под вот этим th-cam.com/video/L2Wnq0ChAIA/w-d-xo.html видео об архитектуре вертикального среза идут очень интересные обсуждения про репозитории, большие проекты и применимость подходов.
Мне кажется, что единственный полезный поинт это "не создавать интерфейсы на каждый чих". В остальном разговоры ни о чем, голые концепции без демонстрации практических примеров.
Следующий шаг - отказ от ООП в пользу процедурного стиля. А там и до go to не далеко.
Есть подозрение, что такой подход может заметно поднять сложность в персистентном слое. Если модели в слайсах будут ссылаться на общее состояние в БД, то придется поддерживать N мапперов. Плюс изобретать отдельные практики по миграциям схемы БД.
Еретик
что это была за ерунда