Коли BIG перепишіть відповідь?

Просто прочитав питання про «Великих переписувачів», і я згадав питання, на яке я хотів відповісти сам.

У мене передається жахливий проект, написаний на старій Java, використовуючи Struts 1.0, таблиці з непослідовними зв’язками або взагалі відсутні взаємини і навіть таблиці без первинних ключів або полів, які були первинними ключами, але зовсім не унікальні. Якось більшість додатків "просто працює". Більшість сторінок повторно використовуються (скопіюйте вставлений код) та жорстко закодовані. Усі, хто коли-небудь працював над проектом, прокляли його в тій чи іншій формі.

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

TL; DR Коли велика перепишіть відповідь і які аргументи ви можете використати для її підтримки?

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

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

• Час нарощування для розробників дуже великий. Якщо для розробки нового розробника потрібно більше часу, ніж нижче (за рівнем досвіду), тоді систему потрібно переробити. Під часом нарощування я маю на увазі кількість часу до того, як новий розробник буде готовий здійснити свою першу фіксацію (про невелику функцію)
  • Свіжий поза коледжем - 1,5 місяця
  • Ще зелений, але працював над іншими проектами раніше - 1 місяць
  • Середній рівень - 2 тижні
  • Досвідчений - 1 тиждень
  • Старший рівень - 1 день
• Розгортання не може бути автоматизовано через складність існуючої архітектури
• Навіть прості виправлення помилок займають занадто багато часу через складність існуючого коду
• Нові функції займають занадто багато часу і коштують занадто дорого через взаємозалежність бази коду (нові функції не можна виділити, а отже, впливати на існуючі функції)
• Офіційний цикл тестування займає занадто багато часу через взаємозалежність існуючої бази коду.
• Занадто багато випадків використання виконується на занадто мало екранах. Це спричиняє проблеми з навчанням користувачів та розробників.
• Технологія, яку потребує нинішня система, вимагає цього
  • Якісних розробників з досвідом роботи в технологіях занадто важко знайти
  • Він застарілий (його не можна оновити, щоб підтримувати новіші платформи / функції)
  • Просто є набагато більш виразна технологія вищого рівня
  • Витрати на підтримку інфраструктури старих технологій занадто високі

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

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

• Технічні
  • З'єднання компонентів настільки велике, що зміни одного компонента неможливо виділити з інших компонентів. Повторне проектування одного компонента призводить до каскаду змін не тільки сусідніх компонентів, але опосередковано для всіх компонентів.
  • Технологічний стек настільки складний, що майбутній стан проекту потребує декількох змін інфраструктури. Це також знадобиться в повному перезаписі, але якщо це потрібно в покроковому переробленні, ви втрачаєте цю перевагу.
  • Повторне проектування компонента все одно призводить до переписування цього компонента, оскільки існуюча конструкція настільки фубар, що нічого не варто економити. Знову ж таки, ви втрачаєте перевагу, якщо це так.
• Політичні
  • Спонсори не можуть зрозуміти, що поступовий перегляд проекту потребує довгострокової відданості проекту. Неминуче більшість організацій втрачають апетит до тривалого витрачання бюджету, яке створює додаткове перероблення. Ця втрата апетиту неминуча і для переписування, але спонсори будуть більш схильні продовжувати, тому що вони не хочуть розбиватися між частково повною новою системою та частково застарілою старою системою.
  • Користувачі системи занадто прив’язані до своїх "поточних екранів". У такому випадку у вас не буде ліцензії на вдосконалення життєво важливої ​​частини системи (переднього плану). Редизайн дозволяє вам обійти цю проблему, оскільки вони починають щось нове. Вони все ще наполягають на тому, щоб отримати "ті самі екрани", але у вас є трохи більше боєприпасів, щоб відштовхуватися.

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

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

Деякі стратегії успіху:

• Якщо ви все-таки зробите це, не намагайтеся перетворити наявний код. Проектуйте систему з нуля. Інакше ти витрачаєш свій час. Я ніколи не бачив і не чув про проект "конверсії", який не закінчився бідно.
• Переміщення користувачів на нову систему по одній команді. Визначте команди, які мають найпоширеніші болі з існуючою системою, та перенесіть їх першими. Нехай вони поширюють добрі новини усним словом. Таким чином ваша нова система буде продаватися зсередини.
• Створюйте рамки так, як вам потрібно. Не починайте з будівництва, який я витратив на 6 місяців - це рамка, яка ніколи не бачила реального коду.
• Зберігайте технологічний стек якомога менше. Не надмірно розробляйте дизайн. Ви можете додати технології за потребою, але вийняти їх важко. Окрім того, чим більше у вас шарів, тим більше працювати розробникам. Не ускладнюйте рух.
• Залучайте користувачів безпосередньо до процесу проектування, але не дозволяйте їм диктувати, як це зробити. Завоюйте їх довіру, показуючи їм, що ви можете дати їм те, що вони хочуть краще, якщо ви будете дотримуватися принципів хорошого дизайну.

Я брав участь у двох великих переписах. Спочатку був невеликий проект. Другий був основним продуктом програмної компанії.

Є кілька підводних каменів:

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

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

Переписування може бути відповіддю, якщо:

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

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

Час для переписування, коли:

Вартість переписування програми + підтримка переписаної програми менша, ніж витрати на підтримку поточної системи протягом часу.

Деякі фактори, які роблять підтримку поточного одним дорожчим:

• Мова настільки стара, що ви повинні платити людям, які знають, багато грошей на програмування в ній (COBOL).
• (з досвіду, на жаль) Система має настільки стару архітектуру обладнання, що їм доведеться шукати деталі Ebay і COLLECT, щоб додати їх до машини, на якій вона працює, тому що вони більше не виготовлені. Це називається «підтримка життєзабезпечення обладнання» і коштує дорого, оскільки, оскільки деталі стають дефіцитнішими, вони (можуть) подорожчати, або вони (абсолютно) згодом закінчаться.
• Це стало настільки складним, що //Here be dragons.коментар у всьому вашому коді.
• Ви не можете писати жодних інших проектів і додавати компанії нову цінність, оскільки ви завжди латаєте цього потворного звіра.

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

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

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

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

Хоча я згоден з відповіддю Крамії та думкою Джоеля, бувають випадки, коли доречно зробити перезапис. У довготривалих програмах (я кажу, як 10-20 і більше років) технічне обслуговування з часом стає все дорожчим. Це пояснюється тим, що код стає все більш спагетті, оскільки оригінальна архітектура жертвується для швидкого обслуговування виправлень. Також розробники старих технологій стають більш рідкісними та дорожчими. Нарешті, апаратне забезпечення починає старіти, і все важче та складніше знайти нове обладнання, операційні системи, рамки тощо для запуску старого додатка. Крім того, бізнес розвивається, і, швидше за все, старша система не буде задовольняти бізнес-потреби організації, як це могла б абсолютно нова система.

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

стій! Переписування майже ніколи не є відповіддю. Найчастіше рефакторинг - це краща ставка.

Звичайно, бувають випадки, коли переписування виправдано:

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

Щоб зрозуміти, чому я рекомендую рефакторинг над переписуванням, подумайте, що стосується переписування. Ти повинен:

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

2. Відтворіть цю функціональність (або оновлену її версію) у новій тестованій та надійній програмі. Існуючий код розробники можуть не зрозуміти, але його користувачі, як правило, добре розуміють. Він може не відповідати їх поточним бізнес-потребам, але вони можуть принаймні розповісти, що робить програма за різних обставин.

Великими перевагами рефакторингу є:

• Ви можете взяти речі за один невеликий шматок за раз.
• Будь-які зміни можна перевірити в контексті існуючої, робочої програми.
• Гіпотези про те, як працює існуючий код, можна перевірити, вносячи невеликі зміни та спостерігаючи за тим, що відбувається.
• Зміни часто можуть бути надані користувачам поетапно, а не всі відразу.
• Навчання на ранніх стадіях рефакторингу може повідомити про пізніші етапи рефакторингу.
• Якщо ви відмовитеся від процесу часткового процесу, все одно будуть переваги в частині більш чистої бази коду (на відміну від переписування, яке необхідно виконати, щоб запропонувати користувачеві або розробникам будь-які переваги).

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

Ця графіка може допомогти, це функція якості базової коду та ділової цінності програми:

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

Я думаю, що я переживаю єдину ситуацію в моїй кар'єрі, де відповідь переписується:

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

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

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

Я працював у невеликій програмі, що мала пару програм DOS, які були оновлені для роботи з Y2K, переписані як 16-бітне додаток для Windows, а потім повністю переписані як 32-бітне додаток з однією додатковою функцією "маленького" (в кінцевому рахунку використовується лише один замовник), що вплинуло на всю структуру.

Переміщення 16-бітного коду до 32 могло б зробити за місяць одна людина, але NOOOOOOOOO, нам довелося переписати його, щоб зробити Soooooooooo набагато краще. Ця річ могла бути адаптована для інших галузей промисловості, матиме повну специфікацію та psuedo-код, перш ніж вони навіть розпочнуть роботу. Технічні характеристики були створені, але це пройшло так довго, що навіть не було часу, щоб написати справжній код. Він був випущений пізно, з більшою кількістю помилок, ніж 16-ти бітний "почався" з (це було на v.3.0 і, нарешті, до того, коли ми майже зробили це тиждень, не повідомляючи про нову помилку).

Ви можете подумати, що повторне написання однієї програми 3-4 рази призведе до деяких покращень, але я просто не думаю, що інтерфейс GUI може бути виправданим настільки.

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

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

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

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

Отож, я сиджу за своїм столом, я почав переписувати код для цього абсолютного безладу одного великого файлу aspx, бази даних за ним і замінюючи інтерфейс MS Access на MsSQL.

Ця програма asp засмічена такими речами

• include(close.aspx) який всередині має один рядок коду, який закриває останнє відкрите підключення до бази даних.
• Спадковий код просто прокоментували випадковим чином
• Не враховуйте безпеку
• Код спагетті, тисячі рядків. Все в одному файлі.
• Функції та змінні, які не мають чіткого значення за своїми назвами

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

Мене взяли на роботу для копіювання функціональності та виготовлення продукту, який може бути налаштований та доступний для інших в галузі. Проблема в тому, що ця річ була написана протягом останніх 10 років, щоб заповнити кожну потребу в бізнесі (ну, все одно я б сказав про п'ять-шість сигм).

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

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

З назви, яку ви можете сказати, свого роду це однобічно (він розповідає про те, чому ви ніколи не кидаєте код) ІМО, багато правди в цьому, я нещодавно побачив відео на каналі9 на 25-й річниці Excel, де деякі розробники сказали, як навіть сьогодні, якби ви заглянули у джерело, ви перевірили б версію та перейшли до коду, який використовував excel, написаний 20 років тому.

Ви не можете бути на 100% впевнені (коли навіть Netscape допускає помилки (зі статті Joels)), я відчував, що стаття Джоела була надіслана Богом, тому що я можу бути песимістичним і люблю відкидати код, думаючи, що завжди можу написати це краще за секунду час, але я зрозумів, що зараз це просто коштує чимало .

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

Мій реальний світ: Додаток Silverlight, що розробляє v0.6, досі має безлад асинхронних викликів, що робить код таким заплутаним. Оскільки я відкрив реактивне розширення на цьому тижні, я дуже хочу переписати більшу частину коду, але тепер, що я скажу своєму клієнту? Програма працює чудово (з деякою пам’яттю протікає тхо), але їм все одно? Я не можу сказати їм. Обіймаю ще 2-3 тижні, тому що хочу щось зробити. Я, однак, збираюся розгалужувати код і переписувати / грати з ним у вільний час.

Просто мої 2 копійки нормально !?

Існуюче рішення не масштабується.

Я дивлюся на вас, MS Access.

За словами Джоеля, великі переписування - це найгірша стратегічна помилка, яку може зробити компанія:

Те, що ти ніколи не повинен робити, частина I

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

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

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

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

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

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

Існує класичний анекдот про те, "якби я їхав у XI, я б не починав звідси".

Одного разу я взяв на роботу, де основною мотивацією роботодавця було залучити талант на борт, щоб запустити давно перезаписаний бізнес-критичний додаток. Питання, яке мені не вдалося задати, було: чому ти в першу чергу опинився в цій ситуації? Це повинен був бути червоний прапор, чи була причина

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

• занадто мало можливостей у відділі,

• занадто мала оплата від клієнтів або керівництва для додаткової роботи,

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

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

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

Натомість часто трапляються переписування, щоб полегшити проблеми управління:

• все повинно бути в .NET,
• наші розробники кажуть, що наш код відстійний,
• ми технічно відстаємо,
• ми не зможемо знайти ресурси для підтримки нашої системи або, дуже часто,
• минуло десять років, тож пора.

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

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

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

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

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

"Зовсім нове": якщо ви плануєте переписувати, але використовуєте ту саму платформу, то рефакторинг та розумна реструктуризація майже напевно є кращим рішенням. "Платформа", як використовується тут, дещо розпливчаста - вважайте, що вона включає мову та, можливо, ОС (поширюється з Linux на Windows або навпаки), але, мабуть, не є рамкою (наприклад, заміна Struts на Spring).

"Необхідно забезпечити бажану функціональність": близько 2000 року я ініціював проект переписати основний компонент сервера в Java з C ++, щоб увімкнути поточну передачу потоків, кеш-об'єкт та керовані клієнтом транзакції. У той час існувало декілька бібліотек для нарізки C ++, які ми повинні були б підтримувати, і багаторечовий код нашого бази даних мав би потребувати перезапису майже усього потоку. Що стосується транзакцій, керованих клієнтом, то зі старою архітектурою цього не відбудеться.

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

Щоб вирішити, з якого пункту слід починати, потрібно визначити, де значення продовження поточного проекту не перевищує значення, починаючи з початку.

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

З моєї метрики ви повинні задовольнити дві умови, щоб виправдати перезапис:

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

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

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

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

ОП не вказує на масштабність проекту, але основна підказка, яку я взяла, була "написана старою [мовою / діалектом], використовуючи старі [libs]", які для мене є основними драйверами переписування. Насправді більшість проектів, на яких я працював із будь-яким значним довголіттям ринку, врешті-решт розуміють, що розміщення оновлень компіляторів / інтерпретаторів / операційних систем є важливим завданням у підтримці кодової бази.

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

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

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

== Реконструкція на місці для більшої користі, а інше ==

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

1. Якщо у вас є можливість перетворитись на UML і задокументувати, яка там мало архітектура.
2. Якщо ви перебуваєте на контролі версій, погляньте на створення декількох звітів про скасування коду та з'ясуйте, які файли та розділи файлів найчастіше змінюються. Зверніть увагу на це, оскільки вони, ймовірно, будуть сферами, з якими ви хочете мати справу з першими.
3. Перш ніж змінювати будь-який код, завжди намагайтеся додати тестове покриття (навіть некрасиві повнофункціональні тести для стека). Якщо ви маєте справу з великою безладною логікою витягування процесуального коду, ви маєте намір перейти на якийсь розумно названий метод чи функцію та, якщо можливо, додати кілька тестових випадків, які підтверджують ваш новий метод. зробіть будь-якого бога жахливий злом, і вам, якщо можливо, параматизуйте зміни, якщо це щось, що зазвичай перероблене, наприклад, ширина поля чи заголовок, тому буде наступним разом оновлення трохи більше.
4. Використовуйте схему адаптера та працюйте над тим, щоб приховати кінарські біти застарілого коду під килим логічно названих класів та методів, так що для більшості розповсюджених завдань вам та іншим розробникам не доведеться турбуватися про страшні біти, що відбуваються позаду спина за тими приємними маленькими чистими методами та класами, що ти заховав цей спадковий код за собою - як ті приємні сім’ї, які тримають деформованих вбивчих зомбі колишніх членів сім’ї в коморах, щоб вони не псували день у день господарство. . . нормально.
5. Поки ви продовжуєте відбілювати та прибирати розділи коду, продовжуйте розширювати тестове покриття. Тепер ви можете копати ще глибше і «переписувати» ще більше коду, коли це потрібно / бажано, з все більшою впевненістю.
6. Повторіть або застосуйте додаткові підходи до рефакторингу, щоб продовжувати вдосконалювати свою кодову базу.

Розгалуження за допомогою абстракції

1. Визначте проблему в коді, який потрібно видалити (постійний шар, генератор pdf, механізм викладки рахунків, генератор віджетів тощо).
2. запустіть (напишіть, якщо потрібно) деякі функціональні тестові випадки (автоматизовані або вручну, але ви знаєте автоматизовані) на основі кодової бази, націленої на цю функціональність разом із загальною поведінкою.
3. Витягувати логіку, пов'язану з цим компонентом, з існуючої бази даних в клас з деяким розумним інтерфейсом.
4. Перевірте, чи весь код тепер використовується за допомогою нового інтерфейсу для виконання діяльності X, яка раніше була розповсюджена випадковим чином по всьому коду (зірвати базу коду, додати слід до нового класу та перевірити сторінки, які повинні викликати його, тощо), і що Ви можете контролювати, яка реалізація буде використовуватися, змінивши один файл. (реєстр об'єктів, заводський клас, незалежно від IActivityXClass = Settings.AcitivtyXImplementer ();)
5. перезавантажте функціональні тестові випадки, які підтверджують, що все ще функціонує з усіма видами діяльності X у ваш новий клас
6. Пишіть одиничні тести, коли це можливо, у новому класі X обгортки.
7. реалізувати новий клас із менш божевільною логікою спагетті, ніж застаріла реалізація, яка дотримується того ж інтерфейсу, що і спадковий клас.
8. переконайтеся, що новий клас пройшов одиничні тести, які ви написали для попереднього класу.
9. оновіть свій код, змінивши реєстр / factorymethod / все, щоб використовувати новий клас замість старого класу.
10. переконайтеся, що ваші функціональні тести все-таки проходять.

Відкритий закритий принцип та загальний бізнес-логічний / стійкий шар

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

• Як мінімум, відокремте презентаційний шар подалі від шарів бізнесу та наполегливості.
• реалізуйте новий шар інтерфейсу та кращу презентацію, який використовує той самий загальний бізнес та постійний шар.
• Переконайтеся, що дані, створені за допомогою нового інтерфейсу, не порушують старий інтерфейс. (Ви будете знаходитися в гарячій воді, якщо користувачі нового інструменту перебивають користувачів старого інструменту). Якщо ви прагнете до повної зворотної сумісності, вам слід зберегти все до тих же шарів стійкості. Якщо ви просто хочете перенести сумісність у новий інструмент, тоді використовуйте нову базу даних та нові таблиці або таблиці розширень, щоб відстежувати дані, які не є в застарілій системі.
• Для нового рівня функціональності та стійкості потрібно додати нові таблиці, а методи не змінювати існуючу застарілу логіку або додавати стовпці та обмеження до існуючих таблиць. наприклад, якщо вам потрібно почати відстежувати контакт з роботодавцями в надзвичайних ситуаціях, а деякі інші поля не змінюють існуючу таблицю службовців (ми не маємо уявлення про те, які припущення старі дані роблять для цієї таблиці), додайте таблицю розширення Employ_ext id, службовий_id, надзвичайний_контакт_id тощо.
• Повільно переміщуйте користувачів на нову систему. якщо можливо, переведіть застарілу систему в режим лише для читання або просто додайте попередження, яке повідомляє користувачам, що після дати X. вона більше не буде доступна.
• впроваджуйте будь-які пропущені функціональні вимоги або вимоги бізнесу у новому інтерфейсі
• перекинути базу користувачів.
• продовжуйте очищати бізнес-логіку та стійкість шару користувачів іншими методологіями рефакторингу.

Я б сказав, що в просторі Refactor vs Rewrite є третя категорія ... І це оновлення ваших мовних версій, компіляторів та бібліотек ... Іноді просто використання сучасних методів кодування має велику користь.

Візьмемо, наприклад, C #, код v7 пише набагато чистіше, безпечніше і стисліше, ніж v2. Такі речі, як Елвіс та оператор з’єднання нулів, допомагають багато.

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

Крім того, вбудовані системи Linux ... Подумайте про встановлення нових інструментів - переключіться на git із svn. або додати Vi у свою систему тощо тощо

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

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

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

Але це насправді не "переписування" оригіналу в тому сенсі, що ви намагаєтеся досягти паритету функції.