Как провести рефакторинг для Startups 2022: причины и компромиссы

(Кросс-пост с веб-сайта Klotho )

Этот пост в блоге представляет собой общий обзор причин рефакторинга кода и систем в настройках запуска. Мы освещаем риски, подходы и компромиссы, которые следует учитывать в 2022 году.

Как определить, когда затраты оправдывают прибыль

Будь честен с собой

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

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

Хорошо структурированный хорошо поддерживается

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

Точки перегиба в бизнесе

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

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

Контролируйте то, что можете, планируйте остальное

Правильный выбор не помешает реархитектуре

Рефакторинг и реархитектура не означают, что вы сделали плохой выбор ранее. Чаще всего движущие силы реархитектуры связаны с изменениями требований или внешними факторами. Есть по крайней мере 4 важных параметра, которые заставят перестроить архитектуру на протяжении всего жизненного цикла продукта: скорость разработки новых функций, размер команды инженеров, количество времени, затрачиваемого на недифференцированную работу, и рост количества клиентов. Каждое из них становится все труднее контролировать напрямую.

Начните с простых циферблатов…

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

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

…а затем перейти к более сложным

Количество времени, которое ваша команда тратит на недифференцированную работу, может быть трудно обуздать, а рост числа клиентов — это самая сложная мера, на которую можно повлиять. Если бы это было легко, все бы свели к минимуму недифференцированную работу и максимизировали бы прирост клиентов! Тем не менее, вы можете

опередить проблемы с осторожным и активным подходом к рефакторингу.

Первый шаг — знать, когда не проводить рефакторинг. Если прирост ваших клиентов и количество времени, затрачиваемого на недифференцированную работу, невелики, не тратьте время на рефакторинг: вместо этого сосредоточьтесь на эффективных, заметных для клиентов функциях. Точно так же, если у вас хороший прирост клиентов и небольшое количество недифференцированной работы, ваша команда работает хорошо. Подумайте о тактическом рефакторинге, чтобы избежать роста объема недифференцированной работы, но не тратьте на нее слишком много времени.

Если ваша команда тратит слишком много времени на недифференцированную работу, пришло время пересмотреть архитектуру, чтобы она лучше масштабировалась до того состояния, в котором находится ваша компания сегодня.

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

Имейте цель, затем найдите ярлыки, чтобы добраться до нее

Имейте план, даже если он не идеален

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

Стройте большие планы, делайте маленькие шаги

Как только вы знаете, где вы хотите разместить код, будьте тактичны в отношении того, как его туда доставить. Работайте с одним компонентом за раз или выбирайте компоненты, которые находятся как можно дальше друг от друга. Если вы еще не вложили средства в надежное тестирование как на уровне модулей, так и на уровне системы, сейчас самое время. Тесты дадут вам уверенность в том, что ваши изменения не нарушат существующий опыт работы с клиентами, но они также могут помочь вашей команде определить свое определение готовности. Когда тесты пройдены, компонент готов!

Лучшая технология та, которую вы можете адаптировать

Ключом к уменьшению влияния рефакторинга и реархитектуры, в частности, на стартапы, является использование адаптируемых технологий.

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

Адаптивная архитектура позволяет одинаково легко размещать приложение на любой технологии. Это позволяет на лету настраивать среду хостинга в соответствии с вашими текущими потребностями. Конкретные варианты технологий, такие как AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP, становятся взаимозаменяемыми.

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

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