Каков наилучший подход к аудиту большого веб-приложения java / j2ee
Вопрос
Мне нужно провести аудит большого веб-приложения Java / J2ee, которое развивалось на протяжении нескольких лет .Она была написана какой-то другой компанией, не той, в которой я работаю.В его текущем состоянии стало трудно развиваться и поддерживаться, новые функциональные возможности трудно добавлять и они часто приводят к ошибкам, которые иногда проявляются в продакшн.Похоже, что был какой-то скопированный / вставленный код, который привел к дублированию кода.Текущее приложение представляет собой что-то вроде онлайн-магазина с некоторым контентом, похожим на cms, здесь и там.В основном это распорки и немного пружины в более новых частях кода, возможно, добавлено несколько ejb-файлов для хорошая мера.Есть несколько доступных модульных тестов, но их не так много.Это то, о чем мне говорили, я еще не видел самого кода.
Моя компания предложит переписать части этого приложения, чтобы уменьшить сложность, улучшить качество и модульность, а также сделать возможным добавление более простых новых функциональных возможностей без регрессий.Прежде чем брать на себя какие-либо обязательства, они хотели бы получить некоторую оценку качества существующего кода и оценить, сколько из него можно использовать повторно, чтобы иметь больше, чем предположение о том, что там нужно будет сделать - полный рерайт или частичный рерайт.
Загвоздка в том, что мне придется сделать это за очень короткий период (пару дней), поэтому я пытаюсь разработать план того, что можно сделать за такое короткое время.Что я имею в виду, так это :
- ознакомьтесь с "базовыми" вещами - обработкой исключений, протоколированием
- проверьте уровень многоуровневости ( представления, контроллеры, уровень dao)
- измерьте фактический охват модульных тестов
- может быть, запустить какой-нибудь Checkstyle, Findbugs и PMD поверх проектов
- ...
Итак, актуальный вопрос заключается в том, какие еще вещи я должен принять во внимание / проверить / измерить / etc ?
Я не уверен, какие цифры я мог бы извлечь из этого и действительно ли это что-то значило бы У меня такое чувство, что то, о чем просит руководство, отчасти неверно подход, поэтому второй вопрос был бы :у кого - нибудь есть идея получше ?
Я буду признателен за любую идею, предложение, комментарий по этому поводу.
Редактировать:Я добавлю к этому два детектора мертвого кода : UCD и DCD
Решение
У меня было два веб-приложения с такими же настройками, как у вас.Я перестал использовать FindBugs и Checkstyle, поскольку они показали более 10 000 проблемных точек.Приложения использовали доступ к данным на уровне JDBC, JSP для представления и пользовательскую платформу для отправки запросов.К счастью для меня, эти низкоуровневые настройки позволили мне выполнять расширения и исправления на средней сложности.В течение 3-летнего проекта только около 20% исходного кода осталось в прежнем виде.Рано или поздно все остальное нужно было либо менять, заменять, либо удалять (и, наконец, я смог использовать FindBugs и Checkstyle).
Мы тоже столкнулись с дилеммой полного переписывания.Однако против этого было несколько факторов:
- Не уверен, что клиент заплатит за полное переписывание.
- Отсутствие функциональной и технической документации делает рискованным полное переписывание.
- Человеко-часов для полного понимания всего приложения было слишком много.Клиент хотел, чтобы запрошенные изменения были внесены как можно скорее.
- Пользователи были настроены на презентацию и поведение страницы.Казалось, было трудно убедить пользователей использовать новый интерфейс для старых функций.
- Если мы полностью переписываем текст, нам необходимо предоставить полную документацию.Для обновления нам нужно было задокументировать только нашу часть.
- Трудно убедить руководство (собственное и заказчика) в необходимости переписывания, если программа работает (более или менее)
- У компании были свои собственные правила PMD, и кодекс не прошел.Проще было возразить, что достаточно, чтобы новые детали прошли тест.
Это сводится к тому, что вы хотите сделать на самом деле.
Вы хотите переписать, несмотря на сложность?
- Сделайте акцент на ошибках в коде.Большие круговые диаграммы с большим количеством красного цвета выглядят убедительно.
- Объясните свойства программы и то, почему они не вписываются в корпоративное видение.
- Покажите варианты улучшения, выходящие за рамки текущих требований, и опишите, почему текущая версия не соответствует поставленной задаче.
- Проведите интервью с реальными пользователями.Они могут указать на важные проблемы с текущей версией.
- Будьте дешевым, но хорошим оценщиком.Вы могли бы отложить некоторые расходы до этапа технического обслуживания.
Ты не хочешь переписывать?
- Делайте упор на стоимость, особенно на количество человеко-часов, требуемых от заказчика для повторного тестирования всего.
- Укажите на потенциальную проблему нарушения функциональности.
- Попросите штатного составителя документов.
Если вы хотите попробовать код на вкус, попробуйте добавить Hello World!функция / экран для приложения.Это говорит о том, с каким трудом и как быстро вы можете внедрять новые вещи.
Другие советы
На самом деле они не будут платить за полное переписывание, потому что :
Это рецессия, затраты на то, чтобы вы переписали ее с нуля, будут высокими
Возможно, они пытаются продать компанию как можно скорее
- Руководство ничего не понимает в разработке программного обеспечения
Сначала я бы остановился на некоторых простых фактах :
- Используйте инструмент для отображения SLOC проекта
- Запустите, как вы планировали, FindBugs и, в конечном счете, PMD, просто чтобы оценить дефекты
- Выполните быстрый сеанс профилирования
- Проверьте различные слои
- Посмотрите, закрыты ли ресурсы обычно (потоки, соединения в режиме гибернации или JDBC и т.д.).
- Посмотрите, используются ли технологии там, где они неприменимы (EJBS, веб-сервисы и т.д.)
- Посмотрите, как они обрабатывают исключения и ведение журнала
- Посмотрите, слишком много или недостаточно абстракции
- Посмотрите, не могли бы вы добавить несколько базовых классов, чтобы уменьшить дублирование кода
Попробуйте нарисовать краткую диаграмму архитектуры приложения, если они не дают вам документа об этом.
Соберите некоторую статистику и некоторые факты, напишите отчет и отправьте их в компанию.Они захотят минимизировать затраты и попросят вас избегать исправления кода, который не является сломанным.Вы начинаете со статистики, затем переходите к фактам и предложению с указанием времени / приблизительного процента затронутого кода / цены.
Обычно устаревшие приложения Struts - это pita для обслуживания, было ли это сделано.Если бы это не было частью твоей работы, я бы сказал, забудь об этом.Если вы столкнетесь с "автономными" страницами, которые не содержат большого количества шаблонов и подвержены многочисленным изменениям, предложите переписать их с помощью какой-нибудь другой технологии.
Вы фокусируетесь на ремонтопригодности и расширяемости, которые находятся на высоте.
Я бы добавил, глядя на то, сколько времени потребуется для перезагрузки проекта.Используют ли они систему управления версиями?Есть ли у них отдельные среды для интеграции и приемочного тестирования пользователей?Есть ли сервер сборки?
Когда вам приходится потратить два месяца, прежде чем появятся первые улучшения, кто-то должен заранее учесть ожидания клиента.
Мне очень нравится ваш список.Я думаю, у вас есть отличный план атаки для начала.
Я бы посмотрел с прицелом на стандартизацию либо на Spring, либо на EJB 3.0, но не на оба варианта.
Я сам ее не читал, но мне интересно, есть ли книга Майкла Перса "Эффективная работа с устаревшим кодом" есть какие-нибудь хорошие идеи?
Обновить:
Возможно, вы сможете помочь, внедрив автоматизированную сборку и непрерывную интеграцию - Cruise Control, Hudson или Team City.Если вам нужно провести какой-либо рефакторинг, это поможет.