Переписывать или не переписывать? Жизнь с техническим долгомУправление командой разработки (тимлиды)
Более двух лет в роли Unit Manager'а отвечает за разработку B2C и B2B eCommerce-решения. В роли team lead'а выпускал продукты объемом от 1 до 10 человеко-лет на релиз. Начинал в качестве backend С++-разработчика в 2005.
Как подходили к управлению техническим долгом? Работали над тем, что съедает время команды разработки: улучшили удобство работы, убрав VPN, внедрили CI и e2e, написали и начали использовать Updater для выкатки релизов, отдали часть разработки в другие команды, поддержав плагины. Оказалось важным иметь свой roadmap и vision развития продукта.
Как мы решили, что пора все переписать с нуля? Появилась большая задача "продуктизовать" и выпустить на рынок in-house-решение. Много споров и еще больше усилий в дизайн помогли понять, что разумно переписать с нуля. Большая часть вопросов требовала качественного дизайна, поэтому 4 месяца ушло на разработку первой базовой функциональности, но мы сделали дизайн, на который потом еще за 2 месяца нарастили около 40 фичей.
Как смогли не переписывать что-то вечно? Управляемо накопили долг по фичам, технический долг.
Как смогли сохранить обратную совместимость? По документации старой версии и примерам написали новые тесты. Для каждой проблемы, сравнивая, сколько стоит исправить во всех плагинах (разработка, тестирование, релиз) и у нас.
Как продали идею переписывания руководству? Детально разобрали, что именно хотим получить на выходе, дотошно обсудили критерии сравнения, пользовались экспертными оценками и результатами proof of concept.