[Разработка веб-сайтов, PHP, Разработка мобильных приложений, Управление разработкой] Кто, где, когда: система компонентов для разделения зон ответственности команды

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
09-Июн-2021 21:12

Цитировать

Меня зовут Евгений Тупиков, я ведущий PHP-разработчик в Badoo и Bumble. У нас в команде более 200 бэкенд-разработчиков, которые работают над сотнями модулей и отдельных сервисов в наших приложениях. Но поначалу всё было не так масштабно. В 2006 году это был один проект, над которым работала небольшая команда. Каждый разработчик хорошо понимал, как всё устроено: легко ориентировался в коде, знал, какие есть сервисы и как они взаимодействуют между собой. Однако по мере роста проекта всё больше времени занимал поиск «хранителей знаний» — тех, кто отвечает за ту или иную функциональность и к кому можно обратиться с вопросом или предложением. В этой статье я расскажу, как мы решили проблему разделения зон ответственности и сделали процесс актуализации информации быстрым и удобным с помощью компонентного подхода. ПредысторияПредставим ситуацию: разработчик одной из команд занимается исправлением бага и в процессе дебага дошёл до кода, за который отвечает другая команда. Как понять, кто именно ответственен за данную функциональность и к кому идти с вопросами?Другими словами, нужен способ легко найти ответственного за ту или иную часть системы. И для этого мы стали использовать два специальных тега в докблоке (DocBlock) файла:

@team — команда, ответственная за данную часть системы;
@maintainer — человек, разрабатывающий данную функциональность (таких сотрудников может быть несколько).

/**
* @team Team name <team@example.com>
* @maintainer John Smith <john.smith@example.com>
* @maintainer ....
*/

Такой подход очень просто внедрить и использовать. Например, можно настроить шаблон в PhpStorm — и нужные теги будут автоматически проставляться при создании нового файла. Мы ещё сделали отдельный Git hook, следящий за тем, чтобы у всех файлов были проставлены нужные теги в требуемом формате.Но вскоре такой подход стал терять свою гибкость. В компанию приходили новые люди, кто-то переходил из одной команды в другую — и каждый раз нужно было актуализировать информацию об ответственных. Кроме того, эта информация дублировалась при настройке мониторинга в Zabbix. И если поправить код — это довольно тривиальная задача, то обновить список получателей уведомлений о результатах определённой проверки быстро не получится. Нужно поставить задачу отделу мониторинга и ждать, когда он выполнит её в рамках заданного процесса.Нам же хотелось иметь возможность обновлять список ответственных в одном месте. И желательно, чтобы все остальные системы автоматически подхватывали изменения. Так мы пришли к компонентному подходу.Что такое компонентНачнём с определения: компонент — это абстракция, представляющая определённую часть системы. Важно отметить, что в нашем случае компоненты не столько инструмент структурирования кода, сколько административный (организационный) инструмент для разделения зон ответственности. Компонент — это не обязательно функциональность, непосредственно связанная с кодом. Компонентом может быть и организационный процесс, например выпуск новой версии приложения.При переходе на компонентный подход мы сформировали ряд правил и ограничений:

структура компонентов должна быть линейной;
каждая команда должна иметь свой набор компонентов (один и тот же компонент не может относиться к нескольким командам);
для каждого компонента должен быть задан список ответственных, при этом оптимальное количество ответственных за один компонент — два—четыре человека;
только менеджер или тимлид команды может добавлять и удалять компоненты;
у каждого компонента должен быть уникальный идентификатор (alias).

Для управления компонентами у нас есть специальный интерфейс в интранете. Страница компонента выглядит следующим образом:

Пример страницы компонента в интранете Мы видим, что у компонента есть:

уникальный идентификатор;
email;
название команды, которая отвечает за данный компонент;
название проекта, к которому относится компонент, в Jira;
краткое описание, которое помогает понять, для чего нужен компонент и какая у него зона ответственности;
список ответственных: у каждого компонента есть владелец, который может его редактировать (это может быть как менеджер или тимлид команды, так и другой человек, который был явно указан как владелец при добавлении компонента);

Как мы используем компоненты в кодеДокблок файла

/**
* @component component_alias
*/

Мы доработали Git hook, проверяющий докблок. Он следит за тем, чтобы файлы, в которые были внесены изменения, содержали тег @component и чтобы указанный компонент существовал.

remote: ERROR in SomeClass.php:
remote: * Unknown @component: UnknownComponent. You have to create component before using it in the code

Также у нас есть хук, который рассылает ответственным за компонент уведомления обо всех изменениях в их файлах, сделанных другими разработчиками. Это полезно в тех случаях, когда разработчики из других команд вносят правки в ваш код и не отправляют задачу вам на ревью.Сервис для работы с компонентами в кодеДля работы с компонентами в коде у нас есть отдельный класс, который позволяет получить список всех компонентов и найти конкретный либо по полному названию, либо по идентификатору. В коде доступна та же информация, что в интерфейсе в интранете.

$componentManager = new \Components\ComponentManager();
$component = $componentManager->getComponent('component_alias');
$recipients = [];
foreach ($component->getMaintainers() as maintainer) {
$recipients[] = $maintainer->getEmail();
}

или найти дежурного по компоненту:

$componentManager = new \Components\ComponentManager();
$component = $componentManager->getComponent('component_alias');
foreach ($component->getMaintainers() as $maintainer) {
if ($maintainer->isDuty()) {
return $maintainer;
}
}

Интеграция с PhpStormВ нашем блоге есть статья про плагин для PhpStorm, который значительно упрощает жизнь разработчикам. За то время, что прошло с момента её написания, мы реализовали много новых удобных фич и добавили поддержку компонентов.Теперь IDE автоматически выводит на экран владельца компонента и дежурного. Также при наведении на идентификатор компонента отображается дополнительный блок со списком всех ответственных за него с возможностью отправки личных сообщений в мессенджер (Slack).

Дежурный по компонентуДумаю, многие из вас сталкивались с проблемой переключения контекста. На мой взгляд, надо стараться этого избегать. У каждого своя скорость — и требуется разное количество времени, чтобы снова погрузиться в задачу (контекст). Кому-то достаточно нескольких минут, а кому-то нужно гораздо больше.Чтобы минимизировать последствия переключения контекста, мы решили ввести практику дежурств. Теперь у каждого компонента есть дежурный, который является входной точкой для всех вопросов связанных с ним. Когда человек заступает на дежурство, отметка об этом появляется у всех нужных компонентов и отображается в публичной группе в мессенджере.Это не значит, что команда бросает дежурного на произвол судьбы. В случае если он не сталкивался с какой-либо проблемой ранее, он всегда может подключить коллег. Но если дежурный самостоятельно отвечает даже на 80% вопросов, это означает, что остальные члены команды 80% времени спокойно работают над своими задачами, не опасаясь, что их вырвут из контекста.Кроме того, дежурства позволяют делиться знаниями внутри команды, тем самым повышая bus factor.Интеграция с внутренними системамиПомимо использования компонентов непосредственно в коде, их поддержка была добавлена в большинство наших внутренних систем. Ниже я приведу несколько примеров.Система сбора и анализа PHP-ошибокИсторически для сбора и анализа PHP-ошибок мы используем самописную систему, которая по функциональности похожа на популярные Sentry и Splunk, но адаптирована к нашим внутренним процессам. В неё первую мы добавили поддержку компонентов. Один из этапов сбора ошибок — насыщение события дополнительной информацией. Мы добавили в пайплайн новый шаг, на котором система собирает список затронутых компонентов на основе списка файлов из стек-трейса ошибки. Эту информацию можно использовать:

для поиска ошибок по определённому компоненту;
для построения отчётов и графиков в разбивке по компонентам.

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

Реестр баз данныхБэкенд наших приложений Badoo и Bumble состоит из сотен различных модулей, систем и сервисов. Большинство из них для хранения данных использует MySQL. Теперь представим ситуацию: разработчик начинает разбираться с новой для него функциональностью, и в процессе ему понадобилось посмотреть схему какой-то таблицы. Для этого нужно:

Найти в коде, на каком хосте живёт база.
Подключиться к хосту через любой удобный инструмент (консольная утилита, phpMyAdmin, Sequel Pro, IDE и т. д.).
Найти нужную базу и таблицу.
Изучить информацию о таблице.

А если нужно узнать размер таблицы на продакшене? Для начала нужно запросить доступ к базе данных, дождаться его предоставления — и только после этого можно будет получить необходимую информацию. На самом деле схема простая и рабочая — процесс получения доступа у нас автоматизирован. Но требуется довольно много времени для того, чтобы получить ответ на простой вопрос.Другой пример: нужно найти список таблиц, которые долгое время не используются и просто занимают место на сервере. Тут уже нужно писать скрипт, который обойдёт все нужные серверы и соберёт статистику.Чтобы упростить жизнь разработчикам, мы создали систему под названием DBRegistry. Она хранит в себе информацию для всех баз данных, доступную через INFORMATION_SCHEMA.

При внедрении компонентов мы добавили возможность указания, к какому компоненту относится та или иная база данных или таблица.Информация о компоненте будет полезна в случае, если с каким-то сервером начались проблемы (например, выросла нагрузка на CPU) и администратор баз данных нашёл проблемный запрос и хочет сообщить о проблеме разработчику. Он просто находит нужную таблицу в DBRegistry, смотрит, к какому компоненту она привязана, и пишет о проблеме дежурному.ЗаключениеС момента нашего перехода на компонентный подход прошло больше трёх лет, и за это время поддержка компонентов была реализована во всех внутренних системах. Нам удалось сделать процессы более быстрыми и понятными. Теперь ни у кого не возникает вопроса «А кто отвечает за этот код?». Достаточно открыть интранет и найти нужный компонент — он содержит всю необходимую информацию.Актуализация списка ответственных теперь сводится к нескольким кликам в интерфейсе, хотя до внедрения компонентов на обновление этой информации во всех системах могли уйти дни, а то и недели.На этом всё. Спасибо за внимание!
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_php, #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_upravlenie_razrabotkoj (Управление разработкой), #_php, #_komponent (компонент), #_bus_factor, #_vnutrennie_servisy (внутренние сервисы), #_baza_znanij (база знаний), #_blog_kompanii_badoo (
Блог компании Badoo
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_php, #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
), #_upravlenie_razrabotkoj (
Управление разработкой
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 21:12
Часовой пояс: UTC + 5