Что на самом деле работало бы в микросервисах, если бы менеджеры этим пользовались.
В большом проекте на 20-30 репозиториев, если вы опытный разработчик, вы неоднократно должны были сталкиваться с тем, что вас менеджер старательно возит лицом по всей кодовой базе. В этом спринте вы тут, а в следующем вы уже где-то ещё, а на вашем месте другой несчастный, который, скорее всего, продолжает ваши задачи, некоторые из которых выписывали именно вы. Вы же старательно вникаете в код, в который уже вникали три месяца назад, но уже всё поменялось и в этом новом витке вы снова его читаете и пытаетесь загрузить в оперативную память до того состояния, чтобы вы могли что-то менять. А в следующий спринт вас потащат куда-то ещё.
Таким образом менеджер реализует принцип коллективного владения кодом и пытается защититься от фактора автобуса. Фактор автобуса - это мера сосредоточения информации среди отдельных членов проекта; фактор означает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.
И вот штука в том, что при этом теряется одна из действительно работающих фич микросервисов: команды прикрепляются к своим проектам. Знают их и любят.
Вместо этого, приходится чувствовать себя креветкой, прыгающей по проектам и ничего нигде толком не понимающей. Только отвлёкся от какой-то области — там уже всё переделали, изучай всё заново.
Конечно, начальство не хочет иметь незаменимых людей.
Но в плане фактора автобуса иметь толпу ни в чем не разбирающихся креветок мало чем отличается от толпы персонально специализированных парней. При удалении любого парня из первой толпы общий уровень экспертизы не уменьшается лишь потому, что он и так равен нулю. Все дружно собирают дзен-паззлы, чтобы как-то закрыть задачу и двинуться дальше.
#dimoneverything