Если решено, что наша система нуждается в капитальном ремонте, что это лучший способ сделать это?

Question

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

В настоящее время существует два пути обсуждаются:

1. Порт существующих приложений на классический ASP с помощью JScript, который позволит нам, мы надеемся перейти оттуда в .NET MSJscript без особых проблем, и в конечном итоге на платформе .NET (желательно, что материал MVC будет выполнен к тому времени, ASP.NET не намного лучше, чем мы были сейчас, по нашему мнению). Это было доказано как более безопасный путь с меньшим риском, чем следующий вариант, хотя это может занять немного больше времени.
2. Полностью переписывайте приложение, используя некоторые другие технологии, прямо сейчас лидером пакета является Python WSGI с пользовательской структурой ORM и хорошим решением для шаблонов. Здесь есть место для маневра для даже джанго и других готовых решений. Этот метод, мы надеемся, будет самым быстрым решением, так как мы, вероятно, будем запускать бета-версию рядом с фактическим продуктом, но у него действительно есть большая трата времени, если мы не сможем/не поймем это правильно.

Это не значит, что наша логика исчезла, поскольку то, что мы построили на протяжении многих лет, довольно стабильно, как это было замечено, просто трудно справиться. Он построен на SQL Server 2005 с интенсивным использованием хранимых процедур и опубликован на IIS 6, просто для получения более подробной информации.

Теперь вопрос. Кто-нибудь взял один из двух путей выше? Если это так, было ли это успешным, как это могло быть лучше и т. Д. Мы не стремимся сильно отклоняться от выполнения одной из этих двух задач, но некоторые предложения или другие решения потенциально могут быть полезными.

Answer 1

Не выбрасывайте свой код!

Это самая худшая ошибка, которую вы можете сделать (на большой кодовой базе). См. Things You Should Never Do, Part 1.

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

Для новых функций в вашем приложении, write it in C# and call it from your classic ASP. Вы будете вынуждены быть модульными при перезаписи этого нового кода. Когда у вас есть время, рефакторинг части вашего старого кода на C# также, и выработайте ошибки, когда вы идете. В конце концов, вы замените приложение на новый код.

Вы также можете написать собственный компилятор. Мы уже давно написали один для нашего классического приложения ASP, чтобы позволить нам выводить PHP. Это называется Wasabi, и я думаю, что это причина, по которой Джефф Этвуд думал, что Джоэл Спольский ушел со своего рокера. На самом деле, может быть, нам стоит просто отправить его, и тогда вы сможете это использовать.

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

Кроме того, если это внутреннее приложение, просто оставьте его. Не переписывайте его - вы единственный клиент, и если вам нужно выполнить его как классический asp, вы можете выполнить это требование.

Answer 2

Используйте это как возможность удалить неиспользуемые функции! Определенно идти с новым языком. Назовите это 2.0. Будет намного меньше работы по восстановлению 80% этого, что вам действительно нужно.

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

(я люблю, чтобы удалить код.)

Answer 3

Я бы не рекомендовал JScript, как это, безусловно, дорога меньше путешествовали. ASP.NET MVC быстро созревает, и я думаю, что вы можете начать миграцию на него, одновременно наращивая структуру ASP.NET MVC по мере ее завершения. Другой вариант - использовать что-то вроде ASP.NET w/Subsonic или NHibernate.

Answer 4

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

Answer 5

Это работает лучше, чем вы могли поверить.

Недавно я сделал большую обратную инженерную работу в отвратительной старой коллекции кода C.Функция по функциям Я перераспределил функции, которые по-прежнему актуальны для классов, написали модульные тесты для классов и создали то, что выглядело как замещающее приложение. У него был некоторый оригинальный «логический поток» через классы, а некоторые классы были плохо разработаны [В основном это было из-за подмножества глобальных переменных, которые было слишком сложно разделить.]

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

В прошлом году я написал план проекта замены 30-летнего COBOL. Клиент склонялся к Java. Я прототипировал пересмотренную модель данных в Python, используя Django как часть усилий по планированию. Я мог бы продемонстрировать основные транзакции, прежде чем я планировал.

Примечание: Быстрое создание интерфейса модели и администратора в Django, чем планирование проекта в целом.

Из-за менталитета «мы должны использовать Java» результирующий проект будет больше и дороже, чем завершение демонстрации Django. Без реальной стоимости, чтобы сбалансировать эту стоимость.

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

Примечание: У меня была работающая реализация Django (только для моделей и администраторов), которые я использовал для планирования остальных усилий.

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

Answer 6

Не пытайтесь перейти 2.0 (больше функций, которые в настоящее время существуют или запланированы) вместо этого создайте новую платформу с целью разрешения текущих проблем с базой кода (ремонтопригодность/скорость/wtf) и оттуда.

Answer 7

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

Мой план состоит в том, чтобы в конечном итоге система ответила на WSGI, но я еще не там. Я нашел лучший способ сделать это, это небольшими шагами. За последние 6 месяцев повторное использование кода увеличилось, и прогресс ускорился.

Общие принципы, которые работали для меня:

1. Выбросьте код, который не используется или закомментированы
2. Выбросьте все комментарии, которые не являются полезными
3. Определить иерархию слоя (модели , бизнес-логику, логику просмотра/контроллера, логику отображения и т. д.) вашего приложения. Это не очень четкая архитектура, но, должно быть, поможет вам подумать о различных частях вашего приложения и поможет вам лучше классифицировать ваш код.
4. Если что-то грубо нарушает эту иерархию, измените код нарушения. Переместите код, перекодируйте его в другое место и т. Д. В то же время отрегулируйте остальную часть вашего приложения, чтобы использовать этот код вместо старого. Бросьте старый, если он больше не используется.
5. Храните ваши API просто!

Прогресс может быть кропотливо медленным, но он стоит того.

Answer 8

Хорошее место для начала, если вы подумываете о переходе на Python, это переписать интерфейс администратора в Django. Это поможет вам получить некоторые из перегибов, разработанных с точки зрения получения Python и работы с IIS (или для переноса его на Apache). Кстати, я рекомендую isapi-wsgi. Это самый простой способ начать работу с IIS.

Answer 9

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