Рефакторинг мобільного застосунку: де накопичується борг
Технічний борг мобільного застосунку рідко виглядає як один зламаний модуль.
Зазвичай він накопичується тихо: мережевий шар обріс винятками під конкретні екрани, бізнес-правила розповзлися між екраном, кешем і аналітикою, а розросла кодова база перестала вміщатися в голову навіть старшому інженеру. Правку вносить одна людина, а наслідки розбирає вся команда.
Зв'язаність модулів зростає разом із кількістю сценаріїв. Щоб показати нову картку в каталозі, зміну доводиться вносити в модель даних, у шар завантаження, у розмітку списку й у локальне сховище — чотири місця, з яких три до задачі не мають відношення. Чим щільніша склейка, тим менше можна передбачити, що саме зламається на сусідньому екрані.
Далі вмикається регрес після правки. Зміна формату відповіді тягне за собою перевірку оформлення замовлення, авторизації та повідомлень, бо всі вони читають ті самі дані.
Ручний прогін займає дні, автотести покривають не всі гілки, і випуск версії зсувається на невизначений строк.
Для продукту це обертається тим, що дрібні доопрацювання перестають бути дрібними. Команда планує не те, що потрібно бізнесу, а те, що безпечно змінювати; замість розвитку з'являються пачки виправлень і позапланові випуски. Розробники починають боятися чіпати старі ділянки — і борг зростає ще швидше.
Водночас накопичене можна виміряти: за кількістю зв'язків між модулями, часом збирання, часткою шляхів без тестів і кількістю дефектів на випуск. Ці цифри показують, де саме різати. Далі розбираємо, як це закривається.
Ефект рефакторингу: швидкість випусків і менше відмов
Рефакторинг виправданий, коли його наслідки видно в метриках циклу релізів, а не в акуратності коду.
Поки екрани, мережевий шар і сховище пов'язані напряму, правка в одному місці тягне ланцюжок змін: збирання триває довше, перевірка — вручну, частину часу з'їдають регреси, що спливли вже після публікації.
Розділення на незалежні модулі змінює картину. Ділянки збираються й тестуються паралельно, типову зміну локалізовано всередині одного модуля, автотести на критичні сценарії проганяються на кожну зміну коду.
Прискорення випуску версій тут не гасло: частка часу, яку команда витрачає на підготовку релізу, скорочується в рази, а сам випуск стає плановою операцією, а не авралом.
Зниження кількості відмов рахуємо за фактами: частка сесій без збою в Crashlytics, кількість повернень після публікації, частота відкатів на попередню збірку.
Явні межі модулів прибирають цілий клас падінь — ті, що народжувалися на стиках шарів і проявлялися лише під навантаженням. Окремо проганяємо пікові сценарії: стійкість до навантаження зростає, бо важкі операції йдуть з головного потоку, а повторні мережеві запити не дублюються.
Четвертий ефект — трудомісткість підтримки застосунку й передбачуваність оцінки.
Коли модулі відповідають кожен за своє, нова задача рахується за обсягом робіт у межах однієї ділянки, а не «як пощастить»: розкид оцінок звужується з тижнів до днів, і цикл релізів планується за календарем, а не за фактом.
Способи переробки: повна, поступова, точкова
Режим переробки вибирають за двома питаннями: наскільки глибоко проблема сидить в архітектурі й чи можна заморозити релізи на час робіт.
Жоден із варіантів не вимагає зупинки чинного продукту — різниця в тому, скільки перехідного коду команда тягне паралельно і як довго живуть два шари одночасно.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Точкова оптимізація вузьких місць | Просідає один-два сценарії: холодний старт, прокрутка довгого списку, фонова синхронізація. Решта ядра влаштовує | Лікує симптом. Борг у шарах доступу до даних і навігації залишається, і через кілька ітерацій правки повертаються в ті самі модулі |
| Поступова переробка | Продукт активно розвивається, релізи йдуть кожні два тижні, зупинка неможлива | Старий і новий шари живуть паралельно: зростає обсяг перехідного коду, на кожному кроці потрібні перевірки сумісності |
| Винесення модулів в окрему бібліотеку | Спільна логіка повторюється у двох або більше застосунках чи командах | Потребує контракту версій і власного циклу релізів, інакше збірки розходяться і користувачі отримують різну поведінку |
| Повне переписування ядра | Архітектура не дає розвивати продукт, платформенні інтерфейси застаріли, правки обходяться дорожче за нову реалізацію | Паралельна підтримка старої гілки, поки нова не досягне паритету за функціями, і повний цикл тестування заново |
Зазвичай починають із точкової оптимізації: вона швидко показує, де справжнє вузьке місце.
Якщо правки після неї повертаються в ті самі модулі, переходять до поступової переробки та винесення спільних частин в окрему бібліотеку, а повне переписування ядра залишають на випадок, коли архітектура перестала тримати навантаження розвитку.
Як проходить робота: етапи від аудиту до передачі
Рефакторинг ламає продукт, коли йде однією великою перепискою: поки гілка живе тижнями, релізи стають, а регрес спливає вже в користувачів. Ми йдемо короткими кроками, після кожного застосунок залишається збираним і робочим. Порядок нижче типовий — під конкретний проєкт змінюються обсяг і глибина.
- Аудит кодової бази. Розбираємо історію правок і карту залежностей, знаходимо дублювання та модулі, які змінюються найчастіше. На виході — список вузьких місць з оцінкою ризику й черговістю робіт.
- Схема цільової структури. Розкладаємо застосунок на шари й модулі, фіксуємо контракти між ними. Що переносимо як є, а що переписуємо — узгоджуємо з вашою командою до першого рядка нового коду.
- Пілотний модуль. Переносимо одну ділянку цілком, щоб перевірити схему на живому коді та оцінити трудомісткість решти. Далі масштабуємо підтверджений підхід, а не припущення.
- Перенесення частинами. Йдемо дрібними порціями: кожна правка закрита тестом і йде в основну гілку, не чекаючи завершення робіт. Релізи продовжують виходити за звичайним графіком.
- Автоматичне збирання й перевірки. Налаштовуємо збирання на кожну зміну, статичний аналіз і прогін тестів. Регрес ловиться до перевірки коду, а не в день розгортання.
- Приймальні перевірки. Звіряємо поведінку з вихідною версією за ключовими сценаріями — вхід, оплата, офлайн-режим. Час старту й частка падінь не повинні погіршитися на жодному кроці.
- Передача й навчання команди. Віддаємо документацію зі структури, правила внесення змін і розбір з інженерами замовника. Застосунок залишається підтримуваним без нас.
Артефакти проєкту: схеми, регламенти, документація
Рефакторинг завершено не тоді, коли збирання стало зеленим, а коли в репозиторії залишилися артефакти, за якими команда працює без нас. Кожен лежить поряд із вихідними кодами й оновлюється в тій самій зміні, тому не розходиться з кодом через місяць.
- Карта модулів і залежностей — які модулі є, хто від кого залежить, де розірвано циклічні зв'язки й який шар за що відповідає.
- Документація з архітектури — схема шарів і меж доменів, точки розширення, журнал рішень з обґрунтуванням і відкинутими альтернативами.
- Регламент роботи з кодом — модель розгалуження, порядок взаємної перевірки змін, обмеження на їхній розмір, обов'язкові перевірки перед злиттям.
- Опис перевірок — які автотести закривають які шляхи, де проходить межа покриття і що залишається на ручну перевірку.
- Інструкція з випуску версії — порядок збирання, підготовка підпису, розгортання на канал і відкат на попередній випуск.
- Карта володіння — за яким модулем закріплено відповідального і до кого йти із питанням.
- Журнал технічного боргу — що свідомо відкладено, за якими ознаками повернемося і що буде, якщо не повернутися.
Перевіряємо комплект просто: реліз за інструкцією збирає інженер, який не брав участі в рефакторингу. Впорався без підказок — артефакти повні; застряг — дописуємо до передачі.
Кейс: скоротили строк випуску версії втричі
Що було
Застосунок розвивався кілька років без спільної архітектури: логіка екранів, робота з мережею й зберігання стану були перемішані, а той самий розрахунок дублювався в чотирьох місцях.
Кодова база на Flutter збиралася однією командою, але кожна зміна тягла за собою ланцюжок пов'язаних правок.
Випуск версії займав шість тижнів, із яких три йшли на стабілізацію після регресів. Близько 40% задач поверталися на доопрацювання, 60% змін вимагали правок у суміжних модулях, а новий інженер виходив на самостійні задачі лише через місяць.
Що змінили і що стало
Розділили застосунок на шари з явними межами: представлення, бізнес-логіка, доступ до даних. Спільні розрахунки звели в один модуль, мережевий шар закрили єдиним клієнтом з обробкою помилок, критичні шляхи — оплату, авторизацію, синхронізацію — покрили автоматичними перевірками.
Випуск перевели на конвеєр, де збирання, перевірки й підпис ідуть однією командою без ручних кроків.
Строк випуску версії скоротився втричі — з шести тижнів до двох. Частка задач, що повертаються на доопрацювання, упала з 40% до 8%, частка змін із правками в суміжних модулях — з 60% до 15%.
Введення нового інженера в проєкт займає близько п'яти робочих днів замість трьох-чотирьох тижнів: структура передбачувана, а перевірки показують помилку до ручної перевірки коду.
Чим переписування з нуля відрізняється від поступової переробки?
Переписування з нуля — це другий проєкт поряд із першим: логіка переноситься в чисту архітектуру, а старий код заморожують. Поступове витіснення модулів іде інакше — новий шар з'являється всередині працюючого застосунку й забирає ділянку за ділянкою.
Дороге в повній заміні не обсяг роботи, а пауза в постачанні. Поки триває перенесення, ні нові можливості, ні виправлення не виходять, вимоги йдуть уперед, і запуск зсувається на величину цього відставання.
Ризик повної заміни в тому, що збій тут один і загальний: платформа не виходить частково — вона не виходить зовсім.
Повна заміна виправдана, коли проблема у фундаменті: зв'язки розмазані по екранах, новий модуль нікуди підключити, тести не пишуться, а правка тягне за собою половину застосунку. Тоді витіснення обходиться дорожче — кожен шар обростає застереженнями, і обв'язка з'їдає виграш.
Поступова переробка майже завжди швидше дає результат. Перший замінений модуль іде до користувачів через один-два цикли й перевіряється на живій поведінці; далі частка нового коду зростає, а відкат кроку обмежений однією ділянкою.
Продуктові релізи при цьому не зупиняються, і строки переробки рахуються за етапами, а не однією датою.
Вибір робимо за заміром: скільки коду справді потрібно замінити і скільки зовнішніх залежностей тримається на цій ділянці. Якщо змінюється менше третини і зв'язки розв'язуються — йдемо через поступове витіснення модулів.
Якщо ядро не дає зачепитися — плануємо повну заміну й заздалегідь вирішуємо, як живе поточна гілка до перемикання.
Часті технічні сумніви перед стартом робіт
Рефакторинг мобільного застосунку майже завжди йде на живому продукті: повністю зупиняти випуск версій не можна, інакше користувачі не отримують правки, а позиції в магазинах просідають.
Тому переробку розбито на короткі зміни — кожна проходить збирання й іде в найближчий реліз окремо, а основна гілка будь-якої миті залишається готовою до викладки.
Частина коду при цьому справді залишається переписаною частково, і це робочий стан, а не незавершеність: межі модулів зафіксовано, старий шар викликається через стабільні інтерфейси й знімається в міру готовності заміни.
Чи доведеться призупинити випуск версій на час робіт?
Ні. Робота йде паралельно циклу релізів: зміни вливаються по одній, кожна проходить перевірки до злиття. Якщо правка не проходить, вона залишається в окремій гілці й не затримує інші задачі.
Як ви переконуєтеся, що нічого не зламалося?
Перевірка регресу будується на автотестах за критичними шляхами — запуск, авторизація, оплата, переходи між екранами — і проганяється на кожній зміні в Appium.
Додатково звіряємо звіти про збої нової збірки з попереднім випуском: помітне зростання помилок блокує злиття до розбору причин.
Наскільки точно ви оцінюєте строки робіт?
Оцінка йде за модулями, а не за кодом загалом: спочатку інвентаризація залежностей і покриття перевірками, потім порядок робіт і точки, де можна зупинитися без втрати працездатності.
Так строки перераховуються за фактом закриття кожного модуля, а ви бачите обсяг на кожному етапі, а не одну загальну цифру.
Обговоримо задачу і повернемося з планом робіт
Оцінка рефакторингу без доступу до коду перетворюється на діапазон «від і до», який на першому ж тижні розходиться з реальністю. Щоб назвати строки за етапами й порядок робіт, нам потрібні вхідні дані: як улаштований репозиторій, як виходять релізи і де саме болить зараз. Надсилайте у зручному вигляді — текстом, посиланням або голосом, розберемо.
- Доступ до репозиторію: достатньо прав на читання — важливі структура модулів, історія змін і гілка, з якої збирається реліз.
- Схема випуску версій: як часто виходять збірки, хто їх збирає, які канали тестування задіяні і де залишився ручний крок.
- Опис вузьких місць: довге збирання, падіння під час роботи застосунку, дублювання логіки між екранами, місця, які правлять з обережністю.
- Карта модулів і екранів із позначкою, які в активному доопрацюванні, а які заморожені.
- Що не можна ламати: контракти із серверною частиною, схему зберігання даних на пристрої, дизайн-систему, поведінку авторизації.
- Стан автотестів: частка покритих шляхів, що падає в наборі і що перевіряється лише руками.
- Пріоритети продукту на найближчий цикл — задачі, через які рефакторинг не можна зупиняти надовго.
З цим набором ми повертаємося з планом: послідовність етапів, що входить у кожен, що свідомо залишаємо за рамками, строки й точки узгодження обсягу. Опишіть задачу — повернемося з оцінкою та планом, далі фіксуємо порядок робіт і стартуємо.
