Як у застарілій кодовій базі як швидко дізнатися, що використовується, а що ні?

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

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

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

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

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

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

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

• Скористайтеся інструментом павука, щоб зрозуміти, які сторінки існують, а що - вхідні. Навіть основний інструмент перевірки посилань - не конкретний інструмент "павук для аудиторських цілей" - буде корисним у цьому плані.
• Складіть основну таблицю аудиту / інвентаризації. Це може бути таким же простим, як список файлів та час останнього змінення, організований за каталогом. Це допоможе вам зрозуміти сферу застосування, і коли ви перейдете до таких каталогів, як _OLD та _DELETE, ви можете зауважити, що а) ваша оцінка базується на матеріалах, не в цих каталогах; б) наявності цих каталогів та потенціалі для жорстокі / приховані кошмари певним чином засвідчують глибші проблеми, які слід враховувати в заявці вашого клієнта . Вам не доведеться витрачати мільйон років, перераховуючи можливі проблеми в _OLD або _DELETE; інформація надійде в можливу пропозицію.
• З огляду на те, що ви переглядаєте те, що виглядає як повністю веб-додаток, навіть стандартними інструментами для аналізу журналів стануть вашим другом. Ви зможете додати до електронної таблиці якесь відчуття "це в топ-10 доступних скриптів" або щось подібне. Навіть якщо сценарії вбудовані у файли Flash і, отже, не підлягають папці, існує велика ймовірність доступу до них через POST або GET і відображатиметься в журналах сервера. Якщо ви знаєте, що у вас є 10 високодоступних сценаріїв, а не 100 (або навпаки), це дасть вам хороше уявлення про те, як ймовірно пройдуть роботи з обслуговування.

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

Настійно рекомендую рефакторинг існуючого вихідного коду (на відміну від переписання), використовуючи шаблони, знайдені в книзі " Ефективна робота зі застарілим кодом ".

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

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

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

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

Читати код важче, ніж його писати. ". - http://www.joelonsoftware.com/articles/fog0000000069.html

У типовій базі коду Java я розглядаю можливість використання таких інструментів, як PMD, FindBugs або Sonar, а потім спробую зрозуміти звітність про інструменти (мертвий код, недокументований код, дублюваний код тощо)

На основі звітів я спробую знайти різні шари програми / сайту (бізнес-рівень, DB, SQL тощо)

Якщо шари з’єднані (html в межах сервлета, sql в коді Java), я спершу розпочну з роз'єднання кожного з цих кроків, слід вважати ізольованим, і ви можете зробити в кінці кожного (запустивши гілку, потім зробіть об'єднання) .

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

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

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

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

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

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

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

3. Статичний аналіз та деякі компілятори також можуть виявити мертвий код, але все ще не дає відповіді, яку ви хочете.

4. Аналіз самих даних або метаданих бази даних може виявити цікаву інформацію. Наприклад, було б легко стверджувати, що таблиця LogonAudit(uniqueidentifier LogonAuditId, datetime LogonEvent, ...)більше не використовується, якщо вона містить 10 000 записів на день за 2006–2009 роки, а записів - з 18 ^{вересня} 2009 року. таблицю, яка містить дані з відступом, здебільшого лише для читання.

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

// Warning: WTF code below. Read with caution, never reuse it, and don't trust
// the comments.

private IEnumerable<Product> GetProducts()
{
    // Get all the products.
    return this.GetEntities<Product>("PRODUCT");
}

private IEnumerable<T> GetEntities<T>(string tableName)
{
    // Everyone knows that SQL is case sensitive.
    tableName = tableName.ToLower();

    if (tableName == "user" || tableName == "product")
    {
        // Those tables were renamed recently in the database. Don't have time
        // to refactor the code to change the names everywhere.
        // TODO: refactor the code and remove this `if` block.
        tableName += "s";
    }

    if (this.IsDelme(tableName))
    {
        // We have some tables which are marked for deletion but are still
        // used, so we adjust their name.
        tableName = this.Delme(tableName);
    }

    return this.DoSelectQuery<T>("select top 200 * from " + tableName);
}

private bool IsDelme(string name)
{
    // Find if the table is among candidates for removal.
    List<string> names = this.Query<string>("select Names from DelmeTables");
    return names.Contains(name);
}

private string Delme(string name)
{
    // Return the new name for a table renamed for deletion.
    return string.Join("_", new [] { name, "delme", "not", "used" });
}

Чи можете ви зрозуміти, що цей код фактично використовується products_delme_not_used таблицю?

Якби я був ти, я би:

1. Тримайте всі об’єкти бази даних на місці,
2. Рефакторинг всієї програми (якщо вона того варта),
3. Документуйте (під час рефакторингу) програму та конкретно використання бази даних.

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

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

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

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

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

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

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