Как мне визуализировать структуру моего кода?
У меня есть приложение, написанное на Java. В хранится в нескольких файлах. Он использует разные классы с разными методами. Код большой и сложный. Я думаю, что было бы легче понять код, если бы у меня была графическая модель кода (своего рода ориентированный граф). Существуют ли стандартные методы визуализации кода. Я думаю об использовании UML (не уверен, что это правильный выбор). Кто-нибудь может порекомендовать мне что-нибудь?
ДОБАВЛЕНО:
Я рассматриваю две возможности:
- Создание графика руками (явно).
- Создание графика в автоматическом режиме. Например, использовать некоторые инструменты, которые читают доступный код и генерируют некоторый график, описывающий структуру кода.
ДОБАВЛЕНО 2:
Было бы неплохо иметь что-то бесплатно.
10 ответов
Самый важный инструмент, который вы должны использовать, это ваш мозг, и он бесплатный.
Нет никаких причин, по которым вы должны использовать какой-либо стандартный метод визуализации, и вы можете использовать любой носитель, который вам нравится. Бумага, доска, фотошоп, Visio, PowerPoint, блокнот - все это может быть эффективным. Нарисуйте схему классов, объектов, методов, свойств, переменных - все, что вы считаете полезным для понимания приложения. Аудитория - это не только другие члены вашей команды, но и вы сами. Создайте диаграммы, которые будут полезны для вас, чтобы вы могли быстро их понять. Размещайте их в своем рабочем пространстве и регулярно просматривайте их, чтобы напомнить себе об общей архитектуре системы при ее создании.
UML и другие стандарты документации кода являются хорошим руководством для типов диаграмм, которые вы можете сделать, и информации, которую вы должны учитывать, включая. Тем не менее, это излишне для большинства приложений и в основном существует для людей, которые не могут нести личную ответственность за документирование без стандартов. Если вы будете следовать UML к письму, вы будете тратить слишком много времени на документацию, а не на создание своего приложения.
Я попытался использовать ряд инструментов UML и обнаружил, что возможности обратного инжиниринга в большинстве инструментов UML не помогли понять код. Они сосредотачиваются на потребностях проектирования, а возможности обратного инжиниринга часто заканчиваются тем, что они показывают огромные картинки с бесполезной информацией. Когда я работал над базой кодов Microsoft Office, я обнаружил, что использование ручки и бумаги более полезно, чем типичные инструменты дизайна / моделирования.
Обычно вы хотите думать об этом несколькими способами:
- Используйте свой мозг: кто-то еще упомянул это - ничто не заменит пытаться понять кодовую базу. Возможно, вам придется записывать и вернуться к нему позже. Могут ли инструменты помочь? Определенно. Но не ждите, что они сделают большую часть работы за вас.
- Найдите документацию и поговорите с коллегами. Нет лучшего способа, чем какой-либо источник, описывающий основные понятия в кодовой базе. Если вы можете найти кого-то, чтобы помочь вам, возьмите ручку и бумагу, подойдите к нему и сделайте много заметок. Насколько сильно багит другой человек? В начале - столько, сколько практично для вашей работы, но никакая сумма не слишком мала.
- Подумайте об инструментах: если вы новичок в части проекта - вы потратите значительное количество времени на понимание кода, поэтому посмотрите, какую помощь вы можете получить автоматически. Есть хорошие инструменты и плохие инструменты. Постарайтесь выяснить, какие инструменты имеют возможности, которые могут быть полезны для вас в первую очередь. Как я уже упоминал выше, средний инструмент UML больше ориентирован на моделирование и не подходит для вас.
- Время против стоимости: Конечно, бесплатно - это здорово. Но если многие люди не используют бесплатный инструмент, возможно, он не работает. Есть много инструментов, которые были созданы просто как исследование того, что можно сделать, но они не очень полезны и поэтому просто доступны бесплатно в надежде, что кто-то еще примет это. Еще один способ подумать об этом, решить, сколько стоит ваше время - возможно, имеет смысл потратить день или два, чтобы получить инструмент, который будет работать на вас.
Оказавшись там, имейте это в виду, когда будете пытаться понять проект:
- Mile High View: многоуровневая архитектурная схема может быть очень полезна, чтобы узнать, как основные понятия в проекте связаны друг с другом. Инструменты, такие как Lattix и Architexa, могут быть действительно полезны здесь.
- Ядро: попытайтесь выяснить, как работает код в отношении основных концепций. Диаграммы классов исключительно полезны здесь. Ручка и бумага работают здесь достаточно часто, но инструменты могут не только ускорить процесс, но и помочь вам сохранить и поделиться такими диаграммами. Я думаю, что AgileJ и Architexa - ваши лучшие ставки здесь, но ваш средний инструмент UML часто может быть достаточно хорошим.
- Ключевые варианты использования: я бы посоветовал отследить хотя бы один ключевой вариант использования для вашего приложения. Скорее всего, вы можете получить самые важные варианты использования от любого в вашей команде, и пошаговое выполнение будет действительно полезным. Большинство IDE действительно полезны здесь. Если вы попытаетесь их нарисовать, то диаграммы последовательности являются наиболее подходящими. Для инструментов здесь я думаю, что MaintainJ, JDeveloper и Architexa - ваши лучшие ставки здесь.
Примечание: я являюсь основателем Architexa - мы создаем инструменты, которые помогут вам понять и документировать код Java, но я постарался быть беспристрастным выше. Мое намерение состоит в том, чтобы предложить инструменты и варианты, учитывая, что именно на этом я сфокусировался как часть моей докторской диссертации
Хранится в нескольких файлах. Он использует разные классы с разными методами. Код большой и сложный.
Весь код Java, написанный за пределами школы, подобен этому, особенно для начинающего разработчика, начинающего проект.
Это старый вопрос, но так как он подходит к поисковым запросам Google, я добавляю здесь свой ответ, чтобы он мог быть полезен для будущих посетителей. Позвольте мне также раскрыть, что я являюсь автором MaintainJ.
Не пытайтесь понять все приложение
Позвольте мне спросить вас: почему вы хотите понять код? Скорее всего, вы исправляете ошибку или расширяете возможности приложения. Первое, что вы не должны пытаться сделать, это понять все приложение. Попытка понять всю архитектуру при запуске проекта заново просто ошеломит вас.
Поверьте мне, когда я говорю это - разработчики с более чем 10-летним опытом работы в области кодирования могут не понимать, как работают определенные части приложения, даже после работы над одним проектом более года (при условии, что они не являются первоначальными разработчиками). Они могут не понимать, как работает аутентификация или как работает управление транзакциями в приложении. Я говорю о типичных корпоративных приложениях с классами от 1000 до 2000 и использующих разные фреймворки.
Два важных навыка, необходимых для поддержки больших приложений
Тогда как они выживают и получают большие деньги? Опытные разработчики обычно понимают, что они делают; это означает, что если они хотят исправить ошибку, они найдут ее местоположение, затем исправят и убедятся, что она не нарушает работу остальной части приложения. Если им нужно улучшить функцию или добавить новую, в большинстве случаев им просто нужно подражать существующей функции, которая делает то же самое.
Есть два важных навыка, которые помогают им сделать это.
Они могут анализировать влияние изменений, которые они вносят при исправлении ошибки. Сначала они обнаруживают проблему, меняют код и проверяют его, чтобы убедиться, что он работает. Затем, поскольку они хорошо знают язык Java и достаточно хорошо знают фреймворки, они могут сказать, не нарушит ли он какие-либо другие части приложения. Если нет, они сделаны.
Я сказал, что им просто нужно подражать, чтобы улучшить приложение. Чтобы эффективно имитировать, нужно хорошо знать Java и понимать фреймворки "достаточно хорошо". Например, когда они добавляют новый класс Struts Action и добавляют в конфигурационный xml, они сначала найдут похожую функцию, попытаются проследить за ходом этой функции и понять, как она работает. Возможно, им придется немного изменить конфигурацию (например, данные "формы" находятся в "запросе", а не в области "сеанса"). Но если они знают рамки достаточно хорошо, они могут легко сделать это.
Суть в том, что вам не нужно понимать, что делают все классы 2000 года, чтобы исправить ошибку или улучшить приложение. Просто пойми, что нужно.
Фокус на доставке немедленной стоимости
Так что я отговариваю вас от понимания архитектуры? Нет, совсем нет. Все, что я прошу вас, чтобы доставить. После того, как вы запустите проект и настроите среду разработки на своем ПК, вам не нужно больше недели, чтобы доставить что-либо, каким бы маленьким оно ни было. Если вы опытный программист и ничего не делаете через 2 недели, как менеджер может узнать, действительно ли вы работаете или читаете спортивные новости?
Итак, чтобы облегчить жизнь всем, доставить что-то. Не соглашайтесь с тем, что вам нужно понимать все приложение, чтобы доставить что-то ценное. Это полностью ложно. Добавление небольшого и локализованного подтверждения Javascript может быть очень полезным для бизнеса, и когда вы его доставляете, менеджер чувствует облегчение, что он получил некоторую ценность за свои деньги. Более того, это дает вам время для чтения спортивных новостей.
Со временем и после того, как вы внесете 5 небольших исправлений, вы начнете медленно понимать архитектуру. Не стоит недооценивать время, необходимое для понимания каждого аспекта приложения. Дайте 3-4 дня, чтобы понять аутентификацию. Может быть 2-3 дня, чтобы понять управление транзакциями. Это действительно зависит от приложения и вашего предыдущего опыта работы с подобными приложениями, но я просто даю приблизительные оценки. Украсть время между исправлением дефектов. Не проси за это время.
Когда вы что-то понимаете, напишите заметки или нарисуйте диаграмму класса / последовательности / модели данных.
Диаграммы
Хааа... мне понадобилось так много времени, чтобы упомянуть диаграммы:). Я начал с раскрытия, что я являюсь автором MaintainJ, инструмента, который генерирует диаграммы последовательности времени выполнения. Позвольте мне рассказать вам, как это может помочь вам.
Большая часть обслуживания заключается в том, чтобы найти источник проблемы или понять, как работает функция.
Сгенерированные MaintainJ диаграммы последовательности показывают поток вызовов и поток данных для одного варианта использования. Итак, на простой диаграмме последовательности вы можете увидеть, какие методы вызываются для варианта использования. Так что, если вы исправляете ошибку, скорее всего, ошибка в одном из этих методов. Просто почините его, убедитесь, что он больше ничего не сломает и вылезайте.
Если вам нужно улучшить функцию, разберитесь в потоке вызовов этой функции, используя диаграмму последовательности, а затем улучшите ее. Улучшение может быть похоже на добавление дополнительного поля или добавление новой проверки и т. Д. Обычно добавление нового кода менее рискованно.
Если вам нужно добавить новую функцию, найдите какую-то другую функцию, аналогичную той, которую вам нужно разработать, поймите поток вызовов этой функции с помощью MaintainJ, а затем имитируйте ее.
Звучит просто? Это на самом деле просто, но будут случаи, когда вы будете делать более крупные усовершенствования, такие как создание совершенно новой функции или что-то, что влияет на фундаментальный дизайн приложения. К тому времени, когда вы пытаетесь что-то подобное, вы должны быть знакомы с приложением и достаточно хорошо понимать архитектуру приложения.
Два предостережения к моему аргументу выше
Я упоминал, что добавление кода менее рискованно, чем изменение существующего кода. Поскольку вы хотите избежать изменений, у вас может возникнуть желание просто скопировать существующий метод и добавить его, а не изменять существующий код. Сопротивляйтесь этому искушению. Все приложения имеют определенную структуру или "единообразие". Не разрушайте это плохими методами, такими как дублирование кода. Вы должны знать, когда вы отклоняетесь от "единообразия". Попросите старшего разработчика проекта пересмотреть изменения. Если вы должны сделать что-то, что не соответствует соглашениям, по крайней мере, убедитесь, что оно локально для небольшого класса (закрытый метод в классе из 200 строк не нарушил бы эстетику приложения).
Если вы будете придерживаться подхода, описанного выше, хотя вы сможете прожить в отрасли многие годы, вы рискуете не понять архитектуры приложений, что в долгосрочной перспективе не очень хорошо. Этого можно избежать, работая над большими изменениями или просто меньше времени на Facebook. Потратьте время, чтобы понять архитектуру, когда вы немного свободны, и задокументируйте ее для других разработчиков.
Заключение
Сосредоточьтесь на немедленной ценности и используйте инструменты, которые обеспечивают это, но не ленитесь. Инструменты и диаграммы помогают, но вы можете обойтись и без них. Вы можете последовать моему совету, просто уделив время старшему разработчику проекта.
Некоторые плагины, которые я знаю для Eclipse:
Architexa
nWire
Если вы хотите перепроектировать код, вы должны попробовать Enterprise Architect
Вы пробовали Google CodePro Analytix?
например, он может отображать зависимости и является бесплатным (скриншот с cod.google.com):
Вот не UML инструмент, который имеет очень хорошие возможности визуализации.
Вы можете отобразить строки кода для каждого класса / метода на цвет / длину прямоугольников. Вы также можете показать зависимости между классами.
http://www.moosetechnology.org/
Приятно то, что вы можете использовать сценарии Smalltalk для отображения того, что вам нужно: http://www.moosetechnology.org/docs/faq/JavaModelManipulation
Здесь вы можете увидеть, как выглядит такая визуализация: http://www.moosetechnology.org/tools/moosejee/casestudy
Сообщество JUDE UML раньше могло импортировать Java, но это уже не так. Это хороший, бесплатный инструмент.
Если ваше приложение действительно сложное, я думаю, что диаграммы не унесут вас слишком далеко. Когда диаграммы становятся очень сложными, они становятся трудными для чтения и теряют свою силу. Некоторых хорошо выбранных диаграмм, даже если они созданы вручную, может быть достаточно.
Вам не нужно прописывать каждый метод, параметр и возвращаемое значение. Обычно вам нужны только отношения и взаимодействия между объектами или пакетами.
Вы можете использовать инструмент JArchitect, довольно полный инструмент для визуализации структуры кода с помощью графа зависимостей, и просматривать исходный код как базу данных с помощью CQlinq. JArchitect бесплатен для участников с открытым исходным кодом.
Вот еще один инструмент, который может добиться цели: http://xplrarc.massey.ac.nz/
Некоторые замечательные инструменты, которые я использую -
StarUML (позволяет преобразовать код в диаграмму)
MS Visio
XMind (очень полезно для обзора системы)
Ручка и бумага!