Как подойти к рефакторингу существующего веб-приложения?

В последнее время я много читал и думал, и пришел к выводу, что, может быть, мне следует переосмыслить свою стратегию веб-разработки. Я много занимаюсь программированием «на лету», и за 2 года работы над веб-приложением на PHP, возможно, началось то, что маленький инструмент стал довольно большим проектом. Но есть тонна унаследованного кода от меня и моего предшественника, фрагмент кода, который мог бы иметь смысл в то время, но сейчас я подвергаю сомнению полезность указанного кода в том виде, в каком он есть на самом деле. Кроме того, такие вещи, как модульное тестирование и разработка через тестирование, не входили в мои задачи до недавнего времени.

Итак, как бы вы подошли к рефакторингу веб-приложения? Какие вещи я должен искать и в каком порядке? А как насчет браузерной игры или функционального веб-приложения? Будет ли тогда разница в подходе?

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

Если вы не можете найти часть, легко тестируемую, вам нужно сделать ее тестируемой без ремней безопасности набора тестов, и в этом случае вы очень осторожно изменяете некоторый почти тестируемый фрагмент кода, чтобы он был тестируемым.

Код, который не отображает данные в браузере - «инфраструктурный» код, модели, элементы, связанные с базой данных - может быть хорошим местом для начала.

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

Об этом есть замечательная книга Майкла Фезерса «Эффективная работа с устаревшим кодом». Посмотрим правде в глаза, у всех нас есть устаревший код.

Главное - протестировать новый код, который вы создаете. Поскольку вам придется прикасаться к другим частям кода, вы также найдете возможности их протестировать. Это длительный медленный процесс, но если вы будете делать это систематически, вы действительно сможете со временем улучшить весь продукт.

• Да - веб-приложения отличаются от веб-сайтов

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

• Начните использовать контроль версий

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

• Уменьшить бесконечность

Если все четыре разные ссылки указывают на один и тот же ресурс, то проблема гораздо больше. Вы заканчиваете тем, что имеете дело с бесконечным количеством URL. Как можно скорее убедитесь, что у вас есть политика нормализации URL. Как только это будет сделано, вы можете начать добавлять семантические значения к URL-адресам и иметь возможность выполнять обратный поиск из ресурса в URL. Это позволяет отделить «веб-отпечаток» от «ресурсов» сайта.

Вы должны спросить себя: «Дали URL, какова его нормализованная форма?». Как только вы это поняли. Тогда 50 000+ 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

• Имейте смелость в своих убеждениях

Большая часть литературы о передовых практиках разработки программного обеспечения ориентирована на настольные системы и приложения для корпоративных приложений. Пока ваш сайт в беспорядке, вы читаете эти книги, и вы можете быть в восторге от мудрости, которая исходит от них. Но не забывайте, что большая часть этой передовой практики была накоплена за время до того, как веб / SEO стали важными. Вы много знаете о современной сети, больше, чем упомянуто в классических книгах, таких как POEA, Gof и т. Д. Из них можно многое извлечь, но не стоит полностью отбрасывать свой собственный опыт и знания.

Я мог бы продолжить. Но это те вещи, которые я выбрал, когда превратил старый унаследованный сайт в новый.

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

Затем напишите тесты для любого кода, который вы планируете изменить. Вам не нужно делать все сразу, писать тесты для всего. Только то, над чем вы планируете немедленно работать. Теория гласит, что при достаточном количестве времени большая часть базы кода будет покрыта тестами. Обратите внимание, что некоторые рефакторинги «безопасны» для обхода без тестов - они задокументированы в упомянутой ранее книге « Legacy Code» и, несомненно, в других местах.

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

Даже с устаревшим кодом вы можете использовать TDD, если вносите дополнения или изменения. Просто напишите сначала тесты для ожидаемых изменений, посмотрите, как они провалились, а затем внесите изменения.

Некоторые инструменты могут быть полезны здесь. NDepend может указывать на сильно связанный код и другие запахи. NCover отслеживает уровни покрытия вашего кода. FxCop - это, по сути, средство проверки правильности кода, помимо того, что делает компилятор. Все эти полезные инструменты пригодятся для проекта любого реального размера, особенно унаследованного.

В конечном счете, это многошаговый процесс. Не пытайтесь делать все сразу, просто делайте это по очереди.

Если это достаточно уродливо, чтобы разозлить меня, то достаточно уродливо, чтобы я удалил всю вещь и написал каплю замены.

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