Понимание и изменение больших проектов

Question

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

80% классов имеют неполную / отсутствующую документацию.Остальные 20% - это те, которые формируют API общего назначения для инструмента.Один месяц чтения кода помог мне понять основную архитектуру.Но я не смог выяснить, какие именно изменения мне нужно внести в мой проект.Однажды я начал изменять часть кода и вскоре сделал так много изменений, которые уже не мог вспомнить.

Мой друг предложил мне попытаться записать иерархию классов.Есть ли лучший (стандартный?) Способ сделать это?

Answer 1

• проверка кода в некотором хранилище исходного кода (Subversion, CVS, Git, Mercurial ...)
• убедитесь, что вы можете собрать проект из исходного кода и запустить его
• если у вас уже есть приложение, использующее этот инструмент с открытым исходным кодом, попробуйте удалить двоичную зависимость и ввести зависимость проекта в eclipse или любой другой IDE. запустите свой код и выполните код, который хотите понять
• после каждого небольшого изменения
• если у вас разные идеи, ответьте на код

Answer 2

Есть замечательная книга Майкла Перса под названием Эффективная работа с устаревшим кодом . Более короткая версия статьи здесь .

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

Из ссылки на статью, краткое изложение его стратегии:

1. Identify change points
2. Find an inflection point
3. Cover the inflection point
   a. Break external dependencies
   b. Break internal dependencies
   c. Write tests
4. Make changes
5. Refactor the covered code.

Answer 3

Две вещи, которые Eclipse (и другие IDE) предлагают, чтобы «бороться» с этим.Я использовал их в очень больших проектах:

• Иерархия вызовов - щелкните правой кнопкой мыши метод и выберите «Иерархия вызовов» или используйте сочетание клавиш CTRL + ALT + H. Это дает вам все методыкоторый вызывает выбранный метод, с возможностью проверить дальше вниз по дереву.Эта функция действительно очень полезна.

• Иерархия типов - см. Иерархию наследования классов.В затмении это F4 или CTRL + T.

Также:

• найдите способ внести изменения, чтобы изменения вступили в силу при сохранении, и вы ненеобходимо заново развернуть
• с помощью отладчика - запустить в режиме отладки в среде IDE, чтобы увидеть, как протекает поток

Answer 4

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

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

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

Answer 5

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

Кроме того, если в вашем проекте есть юнит-тесты (считайте, что вам повезло), просмотрите юнит-тесты модуля, на котором вы сосредоточены. Это поможет вам понять, что модуль должен делать.

Answer 6

Вот пара рекомендаций

• Получить код в какой-либо форме CVS. Таким образом, если вы начнете вносить изменения Вы всегда можете оглянуться на предыдущую версии.
• Потратьте время, чтобы задокументировать, что вы уже выучил / прошел. Javadoc в порядке для этого.
• Создайте структуру UML для вашего кода. Существует множество плагинов, и вы получите хорошее представление о вашем коде.

Answer 7

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

Я предлагаю вам выполнить обратный инжиниринг кода с помощью инструмента моделирования, чтобы вы могли генерировать некоторые UML-модели из существующего исходного кода. Эти диаграммы могут быть полезны в качестве графического руководства при анализе кода.

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

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

Answer 8

Единственный способ понять код - это прочитать его. Продолжай работать, это мой совет.

Есть проекты с лучшей документацией, чем другие. Вот несколько хорошо организованных проектов: Tomcat , Причал , Хадсон

Вам следует проверить java-source , чтобы узнать больше проектов с открытым исходным кодом.