Вас подключили к новому проекту. Что вы делаете, чтобы "въехать" в тему и "въехать эффективно"?
Вариант 2. Когда нет документации, гуру и вообще никого нет. Одни тоны кода.

Мои инструменты:
1. MindMap (для заинтересованных, как это делать расскажу попозже, overview)
2. Pattern: Architecture Achilles Heel Analysis by Elisabeth Hendrickson, Grant Larsen
3. Pattern: Architecture Reverse Engineering by Elisabeth Hendrickson


Так же замечено в инете:
1. Practice Patterns for Architecture Reconstruction by Christoph Stoermer
2. A Pattern Language for Reverse Engineering by Serge Demeyer
...

Расскажите о своём опыте, с чего начинаете, как делаете пометки, как формируете общий образ системы, какие инструменты используете (ex: UML). Очень интересно

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

Затем, имея представление зачем это все писалось,
можно попробовать написать юнит-тесты и попробовать потестировать
некий кусок системы по черному ящику. Это добавит понимания
и позволит порыться в потрохах системы с помощью дебаггера.
По ходу можно попытаться нарисовать парочку "sequence diagram",
если уж есть желание попользоваться UML

"Тулы" — это не принципиально и вопрос предпочтений и доступности.
Я лично в последнее время активно пользуюсь SNiFF и Together
Иногда бывает полезным Graphviz для рисования графов...

denis miller,

DM>Вас подключили к новому проекту. Что вы делаете, чтобы "въехать" в тему и "въехать эффективно"?
DM>Вариант 2. Когда нет документации, гуру и вообще никого нет. Одни тоны кода.

Примерно это

Автор: Lazy Cjow Rhrr
Дата: 28.12.05

можно растрел?

B>Для начала попробуй понять что вообще делает система.
как это сделать?
я вижу два пути (на основании анализа кода и программы, без посторонней помощи)
1) от общего к частному — это хорошо если проект собирается
2) наоборот — если надо написать часть при заведомо несобираемом на твоей стороне проете — бывает такое

B>Попробуй выделить спецификации для какой-то части подсистемы.
какие спецификации?
как выбрать подсистему?

B>Когда знаешь для чего это писалось, становится легче понимать как это было реализовано.
ну в общем всегда есть примерное понятие о чём писалось. проблема в том что "о чём" может очень далеко от самого кода.
вопрос:
как проявляются зания о чём это писалось?
где взять эти знания?
как оценить что у меня достаточно знаний?


B>можно попробовать написать юнит-тесты и попробовать потестировать
Супер!
Тоже хороший шаг.


ещё вопрос:
когда есть эксперт в этом деле как строить бесседу с ним?
когда есть программер — что у него спрашивать?
когда есть архитектор — что у него?


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

Здравствуйте, denis miller, Вы писали:

DM>можно растрел?

B>>Для начала попробуй понять что вообще делает система.
DM>как это сделать?
DM>я вижу два пути (на основании анализа кода и программы, без посторонней помощи)
DM>1) от общего к частному — это хорошо если проект собирается
DM>2) наоборот — если надо написать часть при заведомо несобираемом на твоей стороне проете — бывает такое

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