Как быстро понять дизайн и поток кода любого продукта?

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

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

Примечание. Я пробовал свои руки на Star UML и пытался перепроектировать диаграммы классов, чтобы у меня было четкое представление о внутренних конструкциях продукта, но он не удался.

РЕДАКТИРОВАТЬ: Вопрос заключается не в получении знаний о том, что делает продукт, а в том, как разрабатываются внутренние компоненты.

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

В словах Кита:

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

Ответ 1

Я инженер по контракту, и эта ситуация повторяется несколько раз в год - за последние несколько десятилетий.

Мне очень полезно сначала запустить приложение и поиграть с ним, прежде чем смотреть на любой код:

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

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

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

Таким образом, я нашел возможность хорошо понимать приблизительно 50 000 - 100 000 строк кода в день.

Ответ 2

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

Ответ 3

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

Ответ 5

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

Ответ 6

Есть инструменты, которые всасывают исходный код и рисуют рисунки. Попробуйте Enterprise Architect из Sparx. Он составляет менее 200 долларов США за место и очень эффективно покажет вам схему объекта.