Comments 25
Если кратко: если рефакторинг не приносит пользу бизнесу – его нет смысла делать.
Есть важный нюанс: рефакторинг далеко не всегда приносит пользу бизнесу ваших клиентов, но практически всегда приносит пользу вашему бизнесу :)
Это его свойство также очень сильно влияет на настойчивость в предложении отрефакторить существующую систему. В остальном, я не претендую на объективность, это лишь мои личные наблюдения, но случаев, когда экономический выхлоп от рефакторинга в сумме был нулевой или отрицательный, подавляющее большинство. По крайней мере, если система существует не один год, то там уже накоплено огромное значительное количество бизнес-кейсов, которые даже при наличии документации нереально собрать в требованиях к новой системе. И соответственно, после рефакторинга будет ещё длительный мучительный период адаптации обновлённой системы.
"Рефа́кторинг, или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы"
Так что либо это не рефакторинг либо требования останутся соблюдены
Просто если мы говорим об огромных проектах с огромнейшим же легаси, то тут как раз такая ситуация.
По крайней мере, если система существует не один год, то там уже накоплено огромное значительное количество бизнес-кейсов, которые даже при наличии документации нереально собрать в требованиях к новой системе.
Мне кажется, что товарищ DrPass говорил скорее о том, что если исходная система напоминает дремучий лес, то рефакторинг в таком случае смешивается в проклятом браке с переписыванием.
Вот эти вот все товарищи, которые учат нас рефакторингу как раз сконцентрированны на том, чтобы это было серией эквивалентных преобразований не ломающих функциональность.
Если оно смешивается, то это уже не рефакторинг (или не только рефакторинг).
Вот эти вот все товарищи, которые учат нас рефакторингу как раз сконцентрированны на том, чтобы это было серией эквивалентных преобразований не ломающих функциональность.
Так бывает только в частных случаях. В общем случае архитектурный рефакторинг вроде «сделать из монолита микросервисы» подразумевает «собрать требования к старой системе, спроектировать новую архитектуру, реализовать заново с возможным переиспользованием кусков старой системы». И сложности возникнут ещё на первом шаге.
Я бы не называл это рефаторингом. Это переписывание.
Вот, например, способ разбиение постепенно без полного переписывания. https://martinfowler.com/articles/extract-data-rich-service.html
Конкретно задача «сделать из монолита микросервисы» обычно не подразумевает реализацию системы заново. Большей частью это чисто инфраструктурный рефакторинг: перенос кода и данных модулей из монолита в отдельные сервисы и замена локальных вызовов на удаленные.
Затея выглядит как заменить в машине бензиновый двигатель на пачку реактивных. Если все пройдет так, что сторонний наблюдатель не заметит ни каких изменений, то это рефакторинг. А если заметит, то — апгрейд. Мне кажется, что первый вариант это немножко невыполнимая миссия, т.к. в результате неизбежно появятся новые ручки и эксплуатационные требования.
Сильно зависит от наблюдателя и что считать поведением. С какой-то точки зрения сколь нибудь значимые рефакторинги вообще невозможны, ну, например, чтоб не изменилось (или хотя бы не увеличилось) потребление ресурсов.
А если подходить прагматично, то обычно рефакторингом можно считать изменения программы, не влияющие на её функциональное поведение для целевых пользователей в нормальных условиях.
С таким подходом разбить монолит на микросервисы вполне задача чистого рефакторинга, без создания новой системы. Легко делящаяся на независимые этапы (кроме общей подготовки инфраструктуры), в любой момент могущая быть поставленной на паузу с эксплуатацией того, что уже сделано, прозрачная для конечного пользовател в его обычной работе. Ну, грубо говоря, вместо 500 будут иногда 502 ошибки и в целом количество 500-х увеличится скорее всего. Но это будет та же система.
Вы не путаете рефакторинг с созданием новой системы?
Есть рефакторинг снизу, а есть рефакторинг сверху. Вот тут продают рефакторинг сверху. А хороший — это всегда рефакторинг снизу.
Грубо говоря, рефакторинг снизу: кто-то гит открыл, нырнул, г-на наелся, вынырнул, решил, что хватит, исправил в том месте, где мерзко было.
Рефакторинг сверху: Одно г-но снизу заменяют на г-но сверху.
Маленькие сервиса потребляют меньше оперативной памяти и процессорных мощностей, как следствие – лучшая производительность
С точки зрения бизнеса, сервисы станут потреблять ещё больше ресурсов.
Так как раньше была нужна всего 1 машина с условными 4 гигами. То после такого рефакторинга нужно будет предположим 4 машины для сервисов с 2 гигами каждая.
Либо поднять их все на 1й но тогда разница или будет отсутствовать или будет в большую сторону.
А если возвести степень изоляции в идеал, то ещё + машина под шину, и + собственный инстанс БД для каждого сервиса.
Мне кажется автор статьи или не верно изложил свою мысль, или намеренно вводит в заблуждение.
Тут варианты есть. Например, было 4 машины с 4 гигами, а стало 3 машины с 1 гигом и 1 машина с 4 гигами. 4 гига было нужно только для формирования отчётов, которые вынесли в отдельный сервис, а для обычной работы 100 пользователей достаточно 1 машины с 1 гигом. Сейчас пользователей 250, будет 500 — добавим ещё 2-3 машины с 1 гигом, а не столько же машин с 4 гигами. Усложнятся отчёты — добавим ещё 4 гига на одну машину, а не на четыре.
Собственно возможность раздельного горизонтального масштабирования — один из основных плюсов SOA/MSA, очень понятных для бизнеса. Пока у вас всё держит нагрузку на 1 машине, про "меньше ресурсов" лучше не заикаться. А вот когда вы начинаете увеличивать количество машин или ресурсов на них ради одной-двух функций системы, то это хороший аргумент.
если рассматривать монолит, то он будет всегда потреблять одно и тоже количество оперативной памяти, но при недогрузке ресурсы будут протаивать, а при перегрузке будут проблемы с производительностью.
Эта точка зрения справедлива только при аренде облачных серверов с балансировкой. Если же сервер локальный, то конфигурируется под максимальную нагрузку, и то что он простаивает в момент меньшей нагрузки мало кого волнует, а часто даже полезно, т.к. могут проводится какие то работы по обслуживанию в «тех.окно».
С сервисной архитектурой и с локальными серверами можно играться. Особенно в случае форс-мажоров. Грубо, маркетологи хорошо поработали и народ повалил покупать куда больше чем рассчитывали (но любые объёмы поставить можем). Отрубаем все второстепенные сервисы, и на эти ресурсы ставим продающие.
Хорошим примером когда рефакторинг был инициирован и успешно сделан — это Amazon AWS. Его сделали как рефакторинг существующей системы и потом на него же перевели все службы самого магазина Amazon. Показательно, что при этом возник новый LOB с очень немаленькой прибылью. Технари никогда бы не сделали сами такого решения.
Отличное обоснование :)
Продаем Architecture Refactoring клиенту или в чем проблема девелоперов