«Руководство не даёт мне заняться рефакторингом legacy-кода!» Знакомая ситуация? Раздражает жутко. Большинство разработчиков рано или поздно сталкивается лбами с менеджером, который совершенно не заинтересован в том, чтобы совершенствовать уже готовое. То нужно реализовать что-то новое, то срочно потушить пожар, то исправить какой-то баг… В общем, причина отложить рефакторинг запущенной кодовой базы у них всегда найдётся.
И даже когда пытаешься им объяснять, какие преимущества даёт опрятный код, они то ли не понимают, то ли не хотят понимать. У них только затраты и сроки на уме, а до качества никому нет дела. И получается, что вы абсолютно бессильны что-то сделать с техническим долгом, который всё копится и копится. Программисты работают на прод, а прод – на запросы нетерпеливых пользователей. За рефакторинг никто платить не будет. Положение выглядит безнадёжным.
Попадая в такую ситуацию, многие толковые разработчики просто пакуют вещи и уходят из компании. И очень скоро из-за текучки в отделе уже двери не закрываются: одни уходят, другие приходят…
Менеджеры – не программисты
Решение проблемы состоит в том, чтобы донести до менеджеров, какое влияние низкое качество кода оказывает на бизнес. В конечном счёте, деятельность компании нацелена на получение денег. Прибыли. Соответственно, руководство ищет оптимальные пути урезать расходы и привлечь доходы. А значит, чтобы реабилитировать в их глазах рефакторинг, придётся говорить на их языке.
Мне довелось поработать и техлидом, и консультантом, так что опыт в этом деле у меня большой. Давайте поделюсь с вами некоторыми заготовками.
Пять аргументов, которые вы можете привести
1) «Рефакторинг поможет снизить волатильность предельных издержек на единицу функциональности ПО»
Это точная цитата из замечательного выступления Дж. Б. Рейнсберга на конференции на тему «Экономика в разработке ПО». Стойте, не уходите! Всё, что здесь сказано, вам прекрасно известно, просто оно сформулировано в абстрактно-заумном духе.
Пойдём по порядку:
- «Рефакторинг поможет снизить…» — пока что всё нормально
- «…волатильность…» — иными словами, непредсказуемость
- «…предельных издержек…» — то есть сколько ресурса потребует производство ещё одной дополнительной единицы
- «…на единицу функциональности ПО» — она же фича, имеющая ценность для бизнеса. Ура! Ценность для бизнеса – это как раз то, что нам нужно.
В основе всех пяти аргументов лежит всё та же общая идея о переводе с одного языка на другой, которой мы часто пренебрегаем в общении с людьми, далёкими от сферы IT. Не используйте сленг, напирайте на понятия из экономики и бизнеса – вот и весь секретный ингредиент. Так между вами и руководством быстрее установится связь.
2) «За последние месяц 63% ресурса разработки ушло на исправление проблем с качеством продукта»
Ну, цифры здесь подставите свои. Смысл в том, чтобы подкрепить посыл количественными данными. Технический долг не может не влиять на ваши повседневные рабочие процессы. Можно ли это доказать? Разумеется!
Вот несколько метрик, на которые вы можете обратить внимание:
- Изменение темпов работы со временем. Сколько пунктов из списка вы успеваете обработать за спринт? Не стало ли это число снижаться в последнее время?
- Количество баг-репортов, которые поступают команде за неделю, а также количество исправленных багов за тот же срок. Не выходит ли так, что баги накапливаются? Не слишком ли много времени вы на них тратите?
- Количество аварийных ситуаций, с которыми вы сталкиваетесь за неделю. Сможет ли команда справляться с таким числом на постоянной основе? Не учащаются ли случаи их возникновения?
Покажите руководству, во что именно выливается для них плохое качество кода. А ещё лучше – найдите способ перевести эти цифры в денежный эквивалент.
Как-то я присутствовал на post-mortem бага, которого можно было бы избежать, если бы была проведена проверка типов данных. Код писался на JavaScript. Как раз в то время в компании велись споры о том, стоит ли переходить на TypeScript.
Разработчики, которые разбирались в случившемся, не поленились поднять данные и сумели оценить урон, который баг нанёс бизнесу. Оказалось, что за несколько месяцев своего существования баг высосал из компании миллион канадских долларов. Миллион! Одного этого с головой бы хватило, чтобы окупить стоимость перехода на TypeScript.
Исходя из этого, было принято решение, что новые сервисы будут реализовываться на TypeScript, а для самых ключевых нужно задним числом провести проверку типов данных.
3) «С технической точки зрения, чтобы быстрее выпустить продукт, мы работали в кредит. Теперь нужно выплатить часть долга, чтобы время выхода на рынок не возросло»
Опять же: говорим на языке собеседника. Метафоры бывают очень эффективны, когда нужно донести мысль: они связывают для слушателя незнакомые концепты со знакомыми и тем самым помогают их понять. Понятие «кредит» хорошо знакомо любому менеджеру. Да и сам «технический долг» — тоже метафора, получившая широкое хождение.
Или можно, допустим, представить компанию как ресторан, а кодовую базу – как его кухонную зону. По мере накопления грязной посуды обслуживать возрастающее число посетителей становится всё сложнее и сложнее. Сотрудникам нужно успевать перемыть посуду в перерывах между приготовлением пищи.
4) «Если инвестировать 10% рабочего времени в качество кода, текучесть кадров существенно снизится».
До сих пор мы говорили об очевидных последствиях низкого качества кода. Но есть одна коварная вещь, которую легко упустить из вида: текучка.
В наши дни компании с трудом удерживают при себе разработчиков, особенно талантливых. Если такой перестанет получать удовольствие от работы, для него не составит труда получить другое предложение и просто уйти куда глаза глядят, подальше от вечного хаоса. Да что там, возможно, вы и сами уже поглядываете по сторонам в поисках чего получше…
А теперь давайте зададимся вопросом: во что компании обходится замена уволившегося разработчика? Нового специалиста нужно найти, провести через процесс найма, ввести в курс дела. Это требует вложений, занимает время и затормаживает всю команду. Руководство однозначно предпочло бы не заниматься подобными перестановками каждый год. Поэтому снижение текучести может стать серьёзным аргументом. А сам факт наличия плана по устранению технического долга сразу даст всей команде +100 к мотивации.
5) «Если вложить 20% ресурса в рефакторинг, FRT сократится вдвое и для производительности разработчиков ROI будет положительным»
FRT – это время отклика, важная метрика для пользовательской поддержки. Бизнес стремится к тому, чтобы клиенты были всем довольны.
Здесь мы проделываем следующее:
- Выбираем метрики, которые имеют большой вес в техподдержке;
- Находим пару проблем, которые возникают регулярно и требуют вмешательства разработчиков;
- Предлагаем план по сокращению числа обращений в техподдержку за счёт устранения исходной причины.
- Если проблемы такого рода разрешатся, разработчиков реже будут привлекать к задачам, связанным с поддержкой пользователей. То есть у них освободится больше времени, чем было затрачено на рефакторинг, а значит, вложение окупится – тот самый положительный ROI.
В конечном счёте, решать им
С этим никто не поспорит. Я предложил пять аргументов, которыми можно убедить людей в важности устранения технического долга, но теперь, думаю, следует дать ещё один дополнительный совет, прежде чем вы пойдёте обрабатывать какого-нибудь менеджера.
Проводите рефакторинг по ходу дела
Рефакторинг не должен рассматриваться как отдельный этап работы над функциональностью. Ведь вы всё равно не можете заранее предсказать, какие возможности будут внедряться в будущем. Значит, нужно подгонять кодовую базу под новые реалии по мере их поступления. Это тоже часть работы, необходимая для создания той самой материальной ценности – любой разработчик-профессионал это подтвердит.
Правило работает даже для баз с legacy-кодом. Ну ладно, в божеский вид вы её к завтрашнему дню точно не приведете. И пытаться проводить крупномасштабный рефакторинг между делом – тоже дохлый номер. Но с таким подходом положение, по крайней мере, не будет ухудшаться. А в работе с legacy-кодом приходится ориентироваться не на «хорошо», а на «лучше».
Исправляете баг? Потратьте лишний час на написание автоматического теста. Готовитесь выкатывать новую фичу? Потратьте лишний день, чтобы подчистить код. День изо дня старайтесь, чтобы изменения происходили безболезненно. Через несколько месяцев вы заметите, что эта привычка оказала огромное влияние на вашу производительность. А знаете почему? Потому что рефакторинг помогает снизить волатильность предельных издержек на единицу функциональности ПО.
