Як підійти до рефакторингу існуючої веб-програми?

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

То як би ви підходили до рефакторингу веб-програми? Які б речі я повинен шукати і в якому порядку? А що з грою браузера та функціональним веб-додатком? Чи буде тоді різниця у підході?

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

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

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

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

Про це чудова книга під назвою "Ефективна робота зі спадковим кодом" Майкла Пір'я. Поміркуймо, у всіх нас є застарілий код.

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

• Так - Веб-додатки відрізняються від веб-сайтів

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

• Почніть використовувати контроль над версіями

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

• Зменшіть нескінченності

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

Ви повинні запитати себе, "даючи URL, яка його нормалізована форма?". Як тільки ви це закріпили. Тоді 50,0000+ URL-адрес на вашому сайті можна зменшити, скажімо, до 2000. що набагато простіше зрозуміти та керувати у своєму розумі.

див .: http://www.sugarrae.com/be-a-normalizer-a-c14n-exterminator/

• Почніть з моделювання "що є", а не "того, що ви хочете, щоб це було"

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

Дивіться: http://www.joelonsoftware.com/articles/fog0000000069.html

Дивіться: http://www.laputan.org/mud/

• Піддавати його тестуванню - це гарна ідея.

Створіть тестовий набір / фреймворк і почніть додавати тести. Але досить складно перевірити якийсь спадковий код. Отже, не зациклюйтесь на цьому. Поки у вас є рамки, ви можете додавати тести потроху.

Дивіться: http://www.simpletest.org/en/web_tester_documentation.html

• Майте сміливість у своїх переконаннях

Більшість літератури про кращі практики розробки програмного забезпечення - це настільний / Enterprise App Centric. Незважаючи на те, що ваш сайт у халаті, ви читаєте ці книги, і можете бути в захваті від мудрості, яка випромінює їх. Але не забувайте, що більшість цієї найкращої практики була накопичена за часів до того, як Інтернет / SEO стали важливими. Ви багато чого знаєте про сучасну Інтернет, більше, ніж згадується в класичних книгах, таких як POEA, Gof тощо. З них можна багато чого взяти, але не відмовляйтеся повністю від власного досвіду та знань.

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

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

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

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

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

Деякі інструменти тут можуть бути корисними. NDepend може виділити сильно зв'язаний код та інші запахи. NCover відстежує рівні покриття вашого коду. По суті, FxCop - це перевірка правильності коду, поза межами того, що робить компілятор. Це всі корисні інструменти, які знадобляться для проектів будь-якого реального розміру, особливо найрізноманітніших.

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

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

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