Как мне визуализировать структуру моего кода?

Ответ 1

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

Нет причин, по которым вам нужно использовать какой-либо стандартный метод визуализации, и вы можете использовать любой материал, который вам нравится. Бумага, доска, фотошоп, visio, powerpoint, блокнот: все это может быть эффективным. Нарисуйте диаграмму классов, объектов, методов, свойств, переменных - все, что вы считаете полезным для просмотра, чтобы понять приложение. Аудитория - это не только другие члены вашей команды, но и сами. Создавайте диаграммы, которые вам полезны для быстрого изучения. Поместите их вокруг своего рабочего пространства и посмотрите на них регулярно, чтобы напомнить себе об общей архитектуре системы, когда вы ее создаете.

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

Ответ 2

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

Обычно вы хотите подумать об этом несколькими способами:

• Используйте свой мозг. Кто-то еще упомянул об этом - нет никакой альтернативы тому, чтобы на самом деле пытаться понять базу кода. Возможно, вам придется снять заметки и вернуться к ней позже. Могут ли инструменты помочь? Определенно. Но не ожидайте, что они сделают для вас большую часть работы.
• Найти документацию и поговорить с сотрудниками. Нет лучшего способа, чем некоторые источники описывают основные понятия в базе кода. Если вы можете найти кого-то, кто поможет вам, возьмите ручку и бумагу, идите к нему и возьмите много заметок. Сколько может быть ошибка другого человека? В начале - насколько это практично для вашей работы, но нет слишком мало.
• Подумайте о инструментах. Если вы новичок в части проекта, вы будете тратить значительное количество времени на понимание кода, поэтому посмотрите, какую помощь вы можете получить автоматически. Есть хорошие инструменты и плохие инструменты. Попытайтесь выяснить, какие инструменты имеют возможности, которые могут быть вам полезны в первую очередь. Как я упоминал выше, средний инструмент UML больше ориентируется на моделирование и, похоже, не подходит вам.
• Время против стоимости: Конечно, бесплатно здорово. Но если бесплатный инструмент не используется многими людьми, возможно, этот инструмент не работает. Есть много инструментов, которые были созданы так же, как и исследование того, что можно было сделать, но они не очень полезны и поэтому просто становятся доступными бесплатно в надежде, что кто-то еще примет его. Еще один способ подумать об этом, решить, сколько стоит ваше время - может быть, стоит потратить день или два, чтобы заставить инструмент работать для вас.

После этого помните об этом, пытаясь понять проект:

• Mile High View: многоуровневая архитектурная диаграмма может быть очень полезной для понимания того, как основные понятия в проекте связаны друг с другом. Инструменты вроде Lattix и Architexa может быть действительно полезен здесь.
• Ядро. Попробуйте выяснить, как работает код в отношении основных понятий. Здесь полезны диаграммы классов. Ручная работа работает достаточно часто, но инструменты могут не только ускорить процесс, но и помочь вам сохранить и поделиться такими диаграммами. Я думаю, AgileJ и Architexa - ваши лучшие ставки здесь, но ваш средний инструмент UML часто может быть достаточно хорошим.
• Случаи использования ключа. Я бы предложил отслеживать по крайней мере один ключевой случай использования для вашего приложения. Вероятно, вы можете получить наиболее важные варианты использования от кого-либо из вашей команды, и вмешательство в это будет действительно полезно. Большинство IDE действительно полезны здесь. Если вы попробуете их рисовать, то диаграммы последовательности наиболее подходят. Для инструментов здесь я думаю MaintainJ, JDeveloper и Architexa - ваши лучшие ставки здесь.

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

Ответ 3

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

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

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

Не пытайтесь понять все приложение

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

Поверьте мне, когда я это скажу - разработчики с более чем 10-летним опытом надежного кодирования могут не понимать, как некоторые части приложения работают даже после работы над одним и тем же проектом более года (при условии, что они не являются оригинальными разработчиками), Они могут не понимать, как работает аутентификация или как работает управление транзакциями в приложении. Я говорю о типичных корпоративных приложениях с классами 1000-2000 и использую разные структуры.

Два важных навыка, необходимых для поддержки больших приложений

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

Есть два важных навыка, которые помогают им сделать это.

• Они могут анализировать влияние изменений, которые они выполняют при исправлении ошибки. Сначала они обнаруживают проблему, меняют код и проверяют его, чтобы убедиться, что он работает. Затем, потому что они хорошо знают язык Java и "достаточно хорошо", они могут определить, не сломает ли он какие-либо другие части приложения. Если нет, они сделаны.

• Я сказал, что им просто нужно подражать, чтобы улучшить приложение. Чтобы эффективно имитировать, нужно хорошо знать Java и хорошо понимать рамки. Например, когда они добавляют новый класс Action Struts и добавляют в конфигурацию xml, они сначала найдут подобную функцию, попытаются следить за потоком этой функции и понять, как она работает. Возможно, им придется настроить немного конфигурации (например, данные "формы" находятся в "запросе", чем в области "сеанс" ). Но если они хорошо знают рамки, они могут легко это сделать.

В нижней строке вам не нужно понимать, что делают все классы 2000, чтобы исправить ошибку или улучшить приложение. Просто поймите, что нужно.

Сосредоточиться на немедленной доставке

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

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

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

Когда вы что-то понимаете, пишете заметки или рисуете диаграмму модели/последовательности/данных.

Диаграммы

Хааа... мне потребовалось столько времени, чтобы упомянуть диаграммы:). Я начал с раскрытия, что я являюсь автором MaintainJ, инструмента, который генерирует графики последовательности выполнения. Позвольте мне рассказать вам, как это может вам помочь.

Большая часть обслуживания - найти источник проблемы или понять, как работает функция.

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

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

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

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

Два оговорки к моему аргументу выше

• Я упомянул, что добавление кода менее рискованно, чем изменение существующего кода. Поскольку вы хотите избежать изменения, у вас может возникнуть соблазн просто скопировать существующий метод и добавить к нему, а не изменять существующий код. Сопротивляйтесь этому искушению. Все приложения имеют определенную структуру или "единообразие". Не разрушайте его с помощью плохих методов, таких как дублирование кода. Вы должны знать, когда вы отклоняетесь от "единообразия". Попросите старшего разработчика проекта рассмотреть изменения. Если вы должны сделать что-то, что не соответствует соглашениям, по крайней мере, убедитесь, что оно локально для небольшого класса (частный метод в классе 200 строк не разрушит эстетику приложения).

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

Заключение

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

Ответ 4

Некоторые плагины, которые я знаю для Eclipse:

Architexa

http://www.architexa.com/

nWire

http://www.nwiresoftware.com/

Если вы хотите перепроектировать код, попробуйте Enterprise Architect

Ответ 5

Вы пробовали Google CodePro Analytix?

он может, например, отображать зависимости и свободен (снимок экрана с cod.google.com):

Ответ 6

JUDE Community UML использовалось для импорта Java, но это уже не так. Это хороший бесплатный инструмент.

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

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

Ответ 7

Вот не UML-инструмент, который имеет очень приятные функции визуализации.

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

http://www.moosetechnology.org/

Хорошо, вы можете использовать скрипты Smalltalk для отображения того, что вам нужно: http://www.moosetechnology.org/docs/faq/JavaModelManipulation

Здесь вы можете увидеть, как выглядит такая визуализация: http://www.moosetechnology.org/tools/moosejee/casestudy

Ответ 8

Вот еще один инструмент, который мог бы сделать трюк: http://xplrarc.massey.ac.nz/

Ответ 9

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

Ответ 10

Некоторые полезные инструменты, которые я использую -

StarUML (позволяет преобразовать код в диаграмму)

MS Visio

XMind (очень полезно для обзора системы)

Ручка и бумага!