Каков наилучший подход в аудите большого веб-приложения java / j2ee?

Question

Я должен провести аудит большого веб-приложения Java / J2ee, которое развивалось в течение нескольких года. Это было написано какой-то другой компанией, а не той, на которую я работаю. В его нынешнее состояние стало трудно развиваться и поддерживать, новые Функциональные возможности трудно добавить и часто приводят к ошибкам, которые иногда появляются в производство. Кажется, есть некоторый скопированный / вставленный код, который привел к дублированию кода. Текущее приложение - это своего рода онлайн-шоппинг с контентом в стиле cms. В основном это Struts и немного Spring в новых частях кода, может быть, некоторые ejbs добавлены для хорошая мера. Есть несколько модульных тестов, но их не так много. Это то, что мне сказали, я еще не видел настоящий код.

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

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

• проверить "базовые" вещи - обработка исключений, регистрация
• проверить уровень наслоения (представления, контроллеры, дао-слой)
• измерение фактического охвата модульных тестов
• возможно, запустить несколько проектов Checkstyle, Findbugs и PMD для проектов
• ...

Итак, вопрос в том, что еще я должен принять во внимание / проверить / измерить / и т.д.?

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

Буду признателен за любую идею, предложение, комментарий по этому поводу.

Редактировать: я добавлю два детектора мертвых кодов в микс: UCD и DCD

Answer 1

У меня было два веб-приложения с такими же настройками, как и у вас. Я перестал использовать FindBugs и Checkstyle, поскольку они показали более 10.000 проблемных точек. В приложениях использовался доступ к данным на уровне JDBC, JSP для представления и пользовательская структура для отправки запросов. К счастью для меня, эти настройки низкого уровня позволили мне делать расширения и исправления на средней сложности. В течение трехлетнего проекта осталось только около 20% исходного кода. Рано или поздно все остальное нужно было либо поменять, заменить или удалить (и наконец я смог использовать FindBugs и Checkstyle).

Мы тоже столкнулись с дилеммой полного переписывания. Однако против этого было несколько факторов:

• Не уверен, что клиент заплатит за полное переписывание.
• Отсутствие функциональной и технической документации делает рискованным полное переписывание.
• человеко-часов для полного понимания всего приложения было слишком много. Клиент хотел запрошенных изменений раньше.
• Пользователи, где привыкли к презентации и поведению страницы. Казалось, трудно убедить пользователей использовать новый интерфейс для старых функций.
• Если мы полностью переписываем, нам нужно предоставить полную документацию. Для обновления нам нужно было документировать только нашу часть.
• Трудно убедить руководство (собственное и клиентское) в перезаписи, если программа работает (более или менее)
• У компании были свои правила PMD, и код не прошел. Проще было утверждать, что достаточно, чтобы новые детали выдержали испытание.

Это сводит на нет то, что вы хотите сделать на самом деле.

Хотите переписать, несмотря на сложность?

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

Не хотите переписать?

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

Если вы хотите попробовать код, попробуйте добавить Hello World! функция / экран для приложения. Это говорит о том, насколько сложно и быстро вы можете внедрять новые вещи.

Answer 2

Фактически они не будут платить за полное переписывание, потому что:

• Это спад, стоимость переписывания с нуля будет высокой

• Возможно, они пытаются продать компанию как можно скорее

• Руководство ничего не понимает в разработке программного обеспечения

Сначала я приведу несколько простых фактов:

• Используйте инструмент для отображения SLOC проекта
• Запустите, как вы запланировали FindBugs и, в конечном итоге, PMD, просто чтобы оценить дефекты
• Провести сеанс быстрого профилирования
• Проверьте разные слои
• Проверьте, закрыты ли обычно ресурсы (потоки, соединения Hibernate или JDBC и т. Д.)
• Проверьте, используются ли технологии там, где они не применяются (EJB, веб-службы и т. Д.)
• Посмотрите, как они обрабатывают исключения и ведение журнала
• Посмотрите, слишком много или мало абстракции
• Посмотрите, можете ли вы добавить несколько базовых классов, чтобы уменьшить дублирование кода

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

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

Обычно унаследованные приложения Struts не нуждаются в поддержке, если бы это было сделано. Если бы это не было частью вашей работы, я бы сказал, отпустить. Если вы сталкиваетесь с «автономными» страницами, которые не содержат много шаблонов и подвергаются многим изменениям, предложите переписать их с другой технологией.

Answer 3

Вы сосредотачиваетесь на удобстве обслуживания и расширяемости, которые нацелены на

Я бы добавил, посмотрев, сколько времени потребуется, чтобы перезагрузить проект. Они используют контроль источника? Есть ли у них отдельные среды для интеграции и приемочного тестирования? Есть ли сервер сборки?

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

Answer 4

Мне очень нравится ваш список. Я думаю, у вас есть отличный план атаки для начала.

Я бы посмотрел на стандартизацию Spring или EJB 3.0, но не на оба.

Я сам не читал, но мне интересно, есть ли у книги Майкла Фезерса «Эффективная работа с устаревшим кодом» какие-нибудь хорошие идеи?

UPDATE:

Может быть, вы можете помочь, поставив их на автоматическую сборку и непрерывную интеграцию - Cruise Control, Hudson или Team City. Если вам понадобится рефакторинг, это поможет.