в последнее время попадаются проекты на плюсах, в которых приходится работать (дописывать/исправлять) с чужим кодом. практически недокументированным. какие есть методы восстановления логики программы? если просто натравить розу, то получается диаграмма на миллион классов, как разбираться с которой совершенно непонятно. по идее-то задача довольно распространенная. какие есть регулярные методы ее решения?
Здравствуйте, pasenger, Вы писали:
P>в последнее время попадаются проекты на плюсах, в которых приходится работать (дописывать/исправлять) с чужим кодом. практически недокументированным. какие есть методы восстановления логики программы? если просто натравить розу, то получается диаграмма на миллион классов, как разбираться с которой совершенно непонятно. по идее-то задача довольно распространенная. какие есть регулярные методы ее решения?
Методом "пристольного взляда"
Как можно систематизировать анализ мысли (воплощенной в коде) другого человека, к тому же не факт что она там вообще присутствует...
Для этого и пропагандирют стандартные методы проектирования и разработки: Каркасы, паттерны, стандартные библиотеки.
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
Здравствуйте, BOPOH_N, Вы писали:
BOP>Методом "пристольного взляда" BOP>Как можно систематизировать анализ мысли (воплощенной в коде) другого человека, к тому же не факт что она там вообще присутствует...
кажется, что что-то все-таки можно сделать. например, если сохранить граф диаграмы в виде xml, то можно с помощью xsl выделять какие-то существенные характеристики. например, можно найти классы, на которые больше всего ссылок — это будет означать вероятно, что данные классы относятся к ядру программы. можно искать зависимости между деревьями наследований, чтобы разбивать задачу на подзадачи поддающиеся анализу. хотя бы, чтоб влезали на один экран. кажется, что задачи такого рода должны были возникать, и наверняка есть какие-то утилиты на эту тему.
Здравствуйте, pasenger, Вы писали:
P>Здравствуйте, BOPOH_N, Вы писали:
BOP>>Методом "пристольного взляда" BOP>>Как можно систематизировать анализ мысли (воплощенной в коде) другого человека, к тому же не факт что она там вообще присутствует...
P>кажется, что что-то все-таки можно сделать. например, если сохранить граф диаграмы в виде xml, то можно с помощью xsl выделять какие-то существенные характеристики. например, можно найти классы, на которые больше всего ссылок — это будет означать вероятно, что данные классы относятся к ядру программы.
Смотря что называть ядром. Возможно наоборот ядро имеет сылки на всех и манипулирует ими, а остальные компоненты ничего о нем не знают (структра а-ля exe -> dll в рамках одного модуля)
Я повторюсь что обобщенно анализировать имеет смысл только стандартные (общие) подходы к реализации.
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
Здравствуйте, BOPOH_N, Вы писали:
BOP>Смотря что называть ядром. Возможно наоборот ядро имеет сылки на всех и манипулирует ими, а остальные компоненты ничего о нем не знают (структра а-ля exe -> dll в рамках одного модуля)
это тоже интересная идея, которую тоже имеет смысл попробовать. можно еще попытаться найти подграфы, от которых никто не зависит, а только они зависят от остальной части. тогда эти подграфы можно изучать и изменять, не боясь что-нибудь нечаянно сломать в остальном приложении. и дело не только в диаграмме. допустим найти классы, которые никогда не создаются и методы, которые никогда не зовутся, если их убрать, это может увеличить понимание.
BOP>Я повторюсь что обобщенно анализировать имеет смысл только стандартные (общие) подходы к реализации.
когда я говорю об анализе, я не имею ввиду системы, которая мне все досконально разберет и представит в текстовом виде. я имею ввиду подходы, помогающие нарыть данных, которые не будут сводиться единственно к сидению в отладчике и разглядывание сорцов.
P>когда я говорю об анализе, я не имею ввиду системы, которая мне все досконально разберет и представит в текстовом виде. я имею ввиду подходы, помогающие нарыть данных, которые не будут сводиться единственно к сидению в отладчике и разглядывание сорцов.
Боюсь что в подовляющем большенстве случаев, даже построив графы и определив зависимости, ничего нельзя будет сказать о логике программы, потому что если код разрабатывался без глубокого предворительного проектирования, а стихийно "как кривая легла", то разобраться для чего служит тот или иной класс практически невозможно, а их имена только путают (из личного опыта).
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
Здравствуйте, BOPOH_N, Вы писали:
BOP>Боюсь что в подовляющем большенстве случаев, даже построив графы и определив зависимости, ничего нельзя будет сказать о логике программы, потому что если код разрабатывался без глубокого предворительного проектирования, а стихийно "как кривая легла", то разобраться для чего служит тот или иной класс практически невозможно, а их имена только путают (из личного опыта).
мой опыт говорит что-то похожее но просто в силу распространенности задачи, я думаю, должен существовать систематический подход. и ведь где-то попадалось что-то такое когда-то. подскажите, если знаете.
интересуют продукты, которые
1. сохраняют диаграмму классов в xml
2. находят неиспользуемые участки кода
3. рисуют сколько времени при выполнении программа провела в каждых своих функции или методе.
Здравствуйте, pasenger, Вы писали:
P>мой опыт говорит что-то похожее но просто в силу распространенности задачи, я думаю, должен существовать систематический подход. и ведь где-то попадалось что-то такое когда-то. подскажите, если знаете. P>интересуют продукты, которые P>1. сохраняют диаграмму классов в xml
В html — doxygen
P>2. находят неиспользуемые участки кода
TrueCoverege (run-time анализ).
P>3. рисуют сколько времени при выполнении программа провела в каждых своих функции или методе.
Любой профайлер (TrueTime, например).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, pasenger, Вы писали:
P>Здравствуйте, BOPOH_N, Вы писали:
BOP>>Боюсь что в подовляющем большенстве случаев, даже построив графы и определив зависимости, ничего нельзя будет сказать о логике программы, потому что если код разрабатывался без глубокого предворительного проектирования, а стихийно "как кривая легла", то разобраться для чего служит тот или иной класс практически невозможно, а их имена только путают (из личного опыта).
P>мой опыт говорит что-то похожее но просто в силу распространенности задачи, я думаю, должен существовать систематический подход. и ведь где-то попадалось что-то такое когда-то. подскажите, если знаете. P>интересуют продукты, которые P>1. сохраняют диаграмму классов в xml P>2. находят неиспользуемые участки кода
По этому поводу ничего не скажу
P>3. рисуют сколько времени при выполнении программа провела в каждых своих функции или методе.
А это на раз решается любым профайлером. Лично я пользуюсь бесплатным DevPartner c VC 7.0 скачать можно здесь
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
Здравствуйте, pasenger, Вы писали:
P>в последнее время попадаются проекты на плюсах, в которых приходится работать (дописывать/исправлять) с чужим кодом. практически недокументированным. какие есть методы восстановления логики программы? если просто натравить розу, то получается диаграмма на миллион классов, как разбираться с которой совершенно непонятно. по идее-то задача довольно распространенная. какие есть регулярные методы ее решения?
самое простое и надежное — это трассировка, хоть под отладчиком, хоть при помощи отладочной печати.
Тебе ведь вряд ли нужна логика программы в целом, тебя интересует конкретная ветка — вот ее и оттрассируй.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, pasenger, Вы писали:
P>>в последнее время попадаются проекты на плюсах, в которых приходится работать (дописывать/исправлять) с чужим кодом. практически недокументированным. какие есть методы восстановления логики программы? если просто натравить розу, то получается диаграмма на миллион классов, как разбираться с которой совершенно непонятно. по идее-то задача довольно распространенная. какие есть регулярные методы ее решения?
J>самое простое и надежное — это трассировка, хоть под отладчиком, хоть при помощи отладочной печати. J>Тебе ведь вряд ли нужна логика программы в целом, тебя интересует конкретная ветка — вот ее и оттрассируй.
ну и, естественно, надо строить дерево вызовов, растущее из интересующей функции верхнего уровня, из него тоже почти все видно
по-моему, почти в любой среде разработки инструметы для этого есть.
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
но просто в силу распространенности задачи, я думаю, должен существовать систематический подход. и ведь где-то попадалось что-то такое когда-то. подскажите, если знаете.
