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

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

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

На это есть старшие товарищи и review.

Это только дополнительные меры, на которые нельзя полагаться даже если они есть 100% времени.

Если нет - работающий говнокод тоже сойдёт.

Нет, если ты не _убедился_, что он действительно 1. фиксит проблему 2. не ломает другое.

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

Я и не предлагал.

Так же как и разборки с архитектурой. Если есть локальная задача - её и нужно делать локально.

Только нужно при этом разобраться во всем, что вокруг конкретной локальности. Опыт наблюдения за всякими джунами/мидлами показывает, что говнофиксы очень часто и растут с «нашел решение, вроде подходит - коммичу» без осознавания всего механизма возникновения проблемы и всех цепляемых таким <фиксом> execution flow. Аналогично и с новым функционалом. А code review от такого очень часто не спасает, ибо он не панацея.

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

хз, я его использовал уже настроенным и установленным

Судя по поведению, оно создает индексную базу (как ctags или cscope), и во время этого как раз и «кушает сильно много». А в работе вполне себе шустро, мне понравилось. По сравнению с интегрированным в vim cscope использовать opengrok намного удобнее и приятнее. Значительно быстрее разбираешься что к чему.

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

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

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

Там можно посмотреть на OpenGrok, натравленный на исходники LibreOffice:
http://opengrok.libreoffice.org

Нет, если ты не _убедился_, что он действительно 1. фиксит проблему 2. не ломает другое.

Конечно, на это есть тестовый чеклист для джунов. Заленился - бьют ногами по лицу. Всё равно shit happens и ошибки вносятся с фиксами, на это есть более плотное регрессионное тестирование, но smoke test обязан выполнить каждый. Да, и джун обязан хорошенько обосновать что он там понаделал в коммите и зачем, иначе оно застрянет на review. Джунов нельзя без review. Они же джуны.

говнофиксы очень часто и растут с «нашел решение, вроде подходит - коммичу» без осознавания всего механизма возникновения проблемы и всех цепляемых таким <фиксом> execution flow.

А как же он научится? Как осознание появится? Оно появится только если кто-то сбоку пнёт. Нет ни одного более-менее крупного проекта без таких проблем. Избежать этого можно только тогда, когда джуны перестануть быть джунами и их не бует в проекта, то есть возможно и никогда.

Когда откровенно чувак не протестировал и заслал «фикс» не потестив, его пару раз побьют не сильно, не задев жизненно важные органы, он осознает и будет более внимательно фиксить. Ведь понимаешь, ему в одно ухо манагер орёт «где фикс? уже неделю назад должен был быть!» (задание дали только вчера) а тут коллеги со своими тестами... Не зря вон во многих местах каждый сидит играется неделю в своей песочнице, а в пятницу мержат, и на выходных сидят фиксят результаты.

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

Я не говорю о том review, который QA в одной известной конторе, всё можно довести до маразма, я про нормальный ежедневный review senior'ов над junior'ами. Ведь на так сложно разок в день глянуть коммиты джуна в спецбранч и поругаться. Когда мерджишь его бранч - разделяешь с ним и баги. Если регрессионное тестирование говорит что вы с ним козлы - воспринимаешь это как повод для саморазвития.

Если в проекте есть нормальная документация, это кратчайший путь к успеху. Прямо удивительно, что никто про это еще не сказал.

пофиксил, не благодари

Хороший, как в техническом, так и административном плане проект

Вы сейчас правда про реальный опенсорс говорите? Или опять про проприетарный теоретический (на практике он иногда ещё хуже бывает) ынтерпрайз, как товарищи выше?

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

Qt Creator тянет

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

Такое ревью ничего не покажет. Если в нормальный фикс/фичу входило посмотреть вокруг, понять и поменять _если надо_, то ревью не обнаружит проблем. Разве что тратить прилично времени самому делая это всё по второму кругу.

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

Берёшь бутылку из-под колы, шоколадку с фольгой...

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

если файлов 10-20 - это ещё можно. но когда их 50-100 и больше - уже однозначно надо делить.

Документация не помогает изучить код. Как справочник по API и какому-то высокоуровневому поведению — да, конечно, но не код, не потроха.

А тесты — входная точка в код, по ним можно прямо проследить основные потоки выполнения от входных данных до ожидаемых выходных.

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

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

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

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

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

то есть, самого браузинга по коду там нет, как я понимаю?

в этом плане lxr удобнее. там можно лазить по дереву кода и искать.

Документация не помогает изучить код.

отправным пунктом в изучении кода является понимание что/зачем делает ПО. И для этого следует заглянуть в первую очередь в документацию. Ну и да, видов документаций бывает много, но даже если в проекте имеется «справочник по API и какому-то высокоуровневому поведению» - это УЖЕ дает некоторое представление чем занимается программа.

Ты во всех тестах видел описание «что» и «как» мы тестируем? Без этой информации хрен ты поймешь что происходит. Даже если такая информация присутствует, будет крайне сложно понять «почему именно так», т.к. нигде не описано ожидаемое поведение тестируемого субъекта.

А тесты — входная точка в код, по ним можно прямо проследить основные потоки выполнения от входных данных до ожидаемых выходных.

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

typedef struct {
	void *a;
	void *b;
	void *c;
} testdata;

bool test_something() {
	testdata data;

	do_something(&testdata);
	if (memcmp(a, b, strlen(c)) == 0) return true;
	return false;
}

то есть, самого браузинга по коду там нет, как я понимаю?

Омг, в смысле «нет»? Там как раз что ни на есть «браузинг», и именно по коду.

Документация может устареть. Тесты - нет (при наличии CI конечно же).

Не пробовал. С clang-code-model? Сколько ресурсов жрёт?

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

Вы сейчас правда про реальный опенсорс говорите? Или опять про проприетарный теоретический (на практике он иногда ещё хуже бывает) ынтерпрайз, как товарищи выше?

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

Документация может устареть. Тесты - нет (при наличии CI конечно же).

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

Иначе ССЗБ.

Если разраб её не поправил, то ревью оно в теории пройти не может.

В мире молочных рек и кисельных берегов.

Считается, что тебе что-то нужно (по аналогии с cscope), потому ты в первую очередь вбиваешь что-то в поиск. А файлы посмотреть можно в результате поиска, там же и просто попрыгать по каталогам: http://opengrok.libreoffice.org/xref/core/

В мире адекватных разрабов и минимальной грамотности.

Поправил, не благодари.

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

как он умеет выводить списки

там, скорее, удобнее начать с поиска нужного идентификатора. Если такового на примете нет, можно поискать по имени файла (hxx или cxx — на первый раз подойдут), зайти в файл, пощёлкать по идентификаторам и т.п. (xref).

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

Я не знаю как у тебя удобно «лазить» по коду, но у меня это обычно происходит так:

1) Ищу интересующий символ (процедуру, функцию, переменную) или константу по имени или частир
2) Смотрю что имеется в результатах
3) Выбираю интересующее, в результате чего открывается файл на нужной строке
4) Изучаю участок. Все символы (процедуры, функции, переменные, константы) в открытом файле - ссылки, на которые можно клацать, и опять переходить в поиск, из которого можно находить как использования символа так и декларации, а также его определения.

Это вы про себя?

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

Нарциссизмом не страдаю.

то есть, самого браузинга по коду там нет, как я понимаю?

Омг, в смысле «нет»?

Где там исходный код? По твоей ссылке только (убогая) форма для поиска по коду.

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

Ясно, я понял в чём дело. Просто метод поиска отличается от задачи.
Когда у тебя в трекере висит задание «сделать чтобы фича зашибись() снова работала», то обычно тебе всё равно в каком файле реализована «зашибись()», и вообще наплевать на дату изменения.

читай выше, неадекват

структуру проекта, на модули, распределение по каталогам. смотрю, какие файлы автор правил последними и где идёт активная переделка кода

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

Ставлю assert и printf, где считаю нужным, и запускаю.

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

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

Да, тестов много всяких видов. Все, что покрывает поведение более одной функции, обычно полезно для изучения.

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

Ну сразу же видно, что твои «какие угодно тесты» не какие угодно, а разные сорта одного и того же.

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

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

/xref же.

Или даблкликнуть в списке справа.

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

Про любой хороший проект

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

С clang-code-model?

да

Сколько ресурсов жрёт?

свежая сессия ест метров 700, при длительном использовании может разжираться

Тесты при наличии ci не устаревают, потому что иначе они валятся

В реальном мире эта конструкция быстро обрастает черными списками и пометками тестов как «flaky»