Рефакторинг или переписывание. Когда рефакторить или переписывать код? Какие факторы следует учитывать перед принятием окончательного решения?
Знаете ли вы, что в компаниях со 100+ разработчиками и/или активной кодовой базой из 500 000+ строк кода на техническое обслуживание приходится более половины всего бюджета разработки? Это много, верно?
В MasterBorn мы новички в теме управления техническим долгом. Большинство наших разработчиков программного обеспечения пишут совершенно новый код. Но в последнее время к нам приходит все больше клиентов с уже существующей кодовой базой, которая обычно требует рефакторинга или полного переписывания унаследованной системы.
Рефакторинг против перезаписи
Люди приходят к нам с проектами, которые требуют много размышлений и принятия действительно трудных решений. Обычно они касаются ключевых бизнес-решений — добавления новых функций или небольшого замедления, чтобы погасить технический долг.
В прошлом было проще принять решение о рефакторинге или переписывании, потому что мы работали над нашим продуктом, а не консультировались с чужим старым кодом или старой системой, о которой мы очень мало знаем.
Как технический директор я пытался найти решение, которое помогло бы нам подойти к таким случаям в наших проектах по разработке программного обеспечения. И обратите внимание, что мы наткнулись на команды, у которых практически не было кода, готового к приложению, или которые уже запускали приложение с реальными клиентами еще до того, как мы приняли решение о рефакторинге.
Что лучше: рефакторинг или переписывание старого кода? Вот что я бы подумал.
1. Рефакторинг или переписывание: непрерывность бизнеса
Основная цель привлечения разработчиков программного обеспечения — в конечном итоге продать продукт. Иногда бывает так, что вам нужно быстро добавить функциональные возможности, повернув их. Но в большинстве случаев это связано с одной серьезной ценой: стоимость технического долга — это ваш исходный код, поскольку он создан для доставки как можно скорее.
Если у вас уже есть приложение, которым пользуются клиенты, вы, вероятно, склоняетесь к рефакторингу.
Ведь переписывать приложение с нуля — значит потерять все деньги и усилия, вложенные в ваше текущее приложение. Не говоря уже о том, чтобы сбить ковер с ног ваших клиентов.
Выбор между рефакторингом и переписыванием — непростая задача, но некоторые компании достаточно смелы, чтобы переписать свои приложения (и впоследствии получить много преимуществ от этого решения).
Большую часть времени в MasterBorn мы обычно занимаемся рефакторингом, улучшением и внесением изменений — если только качество существующего исходного кода не очень низкое (я люблю макароны, но спагетти-код — не мое любимое блюдо…). В таком сценарии мы склонны переписывать код параллельно.
2. Рефакторинг против перезаписи: деньги
Создание программного обеспечения — это не просто развлечение. Это также (и tbh: всегда) о деньгах.
Всякий раз, когда команды беспокоятся о сроках и/или имеют строгие ограничения в своих бюджетах, они, как правило, проводят рефакторинг, а не полностью переписывают существующее приложение. Это естественный выбор, учитывая ограничения, с которыми вы имеете дело.
Забавный факт: переписывание приложения может принести вам даже больше денег, чем рефакторинг большого комка грязи, с которым разработчики, возможно, оставили вам разбираться.
Мы говорим о серьезных проблемах с архитектурой, глючных приложениях или функциях, которые просто не работают.
Технический долг стоит реальных денег. Анализ долга, проведенный CAST Research Labs (CRL) в 1400 приложениях в 160 компаниях, показал, что средний размер приложения, состоящего из 300 тысяч строк кода, имеет долг на сумму 1 083 000 долларов. Это 3,61 доллара за строку кода!
3. Рефакторинг или переписывание: время
У вас мало времени? Кто нет? Ваша цель — вывести приложение на рынок как можно быстрее, а сроки быстро приближаются?
Если это так, то у вас, вероятно, нет другого выбора, кроме рефакторинга приложения. Компании обычно попадают в такую ситуацию, когда решают добавить новые функции, которые необходимы приложению с первого дня. У их команды разработчиков не было времени реализовать это из-за различных ограничений.
В результате их проект может потребовать рефакторинга и редизайна, поскольку они изо всех сил пытаются наверстать упущенное и при этом создавать качественное программное обеспечение.
Когда вы очень ограничены во времени, вопрос о рефакторинге или переписывании больше не стоит, потому что рефакторинг может быть вашим единственным решением (но в некоторых случаях у вас не будет времени даже на это).
4. Рефакторинг или переписывание: опыт
Вы не можете получить отличный хлеб без опытного пекаря. Если ваша команда очень неопытна или ее действия привели вас к тому, что вы не можете легко двигаться вперед, то переписывание может быть скорее проблемой, чем реальным преимуществом. Вы также хотите убедиться, что над вашим программным обеспечением больше не работают одни и те же люди (по крайней мере, не одни).
Те же самые люди, которые делают то же самое в новом приложении, не дадут вам другого результата. Они только сожгут ваши деньги.
Рассмотрим цитату Альберта Эйнштейна: «Безумие — это делать одно и то же снова и снова, но ожидать разных результатов».
Он был физиком, а не программистом. Но он точно знал, о чем говорил.
В этом случае гораздо эффективнее найти более опытного разработчика программного обеспечения. Этот человек может возглавить вашу команду и помочь переписать ваше приложение, чтобы внести новые значимые изменения в вашу систему.
Но будьте осторожны с этим сценарием: сверхопытные люди могут склонны слишком долго обдумывать свои решения, что может привести к затягиванию любого выбранного пути.
5. Рефакторинг или переписывание: команда
Как я уже говорил, вам нужны опытные разработчики программного обеспечения и другие специалисты в нужном месте. Но не забывайте об их «командном факторе».
Добавление дополнительных людей в вашу команду для масштабирования не ускорит рефакторинг или переписывание вашего приложения.
Знаете, как говорят: девять женщин не могут родить ребенка за месяц, и это относится и к застройщикам. На самом деле это может привести к обратному — особенно если вы берете людей со скамьи или, что еще хуже, отдаете их на аутсорсинг.
«Выбрасывание ресурсов» на решение сложных проблем может не принести пользы вашему коду. Кроме того, вам придется потратить немного времени, чтобы убедиться, что новые люди интегрируются в команду и знакомятся с кодом. Им также потребуется время, чтобы подумать о правильных решениях и о том, где и как их реализовать. Не говоря уже о том, чтобы действовать в соответствии с ценностями компании и действительно вписываться в культуру организации.
Общий вывод здесь заключается в том, что вам нужны люди, которые будут работать над решением проблем эффективно, и вы должны доверять им, что они знают свое дело — независимо от того, решите ли вы рефакторить или переписать свою систему.
Рефакторинг против перезаписи — Заключение
Для меня это галстук.
Здесь очень хорошо работает одно волшебное предложение: «Это зависит». Как видите, при выборе между переписыванием и рефакторингом в игру вступает множество факторов. Разумно принять их все во внимание при принятии окончательного решения.
Ни рефакторинг, ни переписывание не являются простым решением, когда вы ставите новую бизнес-цель с точки зрения разработки программного обеспечения.
Вы должны учитывать КАЖДЫЙ из вышеперечисленных факторов. И добавьте к этому любые другие факторы, которые влияют на ваш бизнес или отрасль при принятии решения, например:
- Обязательства перед инвесторами — если вы обязаны вернуть некоторые вложения, то это может сильно повлиять на то, как вы смотрите на код.
- Дизайн UI/UX — если они сильно меняются от версии к версии, вам может быть гораздо проще начать с нуля, чем проводить рефакторинг текущей кодовой базы.
- Изменения среды — если вы хотите перейти с одного хостингового решения на другое, вы можете обнаружить некоторые проблемы при полной замене, которые могут привести к необходимости рефакторинга или перезаписи.
В MasterBorn мы всегда стараемся найти лучшие решения для наших клиентов. При принятии решения о переписывании или рефакторинге их системы мы всегда даем им подробное объяснение того, почему один вариант лучше другого и что они получат, выбрав его.
40% рефакторинг — 60% переписывание
Как я уже упоминал, большинство наших решений создаются с нуля, и технический долг сейчас не является проблемой. Но если бы я собрал существующие кодовые базы клиентов, то тенденция была бы такой: 40% рефакторинга и 60% переписывания. Самые большие проблемы, которые возникают:
- Низкое качество кода (помните: важна документация, правильное структурирование и именование!)
- «Старый стиль» структурирования кода (как правило, монолитные приложения в полнофункциональной архитектуре MVC, которую трудно масштабировать или обойти, и обычно этому обучают в большинстве широко доступных учебных пособий)
- Чрезмерная разработка — вам не нужно использовать какие-то «новые и модные передовые технологии», внедрять микросервисы или любые распределенные системы для небольшого CRUD-проекта с командой из 2–3 человек, по крайней мере, большую часть времени. Это особенно касается создания MVP, поверьте мне :)
Если вы столкнулись с серьезной проблемой в своем приложении и не знаете, каким должен быть ваш следующий шаг, свяжитесь с нами по адресу [email protected]. Мы внимательно рассмотрим ваш проект, чтобы сообщить вам, независимо от того, полностью ли ваши разработчики потерпели неудачу или есть еще что-то, что можно спасти, рефакторинг вашего кода.
