Лучшие практики для рефакторинга классического ASP?

Предубеждения

Документация для классической системы ASP довольно легкая.

Руководство не ищет переписывания.

Поскольку вы делали ruby на rails, ваш (VB/C#) ASP.NET в лучшем случае сносен.

Мой опыт

Я тоже унаследовал классическую систему ASP, которую волей-неволей сшили вместе бывшие типы excel-vba. Там было много этого материала <font size=3>crap</font> (и иногда отсутствовали закрывающие теги; Арггх!). В течение 2.5 года я добавил систему безопасности, общую библиотеку, CSS+XHTML и смог заставить эту вещь проверить xhtml1.1 (к сожалению, без надлежащего типа mime) и построил довольно надежную и надежную систему отчетности ajaxy, которая ежедневно используется 80 пользователями.

Я использовал jEdit, с cTags (как упоминалось выше в jamting) и кучу других плагинов.

Мой совет : Попробуйте создать мастер-файл включения, из которого можно импортировать все то, что обычно используется. Такие вещи, как доступ к базе данных login/logout,, веб-сервисы, библиотеки javascript и т. д.

Используйте классы. Они ультра-примитивны (без наследования), но, как сказал джемтинг, они могут быть удобными.

Правильно сделайте отступы в скриптах.

Комментарий

Напишите внешний архитектурный документ. Я лично использую LyX, потому что это мертвый мозг, чтобы создать красиво отформатированный pdf, но вы можете использовать все, что вам нравится. Если вы используете wiki, установите надстройку graphviz и используйте ее. Это очень легко сделать быстрые диаграммы, которые могут быть легко изменены.

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

В модульных тестах бизнес-логики единственное, что я обнаружил, что работает, - это установка прослушивателя xml-rpc в asp, который импортирует основную библиотеку и предоставляет функции (хотя и не подпрограммы) в любом из подразделов основной библиотеки, а затем отдельно строит систему модульного тестирования на языке с лучшей поддержкой материала, который вызывает функции ASP через xml-rpc. Я использую python, но я думаю, что Ruby должно сделать трюк. (Есть ли в этом смысл?). Самое классное, что человеку, пишущему модульную тестовую часть программного обеспечения, не нужно даже смотреть на код ASP, пока у него есть приличные описания функций для вызова, поэтому они могут быть кем-то рядом с вами.

Есть проект под названием aspunit на sourceforge, но последний релиз был в 2004 году, и он помечен как неактивный. Никогда не использовал его, но это чистый vbscript. Беглый взгляд на код говорит мне, что, похоже, авторы знали, что делали.

Наконец, если вам нужна помощь, у меня есть некоторые возможности для выполнения контрактной дистанционной работы (возможно, максимум 8 часов в неделю). Для получения контактной информации перейдите по ссылке trail.

Удачи вам! HTH.

Поскольку полная переписка рабочей системы может быть очень опасной, я могу дать вам только небольшой совет: установите в своем проекте изобильные теги, ctags. Таким образом, вы можете перейти к определению функции и sub easy, что, я думаю, очень помогает.

Об отделении логики от "views". VBScript поддерживает som вид OO с классами. Я склонен писать классы, которые выполняют логику, которую я включаю на asp-странице, которая действует как "view". Затем я соединяю представление с классом типа Username: <%= MyAccount.UserName %>. Класс MyAccount также может иметь такие методы, как: MyAccount.Login() и так далее.

Вроде примитивно, но, по крайней мере, вы можете заглавно прописать какой-то код и скрыть его от HTML.

Я использую ASPUnit для модульного тестирования некоторых из наших классических ASP и нахожу это полезным. Он может быть старым, но и ASP-тоже. Это просто, но он действительно работает, и вы можете настроить или расширить его, если это необходимо.

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

Включение файлов может помочь до тех пор, пока вы держите его простым. В какой-то момент я попытался создать include для каждого класса, и это не слишком хорошо сработало. Мне нравится иметь пару основных включений с общей бизнес-логикой, а для сложных страниц иногда включать с логикой для каждой из этих страниц. Я полагаю, что вы могли бы сделать MVC с аналогичной установкой.

Мой совет-продолжить рефакторинг, classic ASP поддерживает классы, поэтому вы должны быть в состоянии переместить все, кроме кода отображения, в включенные файлы ASP, которые просто содержат классы. Смотрите эту статью о деталях перехода от старомодного asp к ASP.NET

Рефакторинг ASP

Что касается будущего направления, я бы не стремился к ASP.NET веб-формам, вместо этого я бы пошел на новый фреймворк Microsoft MVC, надстройку к ASP.NET) будет гораздо проще перейти к этому с классического ASP.

Есть ли хоть какой-то шанс, что вы сможете перейти с ASP на ASP.Net? Или вы смотрите на то, чтобы сохранить его в классическом ASP,но просто очистить его. Если это вообще возможно, я бы рекомендовал переместить как можно больше переходов в .Net. похоже, что вы все равно переписываете/реорганизуете много кода, поэтому переход на .Net не может быть большим дополнительным усилием.

Вероятно, кто-то другой написал большую часть или всю систему, которую вы сейчас поддерживаете. Ищите обычные вредные привычки (повторяющийся код, переменные с слишком широкой областью действия, вложенные операторы if и т. д.), и рефакторинг, как и любой другой язык. Следите за повторяющимися вещами в одном и том же файле или разных файлах и абстрагируйте их в функции.

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

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

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

Он очень старый, но я не удержался и добавил свои два цента. Если вы должны переписать, и должны продолжать использовать классический ASP:

• используйте JScript! гораздо более мощный, вы получаете наследование, и есть некоторые хорошие побочные преимущества, такие как использование тех же методов проверки на стороне сервера, что и на стороне клиента
• вы можете абсолютно сделать MVC-я написал фреймворк MVC, и это было не так много строк кода
• вы также можете создать свои классы моделей автоматически с небольшим количеством работы. У меня есть некоторый код для этого, который работал довольно хорошо
• убедитесь, что вы выполняете параметризованные запросы и всегда возвращаете отключенные наборы записей

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

Я знаю, как трудно делать правильные вещи, даже больше, когда ответственный менеджер знает sht и боится всего, кроме wost way possible.

Но все же ... Необходимо начать работу над созданием нового программного обеспечения. Это просто невозможно поддерживать вечно, и чем дольше они ждут выхода на пенсию, тем хуже.

Если у вас нет надлежащей документации по спецификациям/требованиям (я думаю, что ни одно программное обеспечение asp в мире не делает этого, учитывая noobatry hability этих кодеров), вам понадобится как группа пользователей, которые знают функции программного обеспечения, так и менеджер, который будет отвечать за проверку требований. Вам нужно будет просмотреть каждую функцию и задокументировать ее требования.

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