Понимание и изменение крупных проектов

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

Там есть замечательная книга под названием Эффективная работа с устаревшим кодом от Michael Feathers. Там более короткая версия статьи здесь.

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

Из приведенной статьи резюме его стратегии:

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.

Ответ 3

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

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

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

также:

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

Вы должны проверить java-source для более открытых исходных проектов.

Ответ 7

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

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

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

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

Ответ 8

Вот несколько рекомендаций

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