Техобслуживание кода. Как «продать» рефакторинг бизнесу

Несколько дней назад я написал статью про основные характеристики старого кода. Однако там было слишком мало конкретных практических рекомендаций о том, как жить в условиях старого кода.

Сегодня я постараюсь ответить на один из самых частых вопросов, которые я слышу, когда речь идёт о разработке систем с запредельным количеством legacy, и поделюсь своим взглядом на то, как «продать» бизнесу рефакторинг.

В этой статье я принципиально ограничиваюсь описанием взаимодействия с бизнесом и не касаюсь технических деталей (как именно рефакторинг проводить). Пост написан исключительно на личном успешном и не очень опыте «продажи» и «покупки» рефакторинга в разных командах и в разных компаниях.

Предпосылки

Итак, чтобы быть более конкретными, давайте представим, что у нас есть флагманский продукт, который работает уже несколько (иногда – десяток) лет и приносит львиную долю доходов компании.

Обычно при этом наблюдаются примерно следующие особенности продукта:

• «пластилиновая архитектура» – за время жизни продукт оброс большим числом дополнительных функций, которые были добавлены в спешке. Это привело к тому, что логика системы равномерно размазана по всему коду, в некоторых местах встречаются «хаки», которые позволяют «сделать странное» в обход первоначальной задумки.
• отсутствие юнит-тестов – текущая логика не покрыта тестами чуть более, чем полностью. «Потому что про юнит тесты думали на третий год жизни системы, но их уже непонятно, как и куда встраивать, да и времени на тесты было мало».
• отсутствие экспертов – люди, которые изначально писали продукт, либо сидят в должности больших руководителей, либо уволились, либо уже забыли за много лет, как всё внутри устроено.

Я описал типичную ситуацию, в которой находится огромное количество продуктов в разных компаниях. Причём, что характерно, уровень разработчиков может быть очень даже высокий. Просто с каждым годом код становится всё больше и запутаннее.

Понятно, что такой код рано или поздно придётся рефакторить. Но как добыть под эту задачу время в условиях постоянного потока продуктовых задач? Именно об этом мы и поговорим ниже.

А может переписать всё с нуля?

Вы можете об этом помечтать, но шансов, что удастся кого-то в этом убедить, крайне мало. Более того, если вам удастся убедить руководство выкинуть старый код и написать всё заново, то это говорит о том, что, либо это самое руководство не умеет оценивать риски, либо компания настолько богата, что может позволить себе долгое время (иногда – несколько лет) содержать параллельную «стратегическую» команду программистов, не приносящих текущей прибыли.

А вообще, почитайте Джоэла Спольски. Он дело говорит (хотя, по официальной версии Netscape всё-таки был выбит с рынка бесплатным IE, а не задержками в обновлениях).

И ещё: надо понимать, что проект «перепишем всё с нуля» может занять годы, а поддержкой старого кода в это время заниматься придётся всё равно. Поэтому то, что написано ниже важно в любом случае.

Итак, как же убедить бизнес, что рефакторинг всё-таки нужен?

Совет 1. Не продавайте бизнесу рефакторинг!

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

Обратим внимание на два пункта:

• цель рефакторинга – упростить понимание и модификацию кода – чисто техническая, а не бизнесовая
• поведение не меняется, то есть результат для бизнеса не заметен

Это значит, что при удачно проведённом рефакторинге изменений не будет. Никаких! При менее удачном – в работающем коде будут ошибки и различия в поведении. То есть, вы не сможете сказать «мы исправили 10 багов и реализовали суперскую фишку». Вы сможете сказать «теперь код стал красивее, а архитектура более простой и понятной. Ну да, и появилась пара багов… Но мы их обязательно исправим!».

А теперь представьте себя на месте бизнеса. Команда дорогостоящих специалистов потратила кучу времени на «наведение красоты» вместо того, чтобы делать вполне понятные фичи, которые приносят пользователей и деньги. Это всё равно, что, отдав машину в автосервис, получить её в неизменном виде и счёт на $500 с запиской «мы перебрали вам подвеску и теперь сможем поменять стойки в три раза быстрее. Возможно, первое время будет что-то постукивать, но должно пройти через месяц. Если не пройдёт – приезжайте, мы поправим за умеренную плату». Не знаю, как вам, а мне бы такое не очень понравилось.

В общем, первое правило такое: покупают только то, что интересно покупателю или то, в чём вы его заинтересовали. Модификация кода сама по себе для бизнеса не ценна и никому кроме разработчиков не интересна. Поэтому, главная ошибка, которую вы можете допустить – это сказать: «нужно сделать рефакторинг, потому что плохой код, и ничего не понятно».

Тогда что говорить?

Совет 2. Продавайте бизнесу возможности и решение проблем

Думаю, каждый из нас интуитивно понимает, что проблемы с плохим кодом ведут не только к боли разработчиков при работе с ним, но и к определённым проблемам в бизнесе. Если попробовать формализовать это понимание, то мы приходим к двум самым серьёзным проблемам.

Во-первых – это нестабильное поведение системы – странные баги, проблемы с производительностью, непредсказуемое поведение, потери данных (это, наверное, самое страшное) и так далее. Это, в свою очередь, ведёт к недовольству пользователей, отказам, плохим отзывам, низкими рейтингами в сторах в случае мобильных приложений. В общем, влияет на прибыль самым прямым образом.

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

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

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

Совет 3. Взгляните на разработку со стороны бизнеса

Как уже было написано выше, первое правило аргументации – понять ценности собеседника. В данном случае, имеет смысл взглянуть на рефакторинг со стороны бизнеса.

С точки зрения бизнеса у любой фичи есть затраты на разработку и профит от внедрения. Затраты состоят из нескольких частей. Во-первых, это деньги, которые команда тратит на разработку фичи. Сюда входит зарплата разработчиков, налоги, аренда офиса, оборудования, электроэнергия и так далее. К менее очевидным, но не менее важным относятся затраты, связанные с упущенной выгодой: за время разработки текущей фичи в продукте не появляются другие функции, которые не приносят денег и не привлекают новых пользователей.

Очевидно, что важность фичи можно легко прикинуть, сравнив планируемый профит от неё и затраты на её реализацию. С этой точки зрения рефакторинг – это инвестиция в чистом виде. Ресурсы тратятся, но ни новых пользователей, ни новых функций у продукта в результате не появляется.

И ваша основная задача – показать бизнесу, почему инвестиции в рефакторинг принесут выгоду в разумные сроки.

Как же эту выгоду показать?

Совет 4. Оперируйте цифрами

Чтобы принять решение о проведении рефакторинга, бизнесу надо, во-первых, получить оценку трудозатрат на его проведение (это вы, скорее всего, делаете регулярно), а во-вторых – понять профит от его результатов. И это один из сложных моментов. Как бы ни хотелось сказать: «у нас много багов» или «если мы проведём рефакторинг, то сможем сэкономить время при внесении дальнейших изменений», смысла для бизнеса эти слова не будут иметь никакого.

Для того, чтобы прийти с нормальным численным обоснованием, придётся позаниматься административной работой. Например, собрать в один список все баги, которые не удаётся исправить за разумное время в текущей реализации, и которые исправятся после рефакторинга. Более сложный и кропотливый труд – вести учёт, сколько времени занимает каждое изменение, и к каждой цифре дописывать время, которое занимало бы это изменение в системе после рефакторинга. Это на порядок сложнее, но и результаты даёт гораздо более ощутимые. Потому как, «изменение, которое позволило бы нам сохранить X человеко-часов разработки за последний месяц и позволит экономить примерно столько же в будущем» звучит для бизнеса гораздо понятнее и убедительнее, чем необходимость «привести код в порядок».

Тут есть ещё один тонкий момент. При оценке главное – не приукрашивать, не делать светлое будущее светлее, чем оно будет на самом деле и не занижать затраты на рефакторинг. Ведь после того, как заветное «добро» на рефакторинг получено, вы будете именно тем человеком, которое пообещал светлое будущее и потратил бюджет, а в результате…

…а в результате, всё зависит от вас. Если вы уверены, что рефакторинг сможет помочь отловить застарелые баги, ускорить разработку, сделать код чище и понятнее, а пользователя – счастливее, то вперёд.

И Удачи!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.