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

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

Нету их в этом мире.

Стараться надо, чтобы были :)

Нету их в этом мире.

хороший != идеальный

Вот идеальных нет. А хороших достаточно много.

Я уже нашел. Всё это слабое подобие великого и могучего DXR: https://dxr.mozilla.org

Буста у нас нет, но со скоростью парсинга бустокода в ходе _компиляции_ у clang не наюлюдается => и в ide он тормозить не должен. Насчет утечек - если что, через неделю oom-killer прибивает процесс clangbackend и все начинается с чистого листа :)

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

Вот что ты за уету продолжаешь нести? Смотри что спрашивает топикстартер и о чём вообще этот топик:

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

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

Рекурсивно ищу всё, что связано с тем, что мне нужно.

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

И что?

Удачи открыть в IDE Gimp, Inkscape и иже с ними.

Что мешает открыть это всё в qtcreator, например?

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

Подтверждаю, знаю много народа, которые разрабатывают ядро в QtCreator и VisualStudio.

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

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

shell + grep + make + doxygen + ltrace + strace + lsof + fuser + gdb + ... --- это тоже ide с удобным текстовым вводом-выводом.

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

++

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

Ты не поверишь

но в «о вреде гоуту» есть место о причинах сложности «изучение исходники»

http://hosting.vspu.ac.ru/~chul/dijkstra/goto/goto.htm

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

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

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

Ну если goto правильно готовится, то он не вызывает проблем. Но с остальным не могу не согласиться.

Qulinxao (простите если неправильно написал), вы снова в деле?

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

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

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

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

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

Делаю нужные мне изменения и закрываю ide.

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

Пока нет бага не лезь в исходники, лучше заснуь...

Ну вот, очередной junior придурок будет всем рассказывать что и когда нужно делать с чем-либо

есть старшие товарищи .... Помогает только ... старшие товарищи рядом

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

Также сложно предсказать side-эффекты исправления некоторого бага.

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

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

Распечатываю на ватман и читаю на унитазе, когда газеты нет под рукой.

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

Распечатываю, читаю в спокойной обстановке, выделяю важные места хайлайтером.

А, так вы батенька теоретик. Тогда с вами говорить не о чем.

К сожалению такие идеальные условия встречаются крайне редко. Если проект развивается, он имеет тенденцию периодически упираться в ограничения архитектуры, а при распространённом консервативном менеджменте вносить изменения в архитектуру достаточно непростая задача. Не у всех же Agile и перепроектирование по понедельникам :) полно идейных противников такого подхода к разработке.

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

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

Пример изменения с неизвестными side-effect'ами - у клиента используется клиентская программа с напрочь вколоченными короткими timeout'ами по tcp. Это исправить нельзя, так как это не наша зона ответственности. Изменения, фиксящие проблему с обработкой запроса другого клиента замедляют время самого длинного запроса на 20ms но при этом среднее время выполнения обычного запроса ускоряется на 30%. Изменение достигнуто работой нескольких команд, работающих над разными модулями. В итоге у клиента возникает сообщение о таймауте несколько раз в день, что является регрессией, клиент не слишком доволен.

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

Не у всех же Agile и перепроектирование по понедельникам :) полно идейных противников такого подхода к разработке.

и я - в первых рядах. я считаю, что аджайл в том виде, как он сейчас понимается - это прямой и надёжный путь к говнокоду. я сторонник тщательного архитектурного планирования и составления ТЗ по всем пунктам задачи.

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

а насчёт внесения ошибок - юнит-тесты решают такие вещи и это всё автоматизируется.

Не, речь идёт не о том, что 1 человек - 1 модуль, каждый модуль пишет команда, в которой работают и джуны и сеньёры и тимлид. И я ни разу не видел проблем от ротации людей раз в пару месяцев или полгода, по окончанию выполнения очередной задачи. Естественно задачи на человека будут более-менее однородными, просто модуль будет другой и другая команда. То есть собирал человек ядро пересадили его писать драйвер USB-устройства. Потом посадили фиксить багу в jni. Если человек умеет всё это делать, почему ему задачи не разнообразить? А то сидят люди годами и делают bitbake core-image-minimal...

1 человек - 1 модуль всё-таки правильнее. ну, для джунов это не всегда так. но для сеньоров однозначно.

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

молотком землю рыть

Речь не идёт о том, что давать человеку не свойственные ему задачи. Речь о том, что человек делает то, что он хорошо умеет но в рамках разных частей проекта. И ротация не каждый день, а через разумные периоды времени. На счёт юнит-тестов - они конечно хороши, но не заменяют полноценного тестирования. Так как unit-test - локальная вещь, а нужно ещё помимо этого много чего тестировать, и удаётся автоматизировать далеко не всё.

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

Модули часто не так просты. Например модуль VoIP и распознавания речи был такой в одном проекте, там команда была человек в 20, хотя и использовалось большинство готовых библиотек. И сеньёров было человек 5, джунов 12, остальные тестеры... и этих людей явно не хватало, был жуткий аврал, но найти кого-то было сложно... И это был не ключевой модуль, а так, вспомогательный.

модуль VoIP и распознавания речи

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

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

А разве он не делился в свою очередь на подмодули, а те еще на подмодули? Или это был монолитный файл, который пилили все 17 человек? :)

Нет, это была пара десятков .so, несколько демонов, всё плотно завязанное друг на друга. Своё внутреннее AP, архитектура и прочее. Но да, все пилили всё, так как там было разделение функциональное а не пофайловое.

Ну не знаю на счёт кучи, это один из сотен модулей, далеко не самый важный.

и что, это повод сваливать в кучу разные вещи и потом писать и отлаживать его вдвадцатером, толкаясь жопами?

https://github.com/ggreer/the_silver_searcher

Не, не видел чтобы толкались, там задачи были разные. Из того, что помню, там звук нужен был для диспетчеризации, и в основном боролись за разборчивость голоса. Распознавание нужно было для оперативного выполнения некоторых команд (снятие нагрузки с диспетчера), там заставляли угадывать небольшой набор слов разными голосами по тестовым данным (готовые звуковые файлы). Ну и вспомогательные задачи типа метрики. Для GSM и транкинговой связи было всё готово (другие модули и команды), оставалось только для VoIP запилить. Использовалось telepathy. Проблемы были все мелкие, но их было очень много. А кода было не слишком много.

если задачи разные - зачем всё толкать в один модуль? вопрос именно в этом.

С какой целью предполагается изучение?

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

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

вдоль и поперёк.

распечатываю на бумаге и читаю вслух, с выражением.

раскрашивая стрёмные места разноцветными маркерами.

Патчи по почте отправляете?

0) Изучаю документацию в случае её наличия.

1) Изучаю данные и что с ними делается, в том числе настройки конфигурации.

2) Если есть юнит-тесты, то изучаю их.

3) Открываю багзиллу и с помощью git/svn diff изучаю правки для багов и фич.