Які інструменти чи методи корисні для опису незнайомої бази коду? [зачинено]

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

• Зверху вниз читати коду, вибираючи кожен наступний вихідний файл, як основоположний ім'я файлу , здається. Я, як правило, читаю майже все. Деякі файли двічі.
• Ширина першого читання , де знайти і прочитати все методу викликає з мінімальним розумінням. Потім прочитайте всі функції, які функціонують, і так далі. Мій ментальний стек має тенденцію до переповнення, якщо я зроблю це на кілька дзвінків глибше.
• Глибини першого читання , де я крок через весь код в отладчике, НЕ знаючи, чи буде це займе 8 хвилин або 8 годин.

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

Які інструменти корисні для швидкого розуміння незнайомого коду? Чи є інструменти, які можуть дати «велику картину» критичного кодового шляху і дозволяють мені детально ознайомитися з деталями будь-якої однієї частини?

Найкраще, звичайно, це той, хто знає кодову базу, щоб пройти вас через неї. Якщо це не варіант, то є деякі інструменти, які можуть вам допомогти.

• VisualStudio може автоматично генерувати діаграму класів UML бази коду. Принаймні це покаже вам ієрархії класів.
• Доксиген може бути надзвичайно корисним. Навіть якщо в коді немає коментарів у стилі доксигену, доксиген все ще може генерувати читабельну документацію, діаграми класів та графіки викликів, що може бути дуже корисно для пошуку вашої незнайомої бази коду.

Як правило, ви також хочете використовувати повнофункціональний IDE, де можна клацнути правою кнопкою миші що завгодно і "перейти до визначення". Це може заощадити багато часу в порівнянні з використанням grep для безлічі файлів у складній структурі каталогу.

Ще одна важлива річ, залежно від того, як довго вам доведеться мати справу з кодом. Якщо є одиничні тести, то перегляньте тести. Якщо тестів немає, починайте їх писати. Сформуйте гіпотезу про те, що робить певний клас чи функція, і складіть тест, щоб перевірити його. Це вимагає великої дисципліни, але це прекрасний спосіб отримати відповіді про те, що відбувається в коді.

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

Мета цієї вправи - виявити відносини класу. Зробіть викидний клон проекту, а потім спробуйте ввести кілька класів у простори імен. Щоб заощадити час на повторних спробах, використовуйте деякі засоби обробки файлів Regex для автоматизації цієї зміни.

Це викличе багато помилок компілятора. У процесі виправлення цих помилок можна краще зрозуміти, як ці класи залежать один від одного, і вирішити, які класи можна розмістити в одному просторі імен.

Ця методика корисна тим, що її можна застосовувати навіть при невеликому розумінні кодової організації проекту. Завдяки цьому виникає ризик, що деякі класи можуть бути неправильно замінені цією технікою через нерозуміння.