Привет, для начала дисклеймер: все совпадения с людьми и компаниями, которые вам придут в голову — только плоды вашей фантазии. Расскажу одну былину про «крестовый поход», который организовала группа энтузиастов в одной компании пару лет назад. Намерения у них были, как всегда, благие — «за все хорошее, против всего плохого». Но не всегда все складывается как в сказке, а скорее получается как в известном мультфильме с приключением на 20 минут. Мы посмотрим на их путь, с какими сложностями они столкнулись, каких успехов добились в этой неравной битве с легаси кодом.
С чем предстояло сражаться
Что имелось на старте. Группа заряженных backend-специалистов, которые хотят сделать мир вокруг себя лучше. Однажды они собрались вечерком за кружкой крепкого чая обсудить дела свои насущные. В ходе непринужденной беседы они поняли, что есть ряд моментов, над которыми надо задуматься и записали их:
- Отсутствие шаринга знаний между проектами. Раньше в офисе проводились внутренние небольшие выступления на разные темы — технические и нетехнические. Их прозвали «куличи» по случаю старой легенды о том, что первое подобное мероприятие прошло после пасхи, а на кухне были куличи, которые сотрудники принесли из дома, чтобы доесть общими усилиями. На этих куличах любой желающий мог выступить и рассказать про интересную статью/видос, который только что прочитал/посмотрел, поделиться прикольной ситуацией с проекта. Это была возможность в непринужденной атмосфере поделиться опытом и прокачаться как самому, так и коллегам. А сейчас эта инициатива затухла.
- Не на всех проектах есть опытные лиды и не хватает знаний для решений конечной задачи качественно. Люди просто используют то, что знают или не совсем проверенную информацию из интернета, чтобы просто решить текущую задачу, не задумываясь о будущем, как это поддерживать. Не выстроена система создания задач в таск трекере на будущее для устранения технического долга или создание issue в репозитории.
- Кулик, который хвалит свое болото. Люди в упор не видят проблем на своем проекте, так как привыкли к этому и уже не чувствуют боли от тех проблем, что у них есть. А при приходе новых людей на проект всячески убеждают его, что это нормально и лучше уже сделать нельзя.
- Слишком разные архитектурные решения одних и тех же проблем. Они работают в разных командах и мало понимают, кто что использует, кто как решает типовые проблемы (полноценное использование Graphql vs плевались и использовали небольшой кусок, семейство гемов dry vs старый гем и собственные костыли). Это же было сложностью при переходе разработчиков между командами, когда затягивали онбординг на проекте.
Посмотрели на этот список на свежую голову (насколько это возможно утром субботы) добры молодцы и поняли, что само это не исправится. Объединили усилия и пошли крушить проблемы на проектах отдельного офиса своей компании.
План их был такой:
- Приходим на проект с известным стеком, где основная команда находится в их офисе, чтобы было проще коммуницировать с командой, да и со своими знакомыми коллегами работать было легче.
- Работаем над этой инициативой без больших потерь на своих проектах. Они все так же оставались штатными разработчиками на своих проектах и не могли просто так, условно 40 часов в неделю, тратить на борьбу со злом. Так что днем ты обычный программист, а вот после работы — Илья Муромец, защищающий код от антипаттернов.
- Погружаться в проект по-серьезному, разбираться в бизнес логике, собирать боли команды и находить проблемы самостоятельно, чтобы команда в их отсутствие в будущем понимала куда идти.
- Срок на каждый проект — рабочая неделя.
Как мы бились
План был надёжен как швейцарские часы, и ничего не предвещало беды. Ребята с рвением пришли на первый проект одного из участника сей банды и, засучив рукава, взялись за работу. Начали они с беседы со своим однополчанином, по совместительству тимлидом этого проекта и сосредоточили свои усилия на проблемах, которые бросались в глаза:
- Группа нестабильных юнит-тестов в девелопе.
- Несоблюдение принципов solid на проекте.
- Взялись рефакторить сложный кусок кода, который был плохо читаемый и не нравился никому в команде
И приняли они следующие решения:
- Один человек отправлялся править нестабильные тесты, так как негоже важному проекту иметь такое в своем арсенале.
- Два человека отправились погружаться в дремучий лес плохо читаемого кода и рефакторить его в ожидании просветления.
- Джуны отправились с поручением сделать куличи по каждой букве из SOLID, чтобы они сами разобрались в теме, да и коллег своих просветили.
Неделя пролетела незаметно, ведь кроме этой активности ребята отбивались от своей основной работы. В конце недели уставшие молодцы увидели перед собой такую картину:
- Тесты починились;
- Буквы из solid розданы, и первые куличи проведены;
- Код после рефакторинга даже завелся, улучшения появились, хоть и не такие явные, как они ожидали от себя.
Это был локальный успех, хоть и сил было потрачено немало, но с понедельника решили идти на следующий проект.
Погружать молодцев в него взялся менеджер. Он сделал упор на бизнес-логику и проблемы, которые мешают с точки зрения бизнеса. Перед богатырями были уже поставлены более полезные задачи:
- Взялись переписывать одну из важных фич проекта, чтобы ускорить ее (условно это был большой импорт данных, который потом обрабатывался, и на его основе работала остальная логика, по времени он занимал 5 минут, а они не очень понимали, почему так долго, и хотели сократить его до 1 минуты).
- Часть кода деплоя была написана на стеке, которым не владела команда и его бы переписать для удобной работы в будущем. Команда снова разделилась на группы и отправилась в бой.
Вот что получилось к концу недели:
- Их основные проекты съедают много времени, и сил перерабатывать вторую неделю подряд почти не осталось.
- Решать бизнес-задачи за такой короткий срок очень сложно, ведь проекты идут годами, и логика для такого быстрого погружения с положительным результатом слишком сложная.
- Не хватает четких метрик успеха, и, следовательно, эндорфины не появляются для работы в авральном режиме на следующей неделе
- Не было общих решений, которые можно было бы сразу раздавать на другие проекты, своеобразных лучших практик, которые, как заповеди, можно было бы нести по проектам.
Окручинились добры молодцы, да и разошлись по домам.
На третьей неделе они уже по инерции попытались зайти на новый проект, чтобы добавить в него свои знания и опыт. Но сил уже не хватало, стартовый запал почти иссяк, а видимых значимых улучшений не было. И ребята решили заморозить эту инициативу до лучших времен.
Как мы не победили до конца
Стоит, конечно, отметить положительные результаты:
- Культура куличей немного возродилась после серии докладов про solid. Не всегда это были технические истории, но люди стали больше узнавать друг о друге, что положительно сказалось и на рабочих моментах в будущем.
- Молодые специалисты на проектах, где побывала команда, стали чуть активнее тянуться к знаниям и в дальнейшем показали себя сильными профессионалами.
- Команда оставила после себя некоторые задачи в беклогах для будущих улучшений, дав толчок в сторону оцифровки необходимых изменений на проектах.
Выводы об этой практике, ее необходимости в ваших компаниях вы можете сделать сами исходя из своей ситуации. На мой взгляд, для более успешной реализации можно внести несколько изменений:
- Срок работы на одном проекте увеличить до нескольких недель, условно 1-2 спринта команды разработки проекта, куда вы приходите.
- Можно попробовать подойти более широким фронтом и добавить в свою «команду мечты» специалистов из других областей: frontend, qa, devops и т.д. Это позволит увидеть картину на проекте с разных сторон и принимать решения лучше.
- Сделать эту команду более совещательным органом, который скорее делает аудит, а команда разработки проекта получает условный отчет и сама решает, что с ним делать в будущем.
Но мне верится, что когда-нибудь эта инициатива вновь будет «разморожена» и мы сможем рассказать про новую версию этой команды супергероев.
