Как разобраться в проекте?

1. Хорошо бы иметь человека, которому задавать вопросы.

2. Разбираться в тех частях проекта, которые нужны прямо сейчас (например, фикс багов).

3. Изучать юнит-тесты.

4. Автоматически нагенерить всяких схем.

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

4. Автоматически нагенерить всяких схем.

Можно, конечно, попробовать, но проект написан в довольно странном стиле.

Читаю код. Если это программы, то с main, если библиотека, то с интересующих меня интерфейсных функций. Читаю бегло, пропускаю много «воды», сосредотачиваясь на последующих вызовах функций, т.е. строю в голове что-то вроде вероятного дерева вызова функций, стараясь понять в общих чертах их назначение (часто понятно по имени и/или комментариям). Проглядев main, перехожу к наиболее интересной вызываемой ею функции и т.д. Как правило, всю мелочь вроде более детального понимания работы условий и циклов можно рассмотреть чуть позже, собрав в голове некоторый образ исследуемой функции и нескольких функций на одну вглубь «по стеку».

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

делаю local wiki по мере осознания кода

Составляешь схемы на листке бумаги?

Зачем такие крайности. Для начала загрузи проект в любую нормальную IDE.

doxygen в помощь

Инкрементирую doxygen. Желательно включать в наиподробнейшем режиме. Будет проще ориентироваться.

Идёшь глазами по коду, начиная с main() (если он есть), полезно ещё запуститься под отладчиком и пройтись по нужному функционалу.

читать код
радикальный метод,

Ну офигеть теперь. Всегда так делал, не понимаю, как это может не очевидным.

Не очевидно, что это наиболее эффективный способ. Совсем не очевидно

Где в моем сообщении написано «наиболее эффективный»? Но ты все же поведай мне про более эффективные способы.

поведай мне про более эффективные способы

Спросить знающего человека, почитать хорошо написанную документацию

почитать хорошо написанную документацию

Так-то да, но в моем случае это невозможно.

Спросить знающего человека

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

почитать хорошо написанную документацию

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

Месяца четыре назад попал в новый проект. 500К строк на Си и немного Си++. Ни одного живого человека, который бы знал как это работает (проект был заброшен пару лет назад). Сейчас худо-бедно представляю архитектуру в общих чертах. Что помогло:

• Прочитал всю доступную документацию (мануалы всякие, но там конечно были совсем общие моменты)
• Отвечал на вопросы коллег про то как оно работает и какие фичи умеет (это чисто по коду ползал, используя grep. Особо интересные моменты/последовательности вызовов записывал во freemind)
• Участвовал в портировании на новую платформу — собственно работа с кодом больше всего любопытных фактов принесла (тут я использовал ещё gdb — иногда из исходников совершенно непонятно как код себя ведёт в тех или иных условиях и тут лучше поотлаживаться в живую).

ИМХО Самый лучший способ — запустить это дело в отладчике и посмотреть кто кого дёргает, какие потоки работают, какими данными обмениваются итд. Там сразу всё будет видно: и стэки вызовов, и кто от кого наследуется, и в каком порядке всё это работает.

Майкл Физерс, «Эффективная работа с унаследованным кодом», глава 16 (и 17). Только что открыл эту главу, прочитал и понял, что каждый пункт я имел неудовольствие переоткрыть за четыре недели ада в том проекте, которым сейчас занимаюсь.

Короче, дело пацан говорит.

ИМХО Самый лучший способ — запустить это дело в отладчике и посмотреть кто кого дёргает, какие потоки работают, какими данными обмениваются итд. Там сразу всё будет видно: и стэки вызовов, и кто от кого наследуется, и в каком порядке всё это работает.

Говоря кратко, современные доксигены и графвизы могут показать control flow, но не data flow и не обоих вместе.

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

знаешь какой-нибудь другой способ?

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

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

Рисую карты разума (mind maps).