Какие инструменты или методы полезны для описания незнакомой кодовой базы? [закрыто]

При ручной проверке незнакомого кода (для просмотра или изменения) у меня, кажется, есть три варианта.

• Сверху вниз читать кода, выбирая каждый следующий исходный файл, как основополагающий имя файла , кажется. Я обычно заканчиваю тем, что читаю почти все. Несколько файлов дважды.
• Ширина первого чтение , где найти и прочитать все методу вызывающей с минимальным пониманием. Затем прочитайте все функции, которые были вызваны, и так далее. Мой умственный стек имеет тенденцию переполняться, если я сделаю несколько глубоких звонков.
• Глубины первого чтения , где я шаг через весь код в отладчике, не зная, будет ли это займет 8 минут или 8 часов.

После того, как я прочел достаточно кода, чтобы иметь достаточно четкое представление о том, что он делает, я часто вспоминаю, что прочитал 80% или более кодовой базы, в то время как основной код составляет 20% или менее . Я потратил много времени.

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

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

• VisualStudio может автоматически генерировать диаграмму классов UML для базы кода. По крайней мере, он покажет вам иерархии классов.
• Doxygen может быть чрезвычайно полезным. Даже если в коде нет комментариев в стиле doxygen, doxygen может генерировать читаемую документацию, диаграммы классов и графики вызовов, которые могут быть очень полезны для поиска незнакомой базы кода.

Как правило, вы также хотите использовать полнофункциональную среду IDE, в которой вы можете щелкнуть правой кнопкой мыши что-нибудь и «перейти к определению». Это может сэкономить вам много времени по сравнению с использованием grep для большого количества файлов в сложной структуре каталогов.

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

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

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

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

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