Архитектурный или проектный рефакторинг это всегда болезненная проблема на проекте. Польза от рефакторинга, для нас технических специалистов очевидна, но продать и обосновать эту идею клиенту зачастую бывает тяжело. Главная причина в том, что мы технические специалисты не знаем как говорить с бизнесом.
Главная проблема в коммуникации между техническими специалистами и людьми, которые делают деньги. Они говорят на разных языках, хотя и пытаются решить одни и те же проблемы.
Данная статья является переводом оригинала с английского: Architecture Refactoring and Design Refactoring How to Sell it Client. Если у вас есть коллеги, не владеющие русским языком, они могут прочитать оригинал на моем болге.
Польза от рефакторинга очевидна для всех технических специалистов, но зачастую мы не можем донести эту идею до бизнеса. Почему так случается? Мы пропускаем несколько незначительных для нас, но очень важных шагов для бизнеса.
Разделим весь процесс на 6 простых, но обязательных шагов:
Этот шаг довольно привычен для нас технических специалистов. Рассмотрим его на реальных примерах.
Билд падает практически после каждого комита.
Есть несколько причин почему это может происходить:
Еще один пример. Деплоймент приложения занимает длительное время, а также наблюдаются проблемы с производительностью.
Основными причинами могут быть:
Следующий шаг немного сложнее, но все еще привычный и несложный для разработчиков senior+. Мы все хорошие технические специалисты и всегда знаем, что должно быть улучшено. И в этот момент мы совершаем ошибку и бежим к клиенту со словами давай сделаем это.
Но мы разумные архитекторы и будем следовать нашему плану из 6 шагов шаг за шагом.
На основе предыдущего примера с монолитным приложением, решения очевидны. Разбить большое сложное приложение на более маленькие независимые модули. Это первые шаги к сервес-ориентированной или микросервисной архитектуре.
Разделим этот шаг на две фазы: техническое и бизнес обоснование.
Техническое обоснование выглядит логично для нас. Разбить монолит на более мелкие сервиса, в следствии чего мы получим:
Обоснование с точки зрения бизнеса – очень важный шаг, про который часто забывают технические специалисты. Вы должны помнить, что важно для бизнеса. Правильно – это деньги.
Если кратко: если рефакторинг не приносит пользу бизнесу – его нет смысла делать.
На основе нашего примера, вы можете предложить клиенту следующие преимущества:
План должен быть четким и детальным. Каждая итерация должна быть четко описана и должны быть задокументированы все архитектурные и дизайнерские изменения.
Создавай свой план вы должны ответить на следующие вопросы:
Очень важный шаг. Не пожалейте времени на это, если действительно хотите продать рефакторинг бизнесу.
Каждый менеджер и бизнесмен хочет знать ответы на два вопроса:
Постарайтесь разбить рефакторинг на маленькие итерации. Каждая итерация должна приносить техническую и бизнес ценность. Довольно тяжело продать рефакторинг на годы и стоимостью в миллионы долларов без каких-либо промежуточных результатов.
Каждая итерация должна содержать информацию о продолжительности и количестве специалистов необходимых для этого. Эта информация поможет ответить менеджеру на два основных вопроса заданных чуть выше.
Собирайте метрики проекта до и после рефакторинга на каждой итерации. Это поможет вам показать какую техническую и бизнес ценность принесла эта итерация.
Прежде чем пойти со своим решением к бизнесу, проверь его со своим непосредственным менеджером. Взгляд со стороны всегда хорошо, особенно если это взгляд со стороны бизнеса. Возможно, у вашего менеджера больше контекста и он поможет вам поменять план в соответствии с ожиданиями бизнеса.
Вы должны знать как ответить на классический вопрос.
Обычно когда вы презентуете архитектурный рефакторинг, бизнес может спросить. Почему нам нужен рефакторинг? В прошлом году мы потратили достаточно средств на архитектуру, а теперь у нас снова проблемы.
На классический вопрос есть классический ответ. Этот архитектурное решение было хорошо год назад, но бизнес растет и меняется и архитектура должна меняться вместе с ним.
Совет №2. Не заставляете паниковать своего клиента. Предоставляйте информации как срочную, но не как катастрофа. Скажите, что у вас есть полгода на рефакторинг, но начинать его надо прям сегодня.
Напоследок. Презентуя свое решение старайтесь образовывать людей, а не обвинять. Помните, что, обвиняя людей вы столкнетесь с сопротивлением с их стороны. Вы должны искать пути решения проблем, а не виновных.
Больше статей по архитектуре и architecture soft skills вы найдете на оригинальном ресурсе.
Всем хорошего рефакторинга!
Главная проблема в коммуникации между техническими специалистами и людьми, которые делают деньги. Они говорят на разных языках, хотя и пытаются решить одни и те же проблемы.
Данная статья является переводом оригинала с английского: Architecture Refactoring and Design Refactoring How to Sell it Client. Если у вас есть коллеги, не владеющие русским языком, они могут прочитать оригинал на моем болге.
Польза от рефакторинга очевидна для всех технических специалистов, но зачастую мы не можем донести эту идею до бизнеса. Почему так случается? Мы пропускаем несколько незначительных для нас, но очень важных шагов для бизнеса.
Разделим весь процесс на 6 простых, но обязательных шагов:
- Определить причину проблемы
- Решить какие изменения должны быть сделаны
- Обоснование решения
- Составить план рефакторинга
- Создать roadmap
- Презентовать свое решение
Найдите причину проблемы
Этот шаг довольно привычен для нас технических специалистов. Рассмотрим его на реальных примерах.
Билд падает практически после каждого комита.
Есть несколько причин почему это может происходить:
- Компоненты приложения очень тесно связаны между собой и зависят друг от друга
- Компоненты приложения не имеют должной изоляции между собой
- Отсутствие unit тестов
- Отсутствие SDLC процессов и CI/CD
Еще один пример. Деплоймент приложения занимает длительное время, а также наблюдаются проблемы с производительностью.
Основными причинами могут быть:
- Монолитное приложение растет быстро и стало слишком большим для одного приложения
- Приложение большое и потребляет много оперативной памяти и процессорных мощностей
- Приложение сложное и написано не эффективно
Решаем какие изменения должны быть сделаны
Следующий шаг немного сложнее, но все еще привычный и несложный для разработчиков senior+. Мы все хорошие технические специалисты и всегда знаем, что должно быть улучшено. И в этот момент мы совершаем ошибку и бежим к клиенту со словами давай сделаем это.
Но мы разумные архитекторы и будем следовать нашему плану из 6 шагов шаг за шагом.
На основе предыдущего примера с монолитным приложением, решения очевидны. Разбить большое сложное приложение на более маленькие независимые модули. Это первые шаги к сервес-ориентированной или микросервисной архитектуре.
Обоснование решения
Разделим этот шаг на две фазы: техническое и бизнес обоснование.
Техническое обоснование выглядит логично для нас. Разбить монолит на более мелкие сервиса, в следствии чего мы получим:
- Более разрозненные компоненты
- Проблемы с билдом будут не такие частые
- Маленькие сервиса потребляют меньше оперативной памяти и процессорных мощностей, как следствие – лучшая производительность
- Отдельные сервиса можно задеплоить быстрее и не зависимо друг от друга
Обоснование с точки зрения бизнеса – очень важный шаг, про который часто забывают технические специалисты. Вы должны помнить, что важно для бизнеса. Правильно – это деньги.
Если кратко: если рефакторинг не приносит пользу бизнесу – его нет смысла делать.
На основе нашего примера, вы можете предложить клиенту следующие преимущества:
- Новый функционал будет разрабатываться быстрее
- Качество приложения будет лучше, как следствие меньше затрат на bug fix и довольный пользователь приложения, что так же положительно сказывается на бизнесе
- Уменьшение затрат на разработку и деплоймент
- Проще найти мотивированный и опытных специалистов готовых работать с проектом.
План рефакторинга
План должен быть четким и детальным. Каждая итерация должна быть четко описана и должны быть задокументированы все архитектурные и дизайнерские изменения.
Создавай свой план вы должны ответить на следующие вопросы:
- Какая цель этой итерации?
- Какая техническая и бизнес ценность этой итерации?
- Как сократить продолжительность итерации?
Roadmap
Очень важный шаг. Не пожалейте времени на это, если действительно хотите продать рефакторинг бизнесу.
Каждый менеджер и бизнесмен хочет знать ответы на два вопроса:
- Сколько это будет стоить?
- Как много времени это займет?
Постарайтесь разбить рефакторинг на маленькие итерации. Каждая итерация должна приносить техническую и бизнес ценность. Довольно тяжело продать рефакторинг на годы и стоимостью в миллионы долларов без каких-либо промежуточных результатов.
Каждая итерация должна содержать информацию о продолжительности и количестве специалистов необходимых для этого. Эта информация поможет ответить менеджеру на два основных вопроса заданных чуть выше.
Собирайте метрики проекта до и после рефакторинга на каждой итерации. Это поможет вам показать какую техническую и бизнес ценность принесла эта итерация.
Презентую свое решение
Прежде чем пойти со своим решением к бизнесу, проверь его со своим непосредственным менеджером. Взгляд со стороны всегда хорошо, особенно если это взгляд со стороны бизнеса. Возможно, у вашего менеджера больше контекста и он поможет вам поменять план в соответствии с ожиданиями бизнеса.
Вы должны знать как ответить на классический вопрос.
Обычно когда вы презентуете архитектурный рефакторинг, бизнес может спросить. Почему нам нужен рефакторинг? В прошлом году мы потратили достаточно средств на архитектуру, а теперь у нас снова проблемы.
На классический вопрос есть классический ответ. Этот архитектурное решение было хорошо год назад, но бизнес растет и меняется и архитектура должна меняться вместе с ним.
Совет №2. Не заставляете паниковать своего клиента. Предоставляйте информации как срочную, но не как катастрофа. Скажите, что у вас есть полгода на рефакторинг, но начинать его надо прям сегодня.
Напоследок. Презентуя свое решение старайтесь образовывать людей, а не обвинять. Помните, что, обвиняя людей вы столкнетесь с сопротивлением с их стороны. Вы должны искать пути решения проблем, а не виновных.
В заключение
- Рефакторинг дорогое удовольствие и его тяжело продать бизнесу
- Архитектурный рефакторинг это не только техническая проблема, его еще нужно продать бизнесу
- Помните о том какую пользу рефакторинг принесет бизнесу
- Всегда легче продавать маленький рефакторинг, но часто, чем большой, но один раз
Больше статей по архитектуре и architecture soft skills вы найдете на оригинальном ресурсе.
Всем хорошего рефакторинга!
DrPass
Есть важный нюанс: рефакторинг далеко не всегда приносит пользу бизнесу ваших клиентов, но практически всегда приносит пользу вашему бизнесу :)
Это его свойство также очень сильно влияет на настойчивость в предложении отрефакторить существующую систему. В остальном, я не претендую на объективность, это лишь мои личные наблюдения, но случаев, когда экономический выхлоп от рефакторинга в сумме был нулевой или отрицательный, подавляющее большинство. По крайней мере, если система существует не один год, то там уже накоплено огромное значительное количество бизнес-кейсов, которые даже при наличии документации нереально собрать в требованиях к новой системе. И соответственно, после рефакторинга будет ещё длительный мучительный период адаптации обновлённой системы.
ApeCoder
"Рефа?кторинг, или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы"
Так что либо это не рефакторинг либо требования останутся соблюдены
EvokSinister
Мне кажется, что товарищ DrPass говорил скорее о том, что если исходная система напоминает дремучий лес, то рефакторинг в таком случае смешивается в проклятом браке с переписыванием. В отличие от ситуации, когда взяли и выбросили старую систему, начав писать новую с нуля.
Просто если мы говорим об огромных проектах с огромнейшим же легаси, то тут как раз такая ситуация.
ApeCoder
Вот эти вот все товарищи, которые учат нас рефакторингу как раз сконцентрированны на том, чтобы это было серией эквивалентных преобразований не ломающих функциональность.
Если оно смешивается, то это уже не рефакторинг (или не только рефакторинг).
DrPass
Так бывает только в частных случаях. В общем случае архитектурный рефакторинг вроде «сделать из монолита микросервисы» подразумевает «собрать требования к старой системе, спроектировать новую архитектуру, реализовать заново с возможным переиспользованием кусков старой системы». И сложности возникнут ещё на первом шаге.
ApeCoder
Я бы не называл это рефаторингом. Это переписывание.
Вот, например, способ разбиение постепенно без полного переписывания. https://martinfowler.com/articles/extract-data-rich-service.html
funca
Возможно есть разница между Architecture refactoring и рефакторингом уровня кода. Мне сложно представить ситуацию, когда изменения в архитектуре не повлияют на какие-то функциональные или нефункциональные характеристики приложения.
VolCh
Конкретно задача «сделать из монолита микросервисы» обычно не подразумевает реализацию системы заново. Большей частью это чисто инфраструктурный рефакторинг: перенос кода и данных модулей из монолита в отдельные сервисы и замена локальных вызовов на удаленные.
funca
Затея выглядит как заменить в машине бензиновый двигатель на пачку реактивных. Если все пройдет так, что сторонний наблюдатель не заметит ни каких изменений, то это рефакторинг. А если заметит, то — апгрейд. Мне кажется, что первый вариант это немножко невыполнимая миссия, т.к. в результате неизбежно появятся новые ручки и эксплуатационные требования.
VolCh
Сильно зависит от наблюдателя и что считать поведением. С какой-то точки зрения сколь нибудь значимые рефакторинги вообще невозможны, ну, например, чтоб не изменилось (или хотя бы не увеличилось) потребление ресурсов.
А если подходить прагматично, то обычно рефакторингом можно считать изменения программы, не влияющие на её функциональное поведение для целевых пользователей в нормальных условиях.
С таким подходом разбить монолит на микросервисы вполне задача чистого рефакторинга, без создания новой системы. Легко делящаяся на независимые этапы (кроме общей подготовки инфраструктуры), в любой момент могущая быть поставленной на паузу с эксплуатацией того, что уже сделано, прозрачная для конечного пользовател в его обычной работе. Ну, грубо говоря, вместо 500 будут иногда 502 ошибки и в целом количество 500-х увеличится скорее всего. Но это будет та же система.
VolCh
Вы не путаете рефакторинг с созданием новой системы?
DrPass
Так архитектурный рефакторинг в значительной мере и является созданием новой системы, под старым логотипом.
funca
Создание новой системы под старым логотипом это довольно известный прием ещё из детских сказок. Каша из топора. Тут главное сразу определиться, на чьей стороне есть ресурсы.
amarao
Есть рефакторинг снизу, а есть рефакторинг сверху. Вот тут продают рефакторинг сверху. А хороший — это всегда рефакторинг снизу.
Грубо говоря, рефакторинг снизу: кто-то гит открыл, нырнул, г-на наелся, вынырнул, решил, что хватит, исправил в том месте, где мерзко было.
Рефакторинг сверху: Одно г-но снизу заменяют на г-но сверху.