Советы по пониманию огромного монолитного кода

Question

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

Обычно у меня есть блокнот и пытаюсь отследить шаги. Но переключение между пониманием кода и записью для меня не очень эффективно. Какие-нибудь советы?

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

Answer 1

Сначала ответьте на вопрос: что вы хотите сделать?

Возможные вопросы

1. вы хотите оценить/Архитектура ли?

2. Вы хотите исправить ошибку?

3. Внедрение новой функции?

Возможные подходы:

1. разжиться на некоторые инструменты статического анализа: Sonar, структура 101 являются примерами. Используйте их, чтобы получить обзор архитектуры.

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

3. Посмотрите на связанную функцию, найдите ее по имени и посмотрите, как они реализованы. Игнорируйте все детали, которые не относятся к задаче.

---- добавление в ответ на выпуск вопроса ----

Делая исправление ошибки в базе кода вы не знаете (и который, вероятно, не имеет экстенсивный автоматические тесты) всегда является рискованным делом.

Все еще я думаю, что общий подход, представленный выше, является целесообразным. Разумеется, он должен быть «защищен» испытаниями:

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

• сделать изменения. Это должно сделать предыдущие тесты зелеными

• выполнить ручные тесты, чтобы убедиться, что приложение работает по назначению.

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

Answer 2

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

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

Answer 3

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

Как только у вас есть базовая модель кода и какая-то идея о том, как разработчик подумал об этом, вы можете взять его оттуда. Всегда работал на меня :)

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

Answer 4

Я скептически отношусь к тому, что, если я ограничу свое понимание функцией/классом, где присутствует ошибка, я не буду уверен в моем исправлении.

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

вам не нужно понимать все, чтобы исправить одну часть.

Answer 5

Есть интересный SE Radio interview with "Pragmatic" Dave Thomas о коде Археология, только в этой теме.

Некоторые идеи, некоторые из этого разговора, некоторые из них не:

У вас есть доступ к репо VC? Каковы горячие точки, где произошло много изменений? Это дает вам подсказку о том, сколько времени было потрачено на разработку.

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

Есть ли трекер ошибок? Какие компоненты имеют большинство ошибок, это также говорит о том, где возникают проблемы (и, вероятно, там, где развитие было сконцентрировано из-за важности этой логики).

Хорошая среда ID делает отслеживание намного проще, так как вы можете перейти к определениям и обратно еще раз.

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

Answer 6

Там в нелинейном (вроде hackerish, вбок и по общему признанию непрофессиональный) способ сделать это - добрейший из следовать хлебным крошки подхода:

• выбрать любую строку коды и не читать на до вы найдете какую-нибудь (скажем) функцию или класс , который привлечет ваше внимание;

• скопируйте его имя и отметьте блок комментарием («найдено: [имя вещи]», постепенно добавляя каждую вещь, за которой вы следуете);

• затем выполните поиск каждого экземпляра этого слова на протяжении всего кода;

• вы найдете фактическую «вещь» на пути , поэтому обратите внимание на строку, где отображается , и что она делает.

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

В худших случаях я также искал &, заменив все экземпляры слабо названных vars, подпрограмм и т. Д. На то, что делает более наглядным смыслом (затем снова запустите код).

Конечно (как говорит Павел), если вы используете редактор или IDE, который может перечислить определенный материал, вы уже на полпути :-)