Что вы дальше делаете?

Чай.

Дальше — отрезаешь дно бутылки.

дальше загружаешь сорцы в мозг и анализируешь в нем цепочки вызовов, отношения объектов (если есть) и прочия, потом все это кешируешь, второй раз будет проще, полное погружение дето минут 15, если мозг уже натренирован то меньше

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

grep-ом

Все не изучишь. Ищешь то что нужно, правишь, ставишь бряк, ...

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

Часто помогает косяк дунуть для начала

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

Это без мультитреда с eventloop'ом на каждое ведро. Тогда ты будешь иметь только очередь без вкяких call stack :)

В зависимости от целей и размеров проекта. Либо иду от main, ежели таковой есть, либо грепаю

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

Но у такого подхода есть трудности в случае использования каких нибудь ОБСЕРверов и прочего множественного наследования.

Исходники грепаются по нужному сообщению или другому признаку, ставятся соответсвующие debuginfo, запускается целевое по, аттачится дебаггер, брейк на нужное место, и он сам размотает всё до нужного места. Читать всё самому сложно и некогда обычно, и незачем. Если всё же надо читать (интересно стало), то гененерю тэги и открываю в vim.

Допустим скачали вы проект и открыли в ide

Где-то 90% проектов разрабатываются без IDE. Удачи открыть в IDE Gimp, Inkscape и иже с ними.

Я обычно сначала пытаюсь собрать проект, чтобы поставить все зависимости, читаю README, смотрю структуру каталогов, дальше ищу причину по которой я взялся за исходники, если это ошибка, как-то привязана к GUI (например при нажатии на кнопку что-то не то происходит), то смотрю файл перевода, затем ищу в файле перевода строку и файл с кнопкой, дальше ковыряю что она делает, пока не найду проблемное место, что далеко не всегда просто. Можно Grep-ом искать проблему, но я обычно Catfish использую для этой цели, т.к. быстрее, он сразу кликабельный список файлов дает.

Ну а если тупо структуру посмотреть надо, в виде зависимостей между классами, есть Doxygen, даже в проектах где он не используется он вполне в силах построить графы.

Допустим скачали вы проект и открыли в ide. Что вы дальше делаете?

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

Допустим скачали вы проект и открыли в ide.

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

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

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

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

дебаггер + брейкпоинты где надо

Где-то 90% проектов разрабатываются без IDE.

Откуда инфа?

Куча FOSS проектов на сишке вообще держит всё сорцы в корне.

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

doxygen хорошо для библиотек и всяких там API. Но для очень многих проектов что doxygen что lxr бесполезны, и нужно сидеть и раскручивать самому. Иногда помогают рантайм-тулзы типа valgrind или gcc introspection, но для большинства задач достаточно просто исходников и мозга. Не надо пытаться знать весь проект целиком, это не книга, которые читают от корки до корки, это скорее как словарь - нужно смотреть то что нужно по мере необходимости.

Откуда инфа?

Сей архитектор так все лабораторки пишет.

А ведь закупиться предварително надо, разве нет?

Ищешь то что нужно, правишь, ставишь бряк, ...

Так и рождаются говнокодеры. Что-то поправил, «вроде работает», пора коммитить. Нафиг вообще разбираться в коде - из каких мест вызывается, на что влияет и т.п...

Куча FOSS проектов на сишке вообще держит всё сорцы в корне.

И что из этого следует? В проекте с нарезкой директориями тоже рано или поздно встретится директория с сорцами. У файлов, кстати, тоже есть имена, их можно читать.

То, что зачастую по дереву файлов сложно что-то понять. Особенно, если у автора свои представления о логике.

Культура потребления, или

Для особых случаев всегда должно быть наготове.

То, что зачастую по дереву файлов сложно что-то понять. Особенно, если у автора свои представления о логике.

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

На это есть старшие товарищи и review. Если нет - работающий говнокод тоже сойдёт. Конечно полезно проверить что там где, но обычно с опытом интуиция подскажет. Просто бездумно читать исходники - бессмысленная трата времени. Так же как и разборки с архитектурой. Если есть локальная задача - её и нужно делать локально. Если нужно менять core API - тогда конечно, стоит посмотреть и подумать, но вряд ли такое дадут нашему ТС.

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

То же могу сказать и про тебя горе-ынтерпрайзник без единого проекта.

А где там должна быть ide? Вы про проектный файл? Ну так тот же cmake все умеют, с горем пополам, открывать. Это же касается и других языков.

Как люди работают без IDE - для меня загадка. Вижу только два варианта:

• наколенный проект из трёх строк
• гигант из миллионов строк (webkit), который IDE тупо не потянет

Всё остальное чисто закидоны, типа: мне вим ближе. А потом рефакторинг через grep + sed...

Вот я сижу без IDE для Rust и страдаю. Про плюсы вообще молчу.

Вот я сижу без IDE для Rust и страдаю. Про плюсы вообще молчу.

А почему опенсорсу так хреново? Вот именно по этому. И так не только с IDE, но и с библиотеками и прочим велосипедостроительством.

Ну так тот же cmake все умеют, с горем пополам, открывать.

Открывыать - умеют, так чтобы запустилось и стало работать - не умеют. Всё очень печально. Тот же Inkscape до недавних пор собирался при помощи отдельного велосипеда на C с классами. Ну перевели его пару месяцев назад на Cmake, вот только Cmake забагованным является (не сам Cmake, а конкретно их конфиг), до сих пор не умеет внятно писать чего ему не хватает, т.к. проверяет версии некоторых библиотек сразу кучей. У меня глубокие сомнения, что IDE что-то там сможет внятно открыть и собрать проект.

А почему опенсорсу так хреново? Вот именно по этому.

А он тут при чём? Я про любые проекты говорю. В ынтырпрайзе без java ide/msvs вообще никуда.

Тот же Inkscape

Inkscape вообще очень спорный проект. Как и cmake.

Мне от ide не сборка нужна, а индексация.

Я про любые проекты говорю.

Ну в любых - да, но ТС больше о опенсорсе.

Допустим скачали вы проект

Маловероятно что он исходники Skype имеет ввиду.

Inkscape вообще очень спорный проект. Как и cmake.

Весь опенсорс спорный. Линус уже начал использовать IDE для разработки ядра?

Линус уже начал использовать IDE для разработки ядра?

С каких пор он пишет код?

гигант из миллионов строк (webkit), который IDE тупо не потянет

Да сфигали. CDT тянет ядро и Firefox.

Помнится где-то читал, что разрабы chromium используют саблайм, ибо ide умирают на этом объеме кода.

Сам не проверял, у меня до 100к проекты, но IDEA, жрущая под гиг ОЗУ на Hello World как бы намекает на аппетиты.

В 2005 точно писал, тот же Git. А сейчас обленился и стал как Столлман? А вообще, это его коммиты?

Даже если он сам код не пишет, он всё равно его читает.

По-моему, кроме первых версий гита он так ничего и не писал.

И нет, это не его коммиты, о просто мерджит пулл-реквесты.

Как вы изучаете исходники?

Под пиво же.

А если серьёзно - не надо пытаться объять необъятное. Если я хочу что-то пропатчить - я ищу интересующий меня кусок и изучаю его. И да, для этого необязательна IDE, может и mcedit за глаза хватить.

Всю кучу исходников имееет смысл изучать перед тем, как затевать глобальный рефакторинг. Но я не знаю, зачем мне этим заниматься в ЧУЖОМ проекте. Если ты только хочешь подхватить проект, который автор давно забросил. Тогда - удачи.

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

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

Ну это всё конечно зависит от софтины, но если есть возможность воспользоваться рантайм тулзами, лучше делать именно это. По 99% проектов с которыми мне приходится работать, генерируемая документация очень ограниченно полезна, так как код изобилует callback'ами, что ломает логику doxygen. lxr чуть получше, но тоже совсем не помогает найти цепочки «что из чего вызывается». Помогают только gcc instospection, valgrind и печать backtrace'ов. valgrind кстати сетевые софтины не убивает, работает даже на коде, работающем с libusb (с небольшими ухищрениями).

И да, очень большие софтины исследовать valgrind'ом еще полезнее, даже бывает, что это единственный выход.

valgrind кстати сетевые софтины не убивает, работает даже на коде, работающем с libusb (с небольшими ухищрениями).

смотря какая нагрузка. например, в телекоме он был бесполезен. софт был не очень объёмный, но данных было много. valgrind выжирал 64 гига памяти, начинал дико тормозить и кернел его убивал. можно попробовать профилировать какие-то отдельные функции, но сложно. и с сетью или взаимодействием с каким-то железом всегда всё усложняется.

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

И да, очень большие софтины исследовать valgrind'ом еще полезнее, даже бывает, что это единственный выход.

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

Ну это всё конечно зависит от софтины, но если есть возможность воспользоваться рантайм тулзами, лучше делать именно это

Это означает что ты совсем не понимаешь что происходит в ПО и не поймёшь. Рантайм инструменты нужно использовать только для проверки «гипотез» вытянутых из чтения кода.

советую использовать opengrok

opengrok

Какая жесть.

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

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

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

Где-то 90% проектов разрабатываются без IDE. Удачи открыть в IDE Gimp, Inkscape и иже с ними.

Хороший, как в техническом, так и административном плане проект ничем не выдаст в чём его разрабатывают. Максимум только косвенно, по модлайнам в исходниках. Потому что в таком "хорошем" проекте исходники отдельно, сборочная система отдельно, интеграция и деплой отдельно, линтеры, стат. анализаторы отдельно, даже код-стайл отдельно энфорсится своими тулзами, так что текст писать можно в том, в чём удобно каждому разработчику, им всё равно не(льзя) выйти за рамки проектных политик, заданных лидером проекта. Размер исходников, причём здесь ортогонален, 1 МБ или 1 ГБ, если индексировалка, например, в QtCreator или CLion или любой другой среде у кого-либо из разработчиков это прожуёт, на здоровье. Если нет, рефакторьте sed-ом (а лучше вовсе не рефакторьте).