Анализ программного кода на примере проектов OpenSource

Может это подойдет? Не читал, не смотрел, руки не доходят.

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

дают мегапроект, надо в нем разобраться в достаточном объеме и начать искать да править ошибки

Я тебе не завидую. Это как соломинку же в стоге иголок искать!

Документации к коду нет %)

А это уже называется "поди туда, не знаю куда, сделай то, не знаю что"

git ls-files
git grep
grep -iR -5 "\bfoobar\b" sources/
find path/1 path/N -name *ext -exec grep -i -5 baz {} \;

и т.д. и т.п.

strace
gdb

Я тебе не завидую. Это как соломинку же в стоге иголок искать!

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

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

А мне нужно, чтобы человек научился искать проблемные места, делать более-менее анализ и диагностику, начал меня спрашивать «что за животное это писало?», «Здесь вот в этом месте куча говна с рандомным результатом». Чтобы мне хоть какая польза от лишнего тела была.

Тогда нубу будет проще вдоль сделать.

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

Насколько нет? Когда я таки попал в уже имеющий некоторую историю проект, кой какая документация там все же была. Описание основных архитектурных решений, к примеру. Работа с некоторыми самописными «фреймворками».

Если документации нет вообще - то только вопросами к большезнающим.

P.S.: На каком языке проект?

Ну тогда действительно отпрофилируй. Я так делал - показывает вполне хороший граф внутренних зависимостей проекта. Я для этого использовал valgrind + kcachegrind, вполне удобно. Kcachegrind показывает и код, и то, что он действительно вызывает. Особенно это помогает, если используется куча виртуальных вызовов или void-ов и указателей на функции.

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

и начать искать да править ошибки

Или одно, или другое.

А как объяснить процесс подающему надежды нубу?

Показываешь багу и говоришь - правь. И не только нубу.

Насколько нет? Когда я таки попал в уже имеющий некоторую историю проект, кой какая документация там все же была. Описание основных архитектурных решений, к примеру. Работа с некоторыми самописными «фреймворками».

Ну, я смотрел. То, что у нас есть — недописанные более, чем наполовину, ридмихи. Причем то, что в них есть, действительности не соответствует, так что вреда больше, чем пользы. Движок шаблонов в софтине, например, самописный, причем глючный и недокументированный. А недокументированный настолько, что в некоторых местах пытается данные выполнить как код (кто-то скобку в макре не там закрыл), ругается, но я еще не дорвался до этого места. %)

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

«Это винтик, это отвертка, винтик можно крутить отверткой. Это всякие железяки, их можно соединять винтиками, закрутив отверткой. Еще бывают гайки и шестеренки.
Задание:
Постройте синхрофазотрон. »

Мне тоже (программисту с 10 годами опыта) предлагали пройти через круги этого ада, но на то у меня и опыт, чтобы не заниматься скучной ерундой, а переходить к делу (и нескучной ерунде). А нуб так не умеет, его спасать надо.

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

Надо расширять и углублять.

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

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

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

P.S.: На каком языке проект?

Perl :)

Я знаю :( Их там почти две тысячи человек.

http://xkcd.com/1172/ как нельзя более в тему.

более развернуто: Наиболее действенная мера: изучение и анализ исходников. Далее поиск по ним - поэтому нужны изощренные способы поиска.

если код в гите, то искать подозрительные места лучше git grep или git ls-files|grep crappy-file

man или git help grep|ls-files + примеров полно в сети: git grep examples git ls-files examples

туториалы по простейшим регуляркам особенно по классовым квалификаторам поиска. Выражение вида «\bkeyword\b» ищет по границе ключевого слова: mykeywordMethod вычленяет например его. Очень удобно. Имхо умение грепать это твои глаза и уши, а find и им подобные: руки и ноги :)

Полезны сайты по примерам команд:

http://www.commandlinefu.com/commands/browse

http://www.examplenow.com/ был еще какой-то не помню сейчас.

Если гит не знаешь - освой очень полезно и легко. Материалов по нему полно. Начни с мини-примера. Большой проект сразу не влезет в гит - могут проблемы с именами и ссылками и мусором.

gdb, strace аналогично. Актуально, когда нет исходников или непонятно, что происходит с прогой. Могут потребоваться большие ресурсы и пересборка проекта.

Ну и гуглить тему: анализ сложных систем и т.п.

Совет: чаще говорить себе: Хочу так, так и так... ))

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

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

Проект должен собираться, и только потом можно что-то с ним делать.

Всегда смотрю где проект начинается и где заканчивается - подключения к сервисами, конфиги.

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

всегда о том, «как нужно», надо узнавать у спецов по предметной области, и запоминать

Абсолютно точно. Именно так и делаю. Без выделения предметной области не обойтись. Вам надо знать к чему стремились разработчики, какую модель они видели, и к чему пришли в итоге (который вы анализируете).

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

если код в гите, то искать подозрительные места лучше git grep или git ls-files|grep crappy-file

И сразу фейл.

gdb, strace аналогично

gdb очень полезен для проги на Перле.

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

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

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

Особенно когда клиенты сперва «зарплату дневного сторожа записывают как поставку асфальта, все согласно смете» (© «Гараж»), а потом через два квартала им по баблу этот самый асфальт и не сходится.

Если династия, то еще проще тогда вразумить. Все методы хороши.

Ролики на ютубе - самое то для вразумления и восприятия.

Сферический тестинг в ваукуме, найс.

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

Мне это понятно. Мне интересно, есть ли какая-нибудь методика обучения этим финтам сторонних людей.

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

чем тебя поиск гитом не устраивает?

Мне интересно, есть ли какая-нибудь методика обучения этим финтам сторонних людей.

В общем, нет.

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

Почаще спрашивай его «что непонятно?», выдели время, в которое он может доставать тебя вопросами. Ну а вообще - «только шаги учат ходить» (ц).

чем тебя поиск гитом не устраивает?

Двумя вещами: 1) гит - убогое говно 2) поиск по VCS более-менее эффективен, когда человек уже знает кодовую базу.

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

1) возможно, но для себя лучшего пока не встречал (пробовал многое кроме Hg) Мне нравится его поиск тем, что он просто интегрирует grep в свою базу и сразу фильтрует проектные файлы.

2) ну тогда просто find|grep (выше привел список в порядке предпочтения) может авк

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

Использую старый, добрый cscope + ctags.

надо в нем разобраться в достаточном объеме и начать искать да править ошибки.

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

а на перле бывают настолько большие проекты? уж не OTRS ли вы пилите?

Doxygen

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

Perl :)

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

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

Другое дело на Java, когда залезал в исходники Eclipse/CDT, там документации тоже мало, но хотя бы IDE все связи между разными частями кода и xml-конфигами корректно находит и можно быстро составить какое-то представление о происходящем. А дальше уже под отладчиком нужную часть прогонять и баг отлавливать.

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

Нет, наше особое проприетарное говно (тм)

У нас новый сотрудник есть в качестве тестера

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

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

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

Мне не нужен тестировщик а-ля тупой юзер, у которого «не работает и все тут».