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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

Это работает лучше, чем вы думаете.

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

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

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

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

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

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

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

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

Answer 3

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

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

(Я люблю удалять код.)

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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