Переход с ASP Classic на .NET и смягчение боли

Question

Мы находимся в процессе редизайна раздела нашего сайта, ориентированного на клиентов, в .NET 3.5.Пока все идет хорошо, мы используем тот же рабочий процесс и хранимые процедуры, по большей части, самые большие изменения касаются пользовательского интерфейса, ORM (от словарей до LINQ) и, очевидно, языка.Большинство страниц до этого момента были тривиальными, но сейчас мы работаем над самыми тяжелыми страницами рабочего процесса.

Главная страница нашего раздела приема предложений занимает 1500 строк, около 90% из которых - ASP, и, вероятно, еще 1000 строк - вызовы функций includes .Я думаю, что 1500 строк тоже немного вводят в заблуждение, поскольку мы работаем с подобными камнями

function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID,  sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)

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

После того, как я все закодирую, я сделаю несколько проходов при рефакторинге / тестировании.Мне просто интересно, есть ли у кого-нибудь какие-нибудь советы о том, как сделать этот процесс немного проще / эффективнее.

Answer 1

Поверь мне, я знаю именно так туда, откуда ты идешь..В настоящее время я переношу большое приложение с ASP classic на .NET..И я все еще учусь ASP.NET !:С (да, я в ужасе!).

Главное, что я запомнил, - это следующее:

• Я не сбиваюсь с пути истинного слишком далек от текущего дизайна (т. е.no massive "давайте вырвем ВСЕ это и сделаем это ASP.NET волшебным!) из-за невероятно высокого уровня сцепления, которым обычно обладает ASP classic, это было бы очень опасно.Конечно, если вы уверены, заправьте свои ботинки :) Это всегда можно переделать позже.
• Подкрепляйте все тестами, тестами и еще раз тестами!Я действительно изо всех сил пытаюсь освоить TDD, но тестировать существующие приложения очень сложно, поэтому каждый раз, когда я удаляю фрагмент classic и заменяю на .NET, я гарантирую, что у меня есть как можно больше подтверждающих тестов.
• Изучите много, есть некоторые СЕРЬЕЗНЫЕ изменения между classic и .NET, и иногда то, что может состоять из многих строк кода и включено в classic, может быть достигнуто за несколько строк кода, подумай перед кодированием..Я учился этому на собственном горьком опыте, несколько раз :D

Это очень похоже на игру Дженга с вашим кодом :)

Желаю удачи в проекте, если возникнут еще вопросы, пожалуйста, задавайте :)

Answer 2

После того, как я все закодирую, я сделаю несколько проходов при рефакторинге / тестировании.Мне просто интересно, есть ли у кого-нибудь какие-нибудь советы о том, как сделать этот процесс немного проще / эффективнее.

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

Сначала напишите несколько тестов, которые проверят, что на самом деле делает бит, на который вы смотрите.Затем выполните рефакторинг.Это НАМНОГО надежнее, чем просто "похоже, что это все еще работает".

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

Answer 3

Вы переходите от классического ASP к ASP с 3.5, не просто переписывая?Скиллз.Мне приходилось иметь дело с некоторым устаревшим ASP @work, и я думаю, что его просто проще разобрать и переписать заново.

Answer 4

Страница ASP на 1500 строк?С большим количеством вызовов для включения файлов?Только не говорите мне, что у функций нет никакого соглашения об именовании, которое указывало бы вам, какой включаемый файл имеет свою реализацию...Это навевает воспоминания (содрогается)...

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

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

Удачи вам!

Answer 5

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

Для файлов большего размера я бы сначала попытался получить представление более высокого уровня.Например, одна вещь, которую я заметил, это то, что Классический ASP был ужасен в отношении вызовов функций.Вы бы прочитали какой-нибудь код и нашли вызов функции, не имея ни малейшего представления о том, где она может быть реализована.В результате классический ASP-код, как правило, содержал длинные функции и скрипты, чтобы избежать этих неприятных скачков.Я помню, что видел функцию, которая печатала до 40 страниц!Разбирать сразу такое количество кода - невесело.

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

Answer 6

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

Как вы догадались?;)

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

Это было то, о чем мы говорили.Исходя из сроков (попытка опередить сайт конкурента для запуска) и ресурсов (в основном, двух разработчиков), имело смысл не взрывать сайт ядерной бомбой с орбиты.На самом деле все прошло намного лучше, чем я ожидал.Еще на стадии планирования мы понимали, что этот код доставит нам больше всего проблем.Вы должны посмотреть историю правок задействованных классических страниц ASP, это настоящая кровавая баня.

Для больших файлов, я хотел бы попробовать получить высокий уровень смотреть в первую очередь.Например, одна вещь, которую я заметил, это то, что Classic ASP был ужасен в отношении вызовов функций.Вы бы прочитали какой-нибудь код и нашли вызов функции без понятия о том, где это может быть реализовано.В результате классический ASP-код имел тенденцию содержать длинные функции и скрипты, чтобы избежать этих неприятных переходов.Я помню, я видел функцию, которая распечатывала до 40 страниц!Синтаксический анализ насквозь такое количество кода не доставляет удовольствия.

На самом деле я довольно часто испытывал неудовольствие от работы с устаревшим кодом, поэтому у меня есть приличное понимание системы на высоком уровне.Вы правы насчет длины функции, есть некоторые подпрограммы (большинство из них я реорганизовал в гораздо меньшие), которые в 3-4 раза длиннее любой из aspx-страниц / вспомогательных классов / ORM на новом сайте.

Answer 7

Однажды я наткнулся на .Сетевое приложение, которое было портировано с ASP.Страницы в формате .aspx были абсолютно пустыми.Для рендеринга пользовательского интерфейса разработчики использовали StringBuilders в коде, а затем выполнили response.write .Это был бы неправильный способ сделать это!

Answer 8

Однажды я наткнулся на .Сетевое приложение, которое было портировано с ASP.Страницы в формате .aspx были абсолютно пустыми.Для рендеринга пользовательского интерфейса разработчики использовали StringBuilders в коде, а затем выполнили response.write .Это был бы неправильный способ сделать это!

Я видел, как это делалось другим способом, код за страницей был пустым, за исключением объявления глобальных значений, тогда VBScript был оставлен в ASPX.