Як я можу оновити велику застарілу базу коду, щоб відповідати конкретним стандартам якості?

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

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

Перед:

• Великий: більше 1MLOC
• Спадщина: відсутні автоматизовані тести
• Погана якість: висока складність, висока муфта, дефекти, що уникнув

Після

• Автоматизовані тести
• Простіші оновлення / обслуговування
• Висока якість: знижена складність, роз'єднаний код, кілька уникнутих дефектів

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

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

Такі книги, як http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052, повинні бути достатньо свідками того, наскільки великі базові кодові коди низької якості поширені в галузі.

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

Це може пояснити недолік досліджень, про які ви говорите. Якщо ви прочитаєте достатню кількість книг, наприклад, Deep C Secrets Пітера Ван дер дер Лінден, ви прочитаєте про помилки мільйона доларів, де частина про проект, який у них був, відсутня.

ПРИМІТКА: Я хотів зробити цей коментар, але це було занадто довго. Я розумію, це не відповідає на питання повністю.

EDIT: C ++ 11 & Довготривалість життєздатності GCC ставиться під сумнів - якщо розробники рефактор GCC і роблять його більш завищеним як LLVM / clang, це може стати хорошим прикладом. В дискусії зазначається, що документація в деяких місцях бідна, що підвищує бар'єр для вступу для нових розробників вище.

3 лютого 2013 року Майкл Меекс, один із розробників LibreOffice, через пару днів веде бесіду під назвою "LibreOffice: очищення та повторне факторинг гігантської бази коду, або чому її перезапис буде ще гірше . " Це звучить як саме те, про що ви просите: обговорення того, що вони зробили, щоб "погано зрозуміла, гігантська база коду, широко коментується німецькою мовою, без одиничних тестів, заплутаною інфраструктурою побудови та двадцять п'ять років невиплаченого технічного боргу »та модернізують його.

Презентацію можна транслювати в Інтернеті , а (я думаю) записи будуть доступні в якийсь майбутній день.

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

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

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

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

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

Скажімо, у вас є, наприклад, 60 000 файлів сильно зв'язаного коду. Ви хочете почати ставити його під тест одиниці, але залежність робить це неможливим. Як це виправити? Ви роз’єднуєте один файл. Ви додаєте автоматизовані тести. Ви повертаєтесь на стійку землю, перш ніж рухатись далі. Повторіть 59999 разів.

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

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

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

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

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

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

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