Dependency Inversion для процессов разработки
Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.
Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.
Таким образом, мы можем развернуть зависимость и создать инструмент для других инженерных команд. Другие команды знают детали своих серверов сильно лучше и могут эффективнее и быстрее интегрировать свои бизнес процессы самостоятельно. Нужно лишь дать им несколько эндпоинтов. А бекофисная команда может сфокусироваться на создании и апгрейде самого инструмента и применении своих сил для других, не рутинных, дел.
Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.
>>Click here to continue<<