Экстраполяция IT

Что на самом деле работало бы в микросервисах, если бы менеджеры этим пользовались.

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

Таким образом менеджер реализует принцип коллективного владения кодом и пытается защититься от фактора автобуса. Фактор автобуса - это мера сосредоточения информации среди отдельных членов проекта; фактор означает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

И вот штука в том, что при этом теряется одна из действительно работающих фич микросервисов: команды прикрепляются к своим проектам. Знают их и любят.

Вместо этого, приходится чувствовать себя креветкой, прыгающей по проектам и ничего нигде толком не понимающей. Только отвлёкся от какой-то области — там уже всё переделали, изучай всё заново.

Конечно, начальство не хочет иметь незаменимых людей.

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

#dimoneverything

www.tgoop.com/itextrapolation/424

2.6K viewsJun 25, 2020 at 08:01

Что на самом деле работало бы в микросервисах, если бы менеджеры этим пользовались.

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

Таким образом менеджер реализует принцип коллективного владения кодом и пытается защититься от фактора автобуса. Фактор автобуса - это мера сосредоточения информации среди отдельных членов проекта; фактор означает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.

И вот штука в том, что при этом теряется одна из действительно работающих фич микросервисов: команды прикрепляются к своим проектам. Знают их и любят.

Вместо этого, приходится чувствовать себя креветкой, прыгающей по проектам и ничего нигде толком не понимающей. Только отвлёкся от какой-то области — там уже всё переделали, изучай всё заново.

Конечно, начальство не хочет иметь незаменимых людей.

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

#dimoneverything

BY Экстраполяция IT