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

11

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

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

Eldros
источник
4
Если это не сломано, не исправляйте это. Тратьте больше времени на написание тестов и меньше времени на внесение ненужных изменений.
Макнейл
Просто из интереса. На каком языке / технологиях вы написали свое заявление? Что это за сайт? См. Welie.com/patterns -> Контекст дизайна -> Типы сайтов
JW01
@ JW01 Я использую PHP для внутренней логики и AJAX для управления представлениями и проверки формы. Это будет вариант шаблона веб-приложения, но доступный только в данной среде, поскольку он является внутренним инструментом.
Eldros
Когда я отвечал на вопрос, у меня в голове была совершенно другая картина с вашим приложением. У вас гораздо больше свободы для изменения API, чем если бы оно было в открытом доступе.
JW01
@ JW01 Я не хотел быть слишком конкретным, так как хотел, чтобы этот вопрос был полезен и для других.
Eldros

Ответы:

6

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

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

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

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

Фрэнк Шиарар
источник
Как бы вы порекомендовали протестировать часть «представления» унаследованного приложения - IE, часть HTML / JavaScript / CSS / и т. Д.? Я согласен, что модульное тестирование - это то, что нужно, но тестирование кода приложения кажется сложным для автоматизации.
Джастин Этье
при создании тестов для веб-интерфейса - сравнение старого HTML с новым HTML является довольно хрупким способом работы. Я склонен определять семантику веб-страницы и проверять ее. Т.е. спросите "Изменился ли веб-отпечаток (заголовок страницы, заголовок, ключевые слова, исходящие ссылки, формы)?" не «HTML изменился?».
JW01
Вы можете тестировать веб-приложения с помощью «безголового браузера» - в основном это библиотека, предназначенная для модульного тестирования, как браузер для специалиста по обеспечению качества. В мире Java есть HTMLUnit (чистый java, автономный) и WebDriver (удаленно управляет реальным браузером, таким как FireFox). Мой проект имеет набор из сотен тестов, написанных так.
Том Андерсон
@ JW01 Ты абсолютно прав - это очень хрупко. Он отлично подходит для тестирования рефакторинга разовым способом: вы можете проверить, что рефакторинг не изменил вывод, но каждый раз, когда вы изменяете сгенерированный HTML, вы должны сохранять «новый ожидаемый» HTML.
Фрэнк Шиарар
10

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

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

Марси
источник
3
«Посмотрим правде в глаза, все, что мы делаем, это пишем завтрашнее устаревшее программное обеспечение сегодня». - Мартин Фаулер
Фрэнк Шиарар
3
  • Да - веб-приложения отличаются от веб-сайтов

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

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

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

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

Если все четыре разные ссылки указывают на один и тот же ресурс, то проблема гораздо больше. Вы заканчиваете тем, что имеете дело с бесконечным количеством 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 и т. Д. Из них можно многое извлечь, но не стоит полностью отбрасывать свой собственный опыт и знания.


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

JW01
источник
Хорошие справочные ссылки!
Nilesh
2

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

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

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

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

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

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

Грант Пэйлин
источник
-2

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

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

Sneakyness
источник
2
Я не согласен (хотя я не дал вам -1). joelonsoftware.com/articles/fog0000000069.html
JW01
1
Это действительно слишком ситуативное решение, чтобы точно защитить себя. Я мог бы этого не делать, когда я работаю с огромной библиотекой Objective-C, однако у меня нет никаких сомнений по поводу написания совершенно новой библиотеки javascript.
Подлость
Очень плохая идея! Хотелось бы, чтобы я прочитал статью Джоэла Спольски, на которую @WW01 ссылался 2 года назад, прежде чем я решил переписать существующее PHP-приложение, используя Angular & Bootstrap. Angular & Bootstrap - отличные технологии, но я все еще пытаюсь преобразовать это старое приложение 2 года спустя. Я должен был просто изменить существующее приложение, а не вырвать / заменить.
Зак Макомбер
Я согласен, особенно учитывая ваш комментарий. «Сценарий» - это ключевая вещь, которая определяет решение. Должны ли вы вырвать тот огромный API, который обслуживает весь ваш бизнес? Кто знает, есть над чем подумать. Вы хотели бы тесты, прежде чем тестировать потом. Ссылка на статью слишком прямолинейна, как будто есть один размер, который подходит всем, но что делать, если что-то глючит или действительно старый код? Действительно ли статья предполагает, что мы не уходим от устаревшего кода, который более новый, легче читаемый и поддерживаемый? В мире разработчиков нет черного и белого, только сценарии и решения
Джеймс