Чотири сценарії модернізації Legacy-коду. Обираємо найкращий

Вітаю! Мене звати Назар Струк, я Back-end розробник з п’ятирічним досвідом. Зараз — Java Developer в компанії InventorSoft. Встиг попрацювати на проєктах з великою спадщиною коду. Звісно, кожен з них унікальний — від бізнес-логіки до стилю проєктування технічної частини.

Коли ми зустрічаємось з легасі, важливо розуміти основні підходи до модернізації, а також яким чином найефективніше додати свої зміни, щоб нічого не поламати. Інколи для цього потрібно мати план дій, який можна застосувати на практиці. Саме так народилась ця невеличка стаття.

Що таке легасі-код

Легасі-код (Legacy code) — не обов’язково погано написаний на основі застарілих технологій. Це може бути й нещодавно імплементований код. Зазвичай ми зустрічаємо легасі, коли розпочинаємо працювати зі «старим» проєктом, а саме з читабельністю, підтримкою та ускладненнями імплементації нових фіч.

Майкл Фезерс доволі влучно стверджує, що «Легасі-код — це код без тестів». Його дійсно важко змінити, адже розробники не хочуть ламати логіку. В найближчій перспективі вони будуть із дедалі меншим ентузіазмом робити рефакторинг великих частин коду логіки, а імплементація нових фіч не приноситиме такого задоволення від роботи, як це було на початку.

Легасі-код створює чимало проблем для всієї команди. Розробникам доводиться витрачати багато зусиль на пошук рішень, переписувати частини коду, запроваджувати додаткові перевірки. Через це бізнес втрачає динаміку розвитку проєкту, ресурси для обслуговування продукту і додавання нового функціоналу. Як результат команда за кавою обговорюватиме як все погано, а бізнес плакатиме над витратами.

Перш ніж розглядати проблематику модернізації легасі-коду, доцільно виокремити основні підходи, які зазвичай широко використовують у роботі з ним:

1. Повне переписування.
2. Продовження розробки без змін.
3. Нова система довкола легасі.
4. Поступовий модульний рефакторинг.

Розглянемо кожну з цих стратегій.

Стратегія 1. Повне переписування

Одним з можливих варіантів розвитку старшої системи є її переродження у проєкт із нуля. Таку стратегію обирають тоді, коли простіше переписати систему повністю, ніж робити поступовий рефакторинг коду. Прогнозуючи довгостроковий розвиток проєкту, клієнт володіє достатніми ресурсами, щоби почати розробку нової системи та паралельно підтримувати старшу.

Переваги

Після аналізу успадкованого коду стає зрозуміло, чого не варто робити.

Система, безумовно, міститиме багато вдалих рішень, які можна успадкувати. Це заощадить час під час створення проєкту з нуля. Інколи навіть цілісні модулі можна перенести у нову систему.

Підвищиться мотивація в команді. Адже база коду теж успадковується і є змога імплементувати усі найновіші рішення та називати проєкт «our baby».

Недоліки

Швидше за все, доведеться одночасно підтримувати старшу та нову системи, допоки усі користувачі не перейдуть на нову. Оскільки клієнти не зможуть не використовувати продакшн-версію та відмовитись від виправлення багів. Для клієнта це додаткові витрати.

Замовник сплачує за створення системи рішень вдруге.

Процес міграції даних та перехід на нову схему БД може бути досить об’ємним та болючим.

Клієнт ще тривалий час не побачить різниці між тим, що було і як стало. Адже перший реліз нової системи, яка перевершить старшу версію за кількістю можливостей, з’явиться не скоро.

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

Система може виявитися складнішою, ніж очікувалося. Є ймовірність повторної невдачі або й ще гіршого результату. Невідомі усі нюанси системи та підсистем, які накопичувалися роками.

Коли варто так діяти

  • Замовник дає час і кошти, щоб переписати старшу систему з нуля. Команда впевнена, що це завдання реально виконати.
  • Систему ще не почали використовувати. Можливо, це прототип або «доказ концепції».
  • Система дійсно не працює, і користувачі від неї відмовляються. Наприклад, це проєкт, яким попередня команда займалась рік. Він міг просто не відповідати заявленим характеристикам, не було сенсу додавати або переробляти код. Внаслідок аналізу помилок прийняли рішення реалізувати нову версію з нуля.

Стратегія 2. Продовження розробки без змін

Може бути ухвалене рішення не торкатися вже написаного за принципом: «Якщо код працює — не чіпай». Команда продовжує писати новий код у такому ж стилі, не витрачає час на рефакторинг застарілого, не змінює дизайн системи. Можливо, вона занадто велика й складна, терміни обмежені, бюджету на виправлення критичних помилок немає. Або технічному керівництву код видався доволі дієвим. Внаслідок цього команда приймає стандарти та підходи поточної реалізації рішень.

Переваги

Робота над системою не припиняється, клієнт бачить результати власних інвестувань.

Імплементація нового функціоналу та можливість виправлення помилок із початку роботи команди.

Недоліки

Якщо архітектура проєкту неправильна, або використовуються застарілі технології, витрати на розробку будуть рости, а показники ефективності — падати.

Для клієнта пріоритетом може бути виправити декілька критичних багів, а не витрачати час на удосконалення дизайну. Попри якість коду, команда додає ще більше «милиць» у нього, щоби хоч якось забезпечити роботу системи. Її стабільності та здорового масштабування у такому випадку важко очікувати. А розробники намагатимуться якомога швидше змінити місце праці.

Є ймовірність потрапити в ситуацію, описану Бруксом. «Усі виправлення мають тенденцію руйнувати структуру, збільшувати ентропію і дезорганізувати систему. Менше зусиль витрачається на виправлення помилок на початку проєкту та дедалі більше на усунення наслідків попередніх виправлень».

Реанімувати систему набагато складніше, ніж створити нову. Така робота вимагає високої кваліфікації.

Є ймовірність витратити час розробників, а потім відхилити всі зміни.

Коли варто так діяти

  • Бізнес не потребує нових функцій. Треба лише виправити деякі з наявних. Це трапляється, коли подальший розвиток системи не планують. Можливо, паралельно створюють нову — з новими ідеями на новій платформі.
  • Є потреба швидко надати результат, навіть свідомо додаючи «милиці» до сучасного коду. Це може погіршити ситуацію, проте, якщо замовник отримає великий прибуток від такого прориву, в майбутньому він зможе інвестувати його в інші стратегії роботи зі застарілою системою.
  • Код, який розробники успадкували, доволі прийнятний та покритий тестами; архітектура відповідає вимогам клієнта; логіка працює, забезпечуючи запит бізнесу.

Стратегія 3. Нова система довкола легасі

Уявімо, що у нас є старий автомобіль, що кожного дня нагадує про свій вік. Можна піти в салон і купити нове авто або ж модернізувати наявне новими частинами. Починати варто з чогось малого, до прикладу, з коліс. Далі перейти до важливіших модулів (акумулятора, ходової частини тощо).

Саме так працює Strangler Pattern, який часто використовують в актуальній стратегії. Лише замість автомобіля модернізуємо систему, а отже й базу коду. Такий підхід є лояльною версією повного переписування системи з нуля.

Створюємо новий застосунок навколо старого зразка. З часом нова програма розширюється і бере на себе більше системних функцій. Не зачіпаючи старшої системи, ми вписуємо нові функції в нову.

Поступово створюється нова функціональність та інкапсулюється довкола наявної застарілої системи. Згодом нові компоненти «придушують» старшу систему та вихідний код, перебираючи на себе дедалі більше їхніх функцій.

Strangler Facade патерн

Переваги

Усі переваги першого підходу з повним перезаписом.

Роботу старшої системи не припиняють і при цьому додають нові функціональні можливості.

Клієнт відразу бачить результати власних інвестицій.

Якщо застаріла система побудована на основі джерел подій, реалізація перехоплення подій відбудеться легко.

Недоліки

Якщо в системі є серйозні помилки, їх треба виправити у застарілому коді.

Є загроза незавершеного результату. Наприклад, припиниться фінансування або робота зі замовником. Тоді система перетвориться на ще більш проблемну.

Зі складною та заплутаною архітектурою застарілої системи таке може бути важко реалізувати.

Доречно зауважити, що це доволі складний підхід, який вимагає ґрунтовного попереднього аналізу та високого рівня кваліфікації розробників.

Коли варто так діяти

  • Застаріла система є стабільною.
  • Є потреба додати нові функції, а не розширювати наявні.

Стратегія 4. Поступовий модульний рефакторинг

Такий підхід застосовують найчастіше. У ньому найменше ризиків, а перехід на нову або оновлену систему відбувається прогнозовано та стабільно. Якщо неможливо почати створювати нову програму довкола старої та залишити код у поточному стані, можна зробити його поступовий рефакторинг та покращити дизайн системи.

Для цього реліз за релізом ізолюють частини системи в незалежні модулі та переписують їх.

Переваги

Поступове підвищення якості системи.

Можливість забезпечити стабільну швидкість доставки.

Користувачі продовжують працювати з уже знайомою системою, отримуючи періодичні оновлення.

Недоліки

Різкого покращення якості системи не відбудеться. Повільна швидкість розробки може бути проблемою для замовника.

Не завжди є можливість пріоритетно підібрати модулі для рефакторингу, особливо якщо вони тісно пов’язані між собою.

Коли варто так діяти

  • Застаріла система має високу споживчу цінність.
  • Система має багато налагоджених модулів.
  • Потрібно розширити наявні функції.

Детальніше про рефакторинг

Тепер, коли є розуміння суті основних підходів до роботи з легасі-кодом, пропоную детальніше розглянути останній. Зважаючи на емпіричний досвід, клієнти зазвичай обирають саме рефакторинг. Зокрема, коли мова йде про об’ємні проєкти з великою кількістю мікросервісів та складною спадщиною описаної бізнес-логіки.

Рефакторинг дає змогу вдало працювати із застарілим кодом. А саме допрацювати його, щоб зробити зрозумілішим та придатнішим для обслуговування. В процесі ми стараємось досягти найкращих показників шляхом оптимізації коду, спрощення та об’єднання змінних і класів, а також переписування методів.

Рефакторинг — це процес зміни програмної системи таким чином, щоб він не змінював зовнішню поведінку коду, але покращував його внутрішню структуру та якісні характеристики. Це дисциплінований спосіб очищення коду, який мінімізує ймовірність появи помилок. По суті, під час рефакторингу ви покращуєте дизайн коду після його написання.

Розпочинати рефакторинг варто лише тоді, коли стане зрозуміло, як працює або не працює код.

Декілька дієвих порад для роботи з легасі-кодом

Видаліть увесь закоментований код

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

Без логів нікуди

Неможливо зрозуміти логіку? Невідомо, де виникла помилка? Залогуйте це. Є вільний час? Додайте більше логів. У роботі з легасі-кодом дуже часто поведінка під час виконання (runtime) може бути не зрозумілою, тому підвищення видимості є вашою основною задачею. Не переживайте, якщо додасте забагато логів. Завжди можна зменшити рівень з INFO до DEBUG. Інколи чудовим рішенням може бути додати в логи ідентифікатор клієнта або якусь сутність. І в результаті цього мати можливість легко відстежити флоу користувача коли система пробуватиме зареєструвати нову задачу.

Інсталюйте та включіть додатки контролю якості коду типу SonarQube

«Ми знайшли 100500 помилок у вашому коді, ви дійсно хочете залити свої зміни на віддалений репозиторій?» — бережіть нерви, такі повідомлення ви будете отримувати часто. Проте в довгостроковій перспективі це дозволить мати здоровішу базу коду, а багато дрібних потенційних помилок не будуть допущені. Також такі речі дуже спрощують процес перевірки коду. Ви не будете відволікатись на помилки, що можуть бути допущені колегами, натомість зможете повністю зосередитися на перевірці логіки задачі.

Будьте як бойскаут

Роберт Мартін у своїй книзі написав про правило бойскаута, яким, на мою думку, повинні користуватись усі, хто має доступ до бази коду. Ідея у тому, щоб залишати місце кращим, ніж ти його знайшов. В нашому контексті — кожного разу, коли ти починаєш працювати над новою ділянкою коду, ти повинен залишити її світлішою та чистішою. Хто знає, можливо, ви сюди ще повернетесь :)

Безпечний рефакторинг — наш пріоритет

Безпечним я називаю рефакторинг, який ми можемо контролювати, оскільки часто пробуємо внести зміни в методи, які не покриті тестами. Тобто краще вносити зміни чи удосконалювати невеликі частини коду, ніж пробувати переписати одразу цілу частину бізнес-логіки й намагатись «подружити» її зі старою системою.

Думаю, більшість погодиться, що якісний рефакторинг коду можна здійснити лише коли твій код покритий unit-тестами. Тільки в такому випадку ми можемо стверджувати, що методи працюють належним чином, і непередбачуваних ситуацій не виникне. Звісно, для багатьох легасі-проєктів може бути рідкістю хороше тестове покриття (80% +).

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

То ж до безпечного рефакторингу можна скромно віднести такі основні кроки:

  • визначити критичні місця, що потребують змін;
  • досягти найменшої залежності (Low coupling);
  • розбити методи на частини (зменшити складність методу):
  • звернути увагу на назви змінних;
  • імплементувати логіку через інтерфейси (щоб легше було створювати Mock’и для тестів);
  • написати декілька JavaDocs (ви витратили 10 хвилин, намагаючись зрозуміти, що робить цей метод? Чудово, будь ласка, заощадьте трохи часу для наступного розробника, який його прочитає — напишіть рядок або два чіткого резюме того, що робить метод).

Написання тестів

Після безпечного рефакторингу можна пробувати переходити до написання тестів.

Якщо код не протестовано, як ви знатимете, що нічого не зламаєте, коли додаватимете свої зміни? Тестування має вирішальне значення в контексті рефакторингу коду, і хтось має це робити.

Можна почати з тестування логіки після безпечного рефакторингу, яка є критичною і часто використовується. В першу чергу є сенс покращити саме її через імплементацію тестів, а потім — безпосередньо змінами у коді. Крім того, залежності для тестів зазвичай найбезпечніше оновлювати.

Сучасні бібліотеки, як-то JUnit, Mockito, PowerMock, мають багато функцій і підходять для тестування застарілого коду. Часто небажання писати unit тести може бути індикатором того, що потрібно знову згадати про SOLID, і переконатись, що принципи правильно імплементовані та працюють на ділянці коду, яку потенційно хочемо протестувати. Це також може бути чудовим прикладом, як не потрібно писати код.

Редагування коду

На цьому етапі ми повинні мати поверхнево відредагований та покритий тестами код. Можливо не весь і не на 100% покритий, проте ми вже знаходитимемось у «чистішому» місці, в якому приємно працювати.

Впевнений, що кожен розробник вже має у своєму арсеналі або починає випробовувати власні техніки рефакторингу коду. Проте читаючи статті завжди стараюсь виокремити для себе те раціональне зерно, яке зможе допомогти мені у майбутньому. Серед усіх методів рефакторингу виділю ті, якими активно користуюсь:

  • Перейменуйте змінні. Що, знову? Якщо це потрібно, так. Зазвичай ми починаємо рефакторинг з ділянок коду, до якого найчастіше звертаємось. Тому часто буває, що комплексний погляд на частину бізнес-логіки може наштовхнути на більш влучне ім’я для змінної, методу чи класу.
  • Використайте константи. Весь явно описаний «захардкоджений» код робить його менш придатним для обслуговування та збільшує кількість невідповідностей і помилок через людський фактор. Замість того, щоб використовувати жорстко записані значення (hard code), відредагуйте код так, щоб вдатись до констант з описовими назвами.
  • Не повторюйте код. Дуплікація в розробці не тільки знижує загальну якість коду, але вносить негативний вплив у якість та зручність обслуговування. Також, такі частини коду збільшуватимуть невідповідності та приводитимуть до помилок у майбутньому. Краще «придушувати» такий код в зародку, а ніж давати цьому феномену можливість штучно збільшувати вашу базу коду.
  • Зробіть методи простішими. В легасі часто можна зустріти складні, об’ємні та заплутані методи. Цей підхід допоможе зробити їх легкими для розширення, розуміння та обслуговування та ідентифікувати надто складні методи, що містять вкладену логіку або ж такі, що мають занадто багато обов’язків.
  • Згадуйте про SOLID не тільки на співбесідах. Застосовуйте базові принципи на рівні класів твого легасі-коду. Усі вони допоможуть зберегти (або ж зробити) твій код придатним для обслуговування, читабельним, гнучким і модульним.
  • Переміщуйте функціональність об’єктів там, де це необхідно. Мета переміщення функціональності між об’єктами — робота з розподілом функціональної логіки між класами. Коли клас став великим та перевантаженим, саме час передати імплементацію новому класу. Крім того, якщо клас виконує незначну частину логіки та обмежений у відповідальності, його методи можна перемістити в інший клас, а його самого — видалити.
  • Pull-Up/Push-Down. З допомогою методів Pull-Up та Push-Down можна переміщувати методи між підкласами та суперкласами під час роботи з ієрархією успадкування. Pull-Up переміщує метод з підкласу в суперклас, забезпечуючи його доступність для всіх підкласів. Push-Down має зворотну дію. Переміщує метод із суперкласу в підклас, якщо ця техніка стосується лише цього підкласу.
  • Lazy Loading. Об’єкти повинні завантажуватись тоді, коли це потрібно. До прикладу, Hibernate за замовчуванням вигружає з бази усі зв’язки One-to-One і вмикає ‘Lazy’ для всіх колекцій. Тобто за замовчуванням всі одинарні зв’язки будуть вигружатись разом з тією сутністю, яку буде потрібно. А для усіх to-Many зв’язків Hibernate буде за замовчуванням вмикати ‘Lazy’. Тому в ході роботи над покращенням коду переконайтесь, чи правильно вказаний fetch type для зв’язків, які використовуються в коді. Це може суттєво покращити продуктивність.

Підсумки

Зараз можна знайти багато вдалих публікацій, у яких автори висвітлюють проблеми легасі-коду та методи боротьби з цим явищем у нашій сфері. Проте легасі — це код, який ви писали ще вчора. Працюючи на проєкті з великою спадщиною коду, важливо розуміти, яку стратегію роботи з легасі обрали у вас та як відбувається рефакторинг з практичної точки зору під час роботи.

Дотримання найкращих практик може полегшити процес і призвести до кращої якості коду. Розуміння застарілого коду та визначення можливостей рефакторингу є важливими першими кроками.

У цьому рукописі я поділився порадами, набутими під час роботи на проєктах із великою кількістю застарілого коду. Користуюся ними й сьогодні. Звісно, вони не здатні посприяти розв’язанню усіх проблем, проте можуть стати хорошою точкою відліку для фахівців, які вперше зустрілися з легасі.

Важливо усвідомити, що дисципліноване оновлення коду та зменшення технічної заборгованості не лише створює сприятливі умови для роботи та береже нерви, але і є важливою задачею для бізнесу. Балансуючи між такими запитами, однозначно можна збільшити свою якісну експертизу.

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Легасі-код — це код без тестів

Я б сказав що це досить категорично. Насправді я бачив не так багато ентерпрайз проєктів де було б хоча б 50% покриття коду тестами.
Я в сказав інакше: «Легасі-код — це код який ніхто не розуміє.» Бо будь-який код пишуть аби реалізувати якийсь функціонал, який можна описати людською мовою. Якщо оригінальні вимоги на людській мові втрачені, якщо нема автора чи когось хто пам’ятає для чого цей код, і якщо з самого коду дуже важко сказати людською мовою що саме він робить — тільки тоді це легасі.
І для легасі-коду може бути навіть багато тестів — але код цих тестів так само не дає розуміння які саме вимоги вони перевіряють. Погано написані тести іноді навіть більш складні, ніж код який вони тестують — що робить їх не тільки не корисними — але й зайвим тягарем.
Головна проблема легасі — коду що неможливо виправити те, що невідомо як має працювати!
Наприклад вирішуючи математичне рівняння ви у більшості випадків розумієте скільки «коренів» вам треба відшукати. Але уявімо що цього не можна дізнатися. Тоді така задача перетворюється вже на велику математичну проблему, як пошук усіх простих чисел.
Отже для легасі стратегія «працює — не чіпай» завжди матиме сенс. Але вона виключає розвиток — отже для бізнесу це означатиме майбутню смерть.
Розуміючи це, багато хто обирає стратегії «рефакторингу», чи поступового переписування, чи «огортування» старих модулів у нові. Бажання «сидіти на двох стільцях» зрозуміло — але воно дає не кращі результати. Чому?
По-перше головна проблема: що ніхто вже не знає як має працювати система — не усунута. Зазвичай кажуть: «робить нове, але щоб працювало як старе і нічого не зламалося». Це означає що замість нової системи просто буде створено новий легасі код! Витратив грошей як на нову систему — у результаті отримаємо систему не краще, ніж була. Можливо там буде купа нових мікросервісів замість старого моноліту — але розібратися у них буде аж ніяк не простіше. І не факт що підвищиться первоманс чи зменшаться витрати на підтримку.
Тому особисто я завжди раджу іти шляхом побудови нової системи. І головний аргумент тут: будуючи нову систему «з нуля» ви маєте можливість використовувати сучасні технології. Які за багато років існування старої системи вже прокинулися далеко уперед!
Можливо навіть що замість мільйонів строк кода старої системи колись написаної «з нуля», подібну систему можна буде зараз на 80% зібрати з готових low-code рішень, додавши 20% кастомного коду де потрібно. Замість ходити по старих граблях ви зможете використати сучасні, працюючі і перевірені рішення та технології. І це ще й відкриє для вашої нової системи величезні можливості взаємодії та інтеграції з іншими сучасними системами (підтримка стандартів, протоколів, сучасний вигляд і т.і.). Які ваша кастомна легасі система написана 10+ ніколи не матиме.
У чому недоліки? Оскільки ніхто не знає на 100% функціонал старої системи — то відповідно ця невідома частина буде втрачена. Але важливість цієї втрати дуже часто переоцінюють.
По-перше: нова система дозволить залучити нових користувачів, які не бачили старої і для яких сучасна система буде відразу краща.
По-друге: більшість старих користувачів не знала і не використовувала 100% можливостей старої системи. Скоріше за все після необхідних зусиль по переходу — вони зможуть працювати як раніше. А згодом зможуть оцінити і нові можливості які є тільки у новій системі.
По-третє: Стара система залишиться працювати поряд і з новою. Це дасть можливість старим клієнтам подивитись, виказати усі претензії до нової системи і надати команді розробки інформацію який саме функціонал потрібен у новій системі і (що важливо) як саме він має працювати! Реалізувати нові зрозумілі вимоги — набагато легше ніж намагатись не зламати щось незрозуміле.
По-четверте: Не треба переоцінювати старих клієнтів! Цілком можливо що буде великий старий клієнт який принципово не захоче переходити на нову систему. Але існує дуже велика імовірність що через рік у нього зміниться власник, чи прийде новий менеджер, чи просто конкурент зробить їм кращу пропозицію. І ось вже клієнт який роками не хотів нічого міняти — підписує перехід на якийсь чужий модний ERP. А ви залишаєтеся з купою старого функціоналу, який був потрібен тільки тому клієнту.

Звичайно, шлях побудови нової системи — це найкращий шлях з точки зору перспективи як для розробників так і для самого клієнта. Проте мабуть далеко не кожен клієнт буде готовий витратити такі ресурси. Гадаю кожен кейс потрібно розглядати окремо, стосовно задач, об’єму потенційної роботи, очікувань та планів клієнта. В основному, старався стисло подати підходи які зараз часто використовуються на різних по обсягу проєктах, щоб розробник з невеликим досвідом міг собі поставити якісь орієнтири в голові куди і як рухатись, якщо перед очима багато легасі :)
Коментар дійсно хороший, і несе раціональне зерно. Дякую!

будуючи нову систему «з нуля» ви маєте можливість використовувати сучасні технології.

Я бачив багато випадків, коли застаріли технології змушували починати роботи по заміщенню системи, але кожного разу на це були досить конкретні причини ( у найбільш екстремальному випадку — стара система розроблялась під/працювала виключно на специфічному сімействі екзотичних серверів, які не випускалися вже з десять років та почали масовано виходити з ладу ), але це ніколи не було суто тому що

будуючи нову систему «з нуля» ви маєте можливість використовувати сучасні технології.

, тобто технології заради технологій.

По-третє: Стара система залишиться працювати поряд і з новою.

Welcome to hell або постійних двосторонніх синхронизацій даних між двома одночасно працюючими системами (підказка — спроби зробити системи цілком незалежними на рівні даних бувають успішними дуже рідко, якщо системи досить складні), або одночасної подівйної роботи у двох системах. Як бонус, увесь цей час стара система все одно повинна супроводжуватися та дороблятися у паралелі до нової, та додатково це ще й тягне за собою зміни у інтегрованих (репортінгових\фінансових\складських etc) системах, які будуть повинні вміти працювати з двома наборами даних

який саме функціонал потрібен у новій системі і (що важливо) як саме він має працювати!

У 90% відсотків це буде «зробить так само як було, тому що ми усі звикли до поточної системи», може з косметичнимі змінами у декількох найбільш дратуючих місцях.

три кити нормальної великої розробки:
— кодестайлінг з синтетичною перевіркою на кожен хук (комміт не проходить якщо не «співпало»)
— автоматичні тести на кожен пуш (навіть якщо до цього їх не було, головне почати і все нове тільки з тестами)
— затверджені правила неймінгу та форматування коду на рівні блоків та файлів

ще багато залежить від мови (десь проще, десь складніше) але в цілому це база.
навіть якщо стартап злетів і велике легасі стало основою продукту що буде зростати — один раз «хардово» зробити єдиний стиль і далі вже працювати по пунктах вище (наступний крок це розкидати і переіменувати все згідно третього пункту)
зрозуміло що переписування краще за все, але в 90% випадків воно недоречно

рефакторінг, оптимізація і все таке інше це вже наступні кроки. Логи взагалі тільки після приведення до «бази». Якщо база с самого початку погана, то 100500 кроків не виправлять ситуацію і далі будуть вспливати банальні проблеми.
Не одноразово бачив такі проекти — і логів на гігабайти за день, і начебто тести е, і просто перевірки коду, а все одно постійно щось випливає (і паплайн на 40хв після кожного пуша)

Підписатись на коментарі