2009-11-08 3 views
4

Это, кажется, популярная жалоба на многих форумах программистов, поэтому я не удивлюсь, если бы этот вопрос уже был здесь. Извините, если он уже был дан ответ, но я искал и не смог найти тот, который относится к Java/OO.Оптимизация и редизайн существующего приложения

У меня есть несколько сложное приложение, которое было написано несколько месяцев назад. Он работает хорошо, но медленный, и код чрезвычайно уродлив. Классы разделяются без логической причины, половина пользовательского интерфейса находится в логическом коде, и это действительно расстраивает. Я хочу перепроектировать и переделать эту программу на правильные стандарты дизайна, но я не хочу ее полностью разрушать. Нет никаких проектных документов, документации, ничего, кроме кода (без форматирования) и встроенного приложения.

Каков наилучший способ использования существующего Java-проекта, написанного наиболее раздражающим образом и перепрофилирования его наилучшим образом? Есть ли хорошие инструменты, которые помогут мне найти узкие места в скорости или для обширного тестирования в NetBeans? Любая помощь для полного новичка тестирования была бы весьма признательна.

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

+2

Вы меня заставили «хорошо работать» - не трогайте его :-) – ChssPly76

+0

+1 к ChssPly. «Если он не сломался, не исправляйте его». Если у вас есть код, который «не работает», возможно, вам следует сначала поработать над этим? –

+0

«пару месяцев назад»? Роскошь! –

ответ

3

«без форматирования»

Netbeans имеет опцию автоматического форматирования в меню «Источник». Это будет хорошим началом.

«Там нет проектной документации, никакой документации, ничего, кроме кода»

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

Использование JUnit для добавления некоторых тестов Unit в разделы, прежде чем вы реорганизовать их, также не повредит.

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

Старт небольшой. Выработайте несколько простых вещей, которые можно было бы лучше спроектировать и сосредоточиться на них в первую очередь. Использование функции Refactor в Netbeans очень поможет. Сосредоточьтесь на том, чтобы убедиться, что все, что вы реорганизуете, по-прежнему работает одинаково (вот почему начинаются небольшие подсказки). Чем больше мелких вещей, которые вы очищаете, тем легче будет больше, когда вы придете к нему.

Также убедитесь, что вы рефакторинг на самом деле улучшение ...

+0

«Начать мелкий» - и только укусить столько, сколько вы можете пережевывать * работает плохо * лучше, чем * не работает вообще * и, так же весело, как и сделать код довольно (я не могу стоять почти весь код/​​проекты, которые я вижу :-), функциональные возможности (и ресурсы, необходимые для их удовлетворения) - это то, что считается. – 2009-11-08 06:05:05

+0

+1 для модульных тестов, но я бы также распространил это на тесты на системном уровне (черный ящик), особенно если сразу не ясно, что должно делать приложение. –

0

Действительно единственный ответ пота справедливости, но некоторые вещи, которые могут помочь:

  • Хороший IDE с инструментами рефакторинга, такие как инструменты покрытия Eclipse
  • Profiling tools for optimization
  • кода, такие как EclEmma
  • Javadoc, иногда это помогает получить представление высокого уровня даже с плохим кодом

Счастливый рефакторинг!

1

Я хотел бы повторить комментарии С. Росса и добавить эти стратегии для обычных «плохой код» сценариев я имел дело в прошлом:

  • Код Дублирование: Единственное, что хуже, чем плохой код это несколько копий одного и того же плохого кода. Ознакомьтесь со всей базой кода, быстрочитая ее (получите ее вкус) и определите примеры кода для вырезания и вставки. Повторите эти действия для одной реализации и удалите дублирование. Возможно, это возможно - или вы можете продолжить уточнение одной копии этого кода.

  • Не спешите его исправить: Только очищайте код, который вам необходимо поддерживать и/или понимать. Это вариант , если он не сломался, не исправляйте его Мне нравится звонить , если вам не нужно его менять, не исправляйте его. Но в любое время, когда вам нужно прикоснуться к кусочку кода, потребуется еще 10 минут, чтобы очистить его. Возможно, это просто добавление форматирования, добавление некоторых встроенных комментариев, переименование переменных, чтобы иметь смысл, и т. Д. Любой код, который вам нужно обновить, скорее всего, снова будет повторен в будущем, и теперь вы сделали его чистым. Код, который вам еще не нужно было менять, может остаться уродливым, не навредив чему-либо.

Удачи :)

0

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

1

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

Будучи прагматичным, я бы с:

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

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

И, конечно, когда вы пересматриваете часть кода, просто очистите его своей любимой IDE.

0

JProfiler отлично, я использовал его только вчера на самом деле, чтобы найти узкое место производительности в каком-то Java-коде, который у меня был.

Если вы можете получить некоторые автоматические тесты на месте, вы будете в лучшем положении, чтобы начать рефакторинг, как вы можете, тогда assetr, что он все еще функционирует, как ожидалось. В частности, вы должны сосредоточиться, я думаю, на очень высоком уровне тестирования системы, если это веб-приложение, посмотрите на selenium и/или другие веб-приложения для тестирования.

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

Смежные вопросы