Изучение устаревшей системы Java

Question

Мне поручено поддерживать и реорганизовывать устаревшую систему Java. В настоящее время я занимаюсь C# и .NET, хотя я знаком с Java.

Унаследованная система использует RMI, архитектуру клиент/сервер и предназначена для 1.4 JVM. Он использует для пользовательского интерфейса (насколько я могу судить), Swing и AWT.

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

Что вы делаете в ситуации, когда вам вручают незнакомую кодовую базу?

Спасибо!

-Jarrod

Answer 1

Первое, что я делаю с любым новым код, я передал это посмотреть на существующих модульных тестов. Написание новых тестов - это, как правило, второе.

Answer 2

Java 1.4 с RMI не является устаревшим, это практически новое по некоторым стандартам!

делать все, что вы можете сделать, чтобы ознакомиться с тем, где вещи - модульные тесты, трассировки кода/звонков, работать некоторые UML диаграмм и т.д.

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

Answer 3

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

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

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

public static int[] a (List<int[]> input){ 

    ... lots of opaque rubbish 
    return b(input); 
} 

public static List<int[]> b{ List<int[]> input) 
{ 
    ... more crap.... 
    return some horribly mangled list of int[]; 
} 

Как получилось, что Осуществлен для сортировки массивов по значению их второго элемента. Тестирование b вести себя должным образом было бы бесполезно в этом случае.

Предложения, чтобы помочь вам сохранить ваше здравомыслие:

• код удалить это явно не используется.
• Постарайтесь отчислить любые «магические числа»
• найти любые ссылки на файл, путь или ресурсы файла hardcode, а также разделить их на свойства или любой другой центральный, общий способ справиться с ними.
• попытайтесь выяснить, действительно ли приложение работает так, как это должно быть, - это не редкость для какой-то действительно сложной функции, что вы не можете заставить головы или хвост фактически представлять что-то, что пользователи чувствовали «никогда не работало правильно» ».
• Найти оригинальную документацию или спецификации с момента ее создания.
• Поскольку вы упомянули 1.4, обобщающие карты могут прояснить, какие объекты проходят. если у вас есть объект, поддерживаемый HashMap, и то, как он заполняется, является загадкой, он может действительно упростить вашу жизнь, чтобы определить, что это на самом деле карта строк для целых чисел - это часто намного легче понять, чем то, что на самом деле предполагается чтобы делать.

Конечно, большая часть этого не требуется, если код хорошо написан, но тогда ваша работа будет намного проще в любом случае. И удачи.

Answer 4

Первое, что я делаю при получении нового кода, - «попытаться заставить его работать»! Под этим я имею в виду:

• сначала установить его (как в установку заметки, если таковые имеются)

• тогда знакомиться с ним (прочитав инструкцию и запустить некоторые важные случаи использования)

• затем некоторые обратные техники, чтобы узнать основные слои. классы и зависимости

• тогда я могу думать о написании новых тестовых случаев (на уровне приема первой, которые будут полезны для регрессионного тестирования позже)

• тогда я отдадимся некоторые «проблемы» о добавлении этой функции (даже если это не требуется) или улучшить производительность существующей функции: это хороший способ выкопать в существующую кодовую базу

• Конечно, если есть некоторые известные ожидающие ошибки/RFE, я буду работать над эти первые

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

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

Answer 5

Построить и запустить это было бы моим первым делом. Начните понимать смысл проблемы, к которой он пытался обратиться.

Возможно, вы можете импортировать его в UML-инструмент, например JUDE, и получить представление о том, как взаимодействуют классы.

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

JDK 1.4? Это конец его поддержки. Я также хочу посмотреть, будет ли код строить и запускаться под JDK 5 как минимум, желательно JDK 6. Может быть, вы могли бы ударить несколько из этих тестов JUnit в JMeter и выполнить тест нагрузки на бедный человек с 5 одновременными пользователями.

Если у вас есть модель данных, потяните ее в ERWin и начните видеть, как столы, объекты и экраны текут вместе.

Answer 6

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

Если у вас есть возможность перейти на более новую версию Java, то обобщение всех коллекций поможет понять, какие типы данных передаются.

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

Редактировать: Думаю о моем ответе, также полезно включить все диагностические трассировки и протоколирование, использовать систему, а затем изучить журналы. Если трассировка протокола связи существует, то просмотр этой трассировки поможет понять коммуникационный протокол, используемый кодом, возможно, с трассировкой Wireshark того же теста.

Другой полезной миграцией является переход из старой библиотеки параллелизма в новую библиотеку параллелизма Java 5 (и 6). Это поможет вам понять, где находятся потоки и когда они запущены и когда они будут закрыты.

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

Answer 7

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

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

Answer 8

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

Используйте Netbeans для преобразования диаграмм классов инженеров.

Answer 9

Был разговор, на котором я присутствовал Майк Хилл, в котором он рассказал о процессе, который он использует для борьбы с плохим устаревшим кодом. Он назвал это «микротестированием», и это в основном изолирует каждую вещь, которую вы хотите протестировать (в своей собственной функции или в маленьком объекте), и записывая тесты вокруг нее. Эти тесты не означают утверждения вещей в бизнес-смысле - они предназначены только для того, чтобы зафиксировать состояние, в котором система оставлена ​​после выполнения тестируемых строк. Как правило, он утверждал, что переменные имели значения, которые они имели в отладчике. Естественно, эти тесты пройдут на начальном этапе, но после того, как он написали достаточно о них, у него будет эффективный снимок системы.

После того, как эти тесты были на месте, он мог бы начать рефакторинг этого фрагмента кода, чтобы попытаться понять, что он пытался сделать. Он мог сделать это безопасно, потому что его «микротесты» потерпели неудачу, если он изменил способ, которым функция (или объект) вела себя немного.Хотя это означало, что он не мог сделать большие изменения дизайна, он мог устранить много шума, и он мог получить представление о том, что делает система. Как только у него появилась четкая идея о том, что делает код, он может начать улучшать его, находить ошибки и т. Д.

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

Answer 10

Опыт показал мне, что у вас есть 3 основных цели при изучении устаревшей системы.

• Узнайте, что код должен делать
• Узнайте, как это делает их
• (самое главное) Узнайте, почему он делает их так, как это делает

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

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

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

При необходимости проведите тестовые примеры.

Не бойтесь спросить кого-то, кто знает, есть ли у вас вопрос. Разумеется, вы не должны тратить время других сотрудников на безумные запросы, но если есть что-то, что вы просто не понимаете (это особенно верно в отношении более концептуальных вопросов типа «Не было бы более целесообразным реализовать это как ___ "или что-то в этом роде), вероятно, стоит выяснить ответ, прежде чем вы что-то портете и не знаете, почему.

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