Ви коли-небудь брали участь у BIG Rewrite? [зачинено]

Джоел Спольський сказав в одному зі своїх відомих дописів:

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

Чад Фаулер написав:

Ви переглядали відео, публікації веб-журналів та ажіотаж, і вирішили, що збираєтеся повторно впровадити свій продукт у Rails (або Java, або .NET, або Erlang тощо).

Остерігайся. Це довший, важчий і невдалий шлях, ніж ви очікуєте.

Ви коли-небудь брали участь у BIG Rewrite?
Мене цікавить ваш досвід цієї трагічної теми, і зокрема, будь-яке велике переписування, яке було завершено успішно (якщо воно є).

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

• Необхідні найменші затрати зусиль: Кожен раз, коли хтось хоче переписати, це тому, що стара система використовує стару технологію і важко підтримувати. Те, що вони не враховують, це те, що через його вік у нього можуть бути 30-40 чоловік років на розвиток. Думаючи, що можна потім переписати всю справу за 6 місяців з командою з 5 нерозумно.
• Втрачені знання: Стара система існувала так довго, вона робить багато чого, і приєднується до всього. Немає актуальної документації та немає єдиного органу влади, який би насправді знав усе, що робить система. З певними користувачами в окремих відділах з'являться відомості, і знайти їх все складно або неможливо.
• Погані управлінські рішення: Переписувачі, в яких я брав участь, мали подібні очікування від керівництва: Нова система повинна бути "зроблена", а стару систему можна було просто вимкнути на певну дату, період. Жоден інший варіант не був прийнятним. Я думаю, що вони отримують це в голові, тому що вони витрачають усі ці гроші, щоб найняти нових людей для цього величезного проекту. Насправді кращою стратегією зменшення ризику є переписання основних функцій старої системи, скажімо, спочатку 50-75% старої системи для першого випуску, а потім подивіться, як вона працює! Через №1 та №2 вище, це, мабуть, вийде набагато краще, оскільки ми з’ясуємо деякі функції, які були пропущені, і що потрібно, щоб фактично вимкнути стару систему.

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

Проект 1

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

Рішення. Ми скористалися переписанням лише на двигун шаблону. Ми використовували належний дизайн OO, щоб подбати про поточні вимоги, а також вирішити нові вимоги до дошці. Час для переписування становив 1 місяць. Якби ми зробили масштабну перезапис цілого ланцюга інструментів, це зайняло б багато років - але нам цього не потрібно було робити.

Проект 2

Веб-додаток, яке наша команда розробила з нуля, починало переробити свій оригінальний дизайн. У нашого клієнта також був набір нових вимог, які б зробили сайт набагато кращим для наших користувачів, більш сумісним з "Web 2.0". Хоча ми могли вбудовувати свій існуючий дизайн у рамки, які ми мали, технічне обслуговування було кошмаром. Ми добре знали додаток, і ми знали, які деталі нам потрібно висувати і які частини відходити в рамках нової версії.

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

Проект 3

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

Рішення. Ми завершили перезапис приблизно через 4,5 місяці, коли ми оцінили 3 місяці. Додаток працював краще, як в інтерфейсі користувача, так і в кількості даних, з якою він може працювати. Тоді сталося цунамі 2004 року. Сама велика кількість людей, яких вони мали відстежити, показала, що Swing - це неправильна технологія для того, що їм справді потрібно. Ми не змогли йти в ногу з налагодженням своєї продуктивності, і вони врешті відмовилися від інструменту на користь спільного веб-додатка, створеного командою Oracle, яка була у них вдома. Впевнені, що ми могли б виправдати те, що ми зробили, базуючись на знаннях, які ми мали тоді, але переписування було недостатньо агресивним, і ми не змогли сказати нашому клієнту, що їх вимоги щодо кількості людей, які, можливо, могли б відстежити, були занадто низький.

Висновок

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

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

Я брав участь з кількома переписувачами, які переходили від VB6 до .NET. У 2 випадках переписування пройшло гладко, і нас фактично закінчили достроково. Інше перезапис зайняло більше часу, ніж очікувалося, але завершено без особливих проблем.

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

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

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

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

Мета: Запровадити корпоративну систему ідентичності, яка могла б підтвердити автентифікацію облікових записів у чотирьох доменах та повністю керувати (за допомогою самообслуговування) облікових записів у 1 з доменів. Оскільки .Net вже був впроваджений на супутниках, класичний asp-сайт, який виконував функцію "введення", потрібно буде переписати, додано управління ідентифікацією, і всі сайти потребують регресійного тестування, щоб переконатися, що на послуги не вплинуло.

Ресурси: 3 первинних архітектора - програміст, управління ідентифікацією, керівник проекту. Приблизно 20 розробників, 10 аналітиків, 10 тестерів.

Час до завершення (початок до кінця): 1,5 року

Успіх запуску: поблизу відмови

Успіх довголіття: приголомшливий

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

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

До кінця першого дня всі сайти запрацювали і все працювало (я б сказав номінальний успіх). Протягом останніх 2,5 років все було надзвичайно успішним. Наявність всіх наших сайтів на загальній архітектурі із загальною базою рамки значно спростила розробку та роботу між розробниками. Особливості, які я написав на нашому сайті 2,5 роки тому (під час переписування), з тих пір побачили / прийняли пара супутникових силосів.

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

У нашому проекті було багато розчарувань, душевних болів і катастроф. Врешті-решт це окупилося і потім дещо. Я на 100% згоден з оцінкою переписувачів Джоела Спольського як загальне правило, але завжди є винятки. Якщо ви думаєте про перезапис, просто потрібно переконатися, що це абсолютно те, що вам потрібно. Якщо це так, то будьте готові до всіх болів, які приходять з ним.

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

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

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

Це була внутрішня заявка - фактично головний бізнес-додаток.

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

Все залежить. У моєму випадку я дотримувався поради Джоела Спольського, і я помилявся . Йшлося про страховий веб-сайт. Сайт був жахливим, і ось що я зробив, то що я повинен був зробити:

Погана стратегія: я керував групою з 4 студентів, щоб:

• Студент №1 - переписав доступ до бази даних / запити, щоб зробити їх безпечними
• Студент №2 - перемістив увесь css "вгору"
• Студент №3 - зробив усі сторінки w3c сумісними
• Студент №4 - вирішив усі відкладені помилки
• Я сам: видалив усі php-попередження та хитрі речі (повторюваний код тощо)

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

Гарна стратегія:

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

Час, який знадобився б: два місяці ( може, і менше ).

• Хороший код.
• Гарне обслуговування.
• Продуктивність.
• Немає відповідей на кшталт "ми не можемо цього зробити, Веб-сайт не може обробляти такі продукти".

Отже, моє заключне слово: все залежить від складності речей, які вам доведеться переписати .

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

Олів'є Понс

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

Половина команди була налаштована працювати на рефактор, а інша половина продовжувала підтримувати та вдосконалювати існуючий продукт.

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

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

Але в кінцевому підсумку це було падінням компанії.

Останні 3 роки я переглядаю велику переписку. Оригінально ми оцінили, що проект займе 2 роки. Основна ідея полягала в тому, щоб замінити апаратне забезпечення, використовувати існуючу ОС, переписати логіку бізнесу (від c до CPP), створити нову IO-карту і написати новий інтерфейс користувача.

По дорозі ми приймали деякі жахливі рішення. У нас не було реального досвіду CPP і не було наставника, який би його добре навчав. Ми спробували самостійно створити структуру інтерфейсу користувача на основі win32. Обладнання було дешевим, а BSP помилився помилками. Програмне забезпечення було дуже гнучким, але важким у обслуговуванні. Минулого року ми викинули інтерфейс, що виростав удома, та розробили інтерфейс у .net. Ми також повністю переписали свій механізм збереження та протокол передачі даних.

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

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

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

Я написав двигун блогу за 3 тижні. Я переписав його через 8 годин.

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

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