Как стать автором
Обновить

Комментарии 8

НЛО прилетело и опубликовало эту надпись здесь
А примеров каких компонентов? Не связанных с кодом? На самом деле их не так много у нас и все они связаны с каким либо внутренним процессом. Компонент в данном случае используется как способ обозначить ответственных и внедрить практику дежурств.

Если из выдуманных, то может быть компонент «Маркетинг» или компонент «Дизайн внутренних интерфейсов». Но понятно, что основной профит от компонентов виден в привязке к коду/фичам/сервисам.
200 бекендеров? Это примерно 40 команд. Я может не вкурсе, но разве у вас не сайт на пхп и приложение для знакомств?

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

Можно было на этом закончить :)

это чтобы подобные идеи можно было реализовать :)

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

нужен способ легко найти ответственного за ту или иную часть системы
Так и не понял, как вы решили эту задачу.
«Дежурства», как мне кажется, не помогут в случае увольнения автора кода.
Решили следующим образом: у нас есть лишь источник истины — это система компонентов. Предположим мне потребовалось в рамках моей задачи отправлять push уведомления. Я иду в Интранет, ищу компонент отвечающий за push-ы, смотрю кто дежурный и задаю свой вопрос ему.

Может получиться так, что дежурный не знает ответа на мой вопрос, и это нормальная ситуация (нет человека который все обо всем знает). Цель дежурства — это в первую очередь решить проблему смены контекста. И в случае, если я как дежурный, не могу сразу ответить на вопрос, то вместо того, чтобы «скинуть» вопрос тому, кто больше погружен в детали конкретного компонента, я начинаю разбираться в проблеме, начинаю задавать уточняющие вопросы коллегам, тем самым пополняя свой багаж знаний.

Дежурства конечно не помогут в случае, если автор кода уволился и не передал компонент другому человеку. Но это уже признак того, что есть проблемы с обменом знаниями внутри команды и тут никакие компоненты проблему не решат :) Но как минимум система компонентов может показать, что есть компоненты у которых Bus factor = 1 и это маркер того, что в этот компонент нужно инвестировать время и увеличить bus factor как минимум до 2
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.