Чи існують фактичні приклади переписування показників успішності / відмов програмного забезпечення?

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

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

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

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

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

1. Переписати або повторно використати . Вони провели дослідження над програмою Cobol, яка була перетворена на Java.
2. Інша справа була у програмі Повторне використання програмного забезпечення: досвід та уявлення розробників .
3. Повторне використання або перезапис Інше дослідження щодо витрат на обслуговування порівняно з переписанням.

Нещодавно я знайшов ще одну статтю на цю тему: The Great Rewrite . Там автор, здається, потрапив у деякі основні проблеми. Поряд з цим виникла ідея прототипування з використанням запропонованого нового стека технологій та вимірювання того, наскільки швидко розробники підхопили його. Це все було як прелюдія до переписування, що я вважав чудовою ідеєю!

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

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

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

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

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

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

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

Думка про те, що систему можна розбити на частини і зрозуміти окремо, є помилковою. У певний момент часу окремій особі чи декільком особам довелося уявити всю проблему у повному обсязі. Якщо ця проблема - це низка бізнес-проблем та технологій, що їх сприяють; людині в компанії може знадобитися кілька років, щоб зрозуміти всі системи до такого рівня, коли можлива їх заміна без катастрофи або пропущеної вимоги. Це, безумовно, було у моїй компанії, коли я перейшов на посаду директора з технологій. Якби не факт, що я сам кодер, я б не зміг повільно зрозуміти всі деталі погано організованої, щільно поєднаної, щільно пов'язаної архітектури та інтеграції технологій. Якщо маленькі приховані, недокументовані деталі, як"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" не помічені результати можуть бути згубними, і єдиний спосіб це знати - повільно виявити все це.

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

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

Файли cookie створюються, розробляється програмне забезпечення (повинно бути).

Існує багато прикладів компаній, які померли від переписування, як-от Netscape . Є також компанії, які пережили перезапис без великих проблем, як твіттер .

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

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

Я думаю, що в даний час переписування має більше сенсу, тому що ми швидко кодуємося на плечі постійно вдосконалюваних інвазивних рамок, таких як Rails, Grails, AngularJS. Якщо ви хочете перейти від звичайного js до кутового, перепишіть про все, що ви можете зробити. Це все ще може мати тонни сенсу. Якщо ви замінюєте одну реалізацію diy іншою (як і всі приклади в статті Джоела Спольського ), ви, мабуть, божевільні.

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

Виявлене вами тематичне дослідження, здається, було вироблено Fujitsu, і не дивно, що результат був тим, що краще використовувати інструменти Fujitsu.

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

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

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