Что наиболее распространенным способом понимания является очень большое приложение C++? [закрытый]

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

Как уже было сказано, возьмите doxygen и создайте HTML-документацию для исходного кода.

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

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

I'm not sure there is a standard way. There are some for-pay tools that will do C++ class diagrams/call graphs and provide some kind of code-level view. doxygen is a good free one. My low-tech approach is to find the top-level file and start to sort through what it provides and how...taking notes if needed.

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

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

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

Исправление ошибок отлично работает для любого проекта, а не только для C ++.

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

Вот как я подхожу к проблеме

• Начните с исправления простых ошибок. Будьте предельно внимательны к этим ошибкам и активно используйте отладчик, чтобы найти проблему.
• Код проверяет каждое изменение, вносимое в систему. В невероятно большой системе выберите меньшее подмножество и просмотрите все эти изменения
• И самое главное: задавайте много вопросов!

Во-первых, насколько большой размер?

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

Вы просто поддерживаете / исправляете его, когда что-то идет не так? Разрабатываете новый функционал? Переносите код на новую платформу? Обновление кода для нового компилятора C ++?

В зависимости от ваших требований я бы начал по-разному.

Попробуйте написать модульные тесты для различных классов.

Обычно очень полезно понимать, как используется код.

Если это библиотека, посмотрите клиентский код и модульные тесты. Если нет никаких модульных тестов, напишите несколько.

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

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

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

Вот мой общий процесс:

• Начните с понимания того, что делает приложение и как оно используется. (Я вижу, что слишком многие разработчики полностью пропускают этот важный шаг.)
• Найдите любую документацию для разработчиков, связанную с проектом. (Однако знайте, что это почти всегда будет неправильным и устаревшим - это просто будет иметь полезные подсказки.)
• Попытайтесь выяснить логику в организации. Как определяется основная архитектура? Какие крупномасштабные узоры используются? (например: MVC, MVP, IoC и т. д.)
• Попытайтесь выяснить основные классы, относящиеся к «большим» объектам в проекте. Это помогает в вышеупомянутом пункте.
• Медленно начинайте рефакторинг и очистку, пытаясь поддерживать проект.

Обычно это помогает мне хоть немного ускориться. Однако,

Что нужно сделать:

• Посмотрите, что говорится в рекламной брошюре вы это делаете, установите рамки своих ожиданий
• Установите его, какие параметры у вас есть в установщике, прочтите руководство по быстрому запуску / установке
• Узнайте, что он делает, выполняет ли он даже, есть ли у вас несколько исполняемые файлы
• Есть ли руководство по установке / вики для разработчиков, указатели на VCS
• Получите код и заставьте вашу среду сборки работать, документируйте SDK, инструменты сборки, которые вам нужны, если они еще не были
• Посмотрите на процесс сборки, зависимости проекта, есть ли машина сборки / служба CI
• Посмотрите на сгенерированный вывод документации (если есть!)
• Найдите интересную часть решения и посмотрите, как оно работает, каковы точки входа / как это работает / ищите основные классы и интерфейсы
• Реплицируйте ошибки, остановитесь на интересных функциях программы, чтобы получить обзор и перейти к трассировке кода.
• Начните исправлять ошибки, но убедитесь, что вы исправляете их, имея соответствующие модульные тесты, чтобы показать, что он неисправен сейчас и когда он будет исправлено.

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

1. Ударьте разработчиков, которые работали над этим. Жаль, что они не сделали чего-то столь же простого, как диаграммы классов UML.
2. Попробуйте сгенерировать их из кода. Они не будут точными, но дадут вам фору.

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

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

Помимо этого, вы можете попытаться понять код, прочитав его:

• Начните с файлов заголовков (.h / .hpp), их чтение поможет понять «интерфейсы» между классами
• Если в решении есть несколько проектов, которые попытаются понять ответственность каждого проекта.
• Найдите кого-нибудь, кто знаком с проектом, который может дать вам обзор, 5 минут с нужным человеком могут сэкономить вам час с отладчиком

Вы можете попробовать запустить его через doxygen, чтобы наконец получить доступный для просмотра набор документации, но в основном Единственный способ - это отладчик, несколько сообщений trace / std :: cerr и много кофе.

Предложение о написании тестовых примеров является основой Working-Effectively-Legacy-code и точкой библиотеки тестов cppunit. Если вы можете использовать этот подход, это зависит от вашей команды и ваших настроек - если вы новый юниор, вы не сможете переписать приложение для поддержки тестирования.

В C ++ наиболее распространенной проблемой является то, что много энергии и времени тратится на задачи низкого уровня, такие как «управление памятью».

Простые вещи в управляемых языках - это боль в C ++.