Ваши методы анализа, поделитесь :)
 

У меня есть задание доделать проект начатый другим человеком. Проблемма заключается в том, что в коде нету коментариев в принципе. И это мягко говоря "*****код". Поделитесь пожалуйста, как вы анализируете проекты и разбираетесь в взаимосвязях в коде, используемые методики, программы или литературы какой посоветуете поискать. Или тут как говорится "до посинения анализировать код взглядом покуда не дойдет :wacko:"

зарание спасибо за любые коментарии :)

Отлаживать надо, единственный вариант.

Но вы, по моему, разделом ошиблись...

МНТ (Метод Научного Тыка).

Enterprice Аrchitect может сделать Reverse Enginering и визуально что-то показать - я бы так попробовал для начала

Если это *****код, то пишу все заново, ибо в конце концов к этому и придешь

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

Kuruki
не всегда это возможно по различны причинам.

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

1. Читаю все доступные описания работы кода
2. Досконально вычитываю весь код, запоминаю какие классы за что отвечают, пытаюсь построить зависимости в голове.
3. Запускаю программу на выполнение в пошаговом режиме, запоминаю последовательность действий на разные события.

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

а пошаговый режим - это через брекпоинты в дебаге???

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

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

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

В принципе, довольно подробно эта тема (для любого языка программирования) рассматривается в этой книге:
http://www.ozon.ru/context/detail/id/4311012/

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

Это называется Рефакторинг.
Почитайте про него.
Есть такое понятие: "Управляемая тестами разработка" TDD.
Суть:
1. Вопрос. Задаете системе вопрос с помощью написаного вами теста.
2. Ответ. Отвечаете написанием кода, успешно проходящем тест.
3. Улучшение. Убираете несущественное и неопределенное, улучшая ответ.
4. Повтор. Продолжаете, задавая следующий вопрос.
"Красный, зеленый, реорганизация" (K.Beck)
1. Пишите тест, выражающий то, что ждете от кода. Тест не проходит (красный).
2. Правите и отлаживаете. Тест проходит (зеленый). Говнокод.
3. Улучшаете проект, прошедший тест.

Спасибо большущее за ваши коментарии :) почерпнул много интересного :)