Comments 13
Если из выдуманных, то может быть компонент «Маркетинг» или компонент «Дизайн внутренних интерфейсов». Но понятно, что основной профит от компонентов виден в привязке к коду/фичам/сервисам.
Я слабо разбираюсь в разработке и управлении командами, так как не разработчик. Но кажется, имея под рукой 200 бекендеров можно делать какие-то невероятные вещи. Помню в лучшие времена в вк было 12 фулл стек чуваков.
В одной известной на Хабре компании я встречал такой подход, что каждая компонента — это отдельный гит-репозиторий, и его мейнтейнеры задаются в настройках проекта в битбакете. Таким образом, найти ответственного очень легко — каждый файл принадлежит какому-то репозиторию, заходим в битбакет, видим мейнтейнеров. При смене мейнтейнера ничего кроме настроек в битбакете менять не нужно.
нужен способ легко найти ответственного за ту или иную часть системыТак и не понял, как вы решили эту задачу.
«Дежурства», как мне кажется, не помогут в случае увольнения автора кода.
Может получиться так, что дежурный не знает ответа на мой вопрос, и это нормальная ситуация (нет человека который все обо всем знает). Цель дежурства — это в первую очередь решить проблему смены контекста. И в случае, если я как дежурный, не могу сразу ответить на вопрос, то вместо того, чтобы «скинуть» вопрос тому, кто больше погружен в детали конкретного компонента, я начинаю разбираться в проблеме, начинаю задавать уточняющие вопросы коллегам, тем самым пополняя свой багаж знаний.
Дежурства конечно не помогут в случае, если автор кода уволился и не передал компонент другому человеку. Но это уже признак того, что есть проблемы с обменом знаниями внутри команды и тут никакие компоненты проблему не решат :) Но как минимум система компонентов может показать, что есть компоненты у которых Bus factor = 1 и это маркер того, что в этот компонент нужно инвестировать время и увеличить bus factor как минимум до 2
Во-первых, компонент — это какой-то сервис, который имеет выделенную и самодостаточную бизнес логику (например, компонент регистрации) или это что-то более мелкое?
Во-вторых, дежурный человек отвечает на все вопросы от других разработчиков, которым нужно внести какие-то измнения в этот компонент (имеют ли они право это делать, кстати), или это ответы по комопненту на вопросы всех желающих (QA, Поддержка, Маркетинг) и так далее?
Во-первых, компонент — это какой-то сервис, который имеет выделенную и самодостаточную бизнес логику (например, компонент регистрации) или это что-то более мелкое?
Да, компонентом может быть, как сервис, так и модуль в монолите. Мы при внедрении компонентного подхода сначала разбили все на довольно большие компоненты и со временем уже какие-то части выносились в отдельные компоненты. Тут нет какого-то правила и нужно исходить из конкретных сервисов/систем/модулей
Во-вторых, дежурный человек отвечает на все вопросы от других разработчиков, которым нужно внести какие-то измнения в этот компонент (имеют ли они право это делать, кстати), или это ответы по комопненту на вопросы всех желающих (QA, Поддержка, Маркетинг) и так далее?
Задача дежурного скорее быть входной точной для оперативных вопросов, советов, может быть пожеланий. Например, вы предоставляете некий сервис и у разработчика возник вопрос по его использование, который не покрыт документацией. Либо же сработал мониторинг и нужно поресерчить проблему. Важно понимать, что дежурный это не один в поле воин и остальные члены команды всегда на подхвате.
Если кто-то не из списка ответственных за компонент хочет внести правки в код компонента, то на мой взгляд самый лучшим тут будет попросить поставить задачу в трекере и уже предметно обсуждать ее. Можно назначить отдельную встречу, где обсудить саму задачу и может ли она быть сделана силами "со стороны" с ревью ответственными за компонент.
Вообще мне кажется самый оптимальный подход - это определиться в рамках своей команды, что должно входить в задачи дежурного и постепенно либо расширять этот список, либо наоборот что-то убирать.
Спасибо, полезная статья.
Есть ли у вас "кросс-функциональные" компоненты? Ведь тоже самое дежурство или эксперты полезны и на фронте и в продукте или в вашей случае компоненты это только про бэкенд?
Если говорить прям про кросс-функциональные компоненты - то у нас нет такой практики, потому что не было пока такой потребности. Но ничего не мешает масштабировать такой подход и на них, особенно в случае если разработчик(-и) отвечают и за фронет и за бекенд (у нас просто эти роли разделены)
Компоненты это скорее просто про разделение зоны отвественности и этот подход может быть применен в любом направлении. В нашем случае изначально проблема была на стороне бекенда, поэтому не удивительно, что большинство компонентов тесно связаны с ним. Но помимо этого есть также компоненты у релиз инженеров, у команд мобильной разработки, у тестировщиков - просто не в таком масштабе.
Также компоненты у нас стали стандартом в большинстве внутренних систем там где требуется взаимодействие с людьми. Например, у нас есть своя система мониторинга, которая позволяет разработчикам писать свои проверки с учетом специфики своих компонентов и эта система работает только с компонентами т.к. по компоненту можно легко получить список получателей уведомлений.
Кто, где, когда: система компонентов для разделения зон ответственности команды