Здравствуйте, zorba, Вы писали:
Z>Допустим есть огроменный проект. Как максимально эфективно разобратся в нем? Я обычно стараюсь гонять его под отладчиком, смотрю workflow, и т.д. Эффективность не слишком высока. Особенно неприятно, что "за бортом" остаюстся огромные фрагменты кода не учавствующие в основном workflow. Есть идея попробовать тупо читать файл за файлом и строить диаграммы.
Z>Как Вы подходите к такой задаче?
Фиксю конкретные проблемы и изучаю то, что к ним относится. Зубрить весь код смысла не вижу. Это не самоцель. Возникает задача — изучаю соответствующий кусок.
Здравствуйте, zorba, Вы писали:
Z>Допустим есть огроменный проект. Как максимально эфективно разобратся в нем? Я обычно стараюсь гонять его под отладчиком, смотрю workflow, и т.д. Эффективность не слишком высока. Особенно неприятно, что "за бортом" остаюстся огромные фрагменты кода не учавствующие в основном workflow. Есть идея попробовать тупо читать файл за файлом и строить диаграммы. Z>Как Вы подходите к такой задаче?
Начинаю исправлять ошибки и добавлять функциональность, т.е. решать текущие задачи.
Здравствуйте, kaa.python, Вы писали:
KP>Алгоритм следующий. Берешь Doxygen + Graphwiz и строишь максимально подробную "документацию" для всего проекта. Включаешь построение UML моделей, генерацию кода в виде HTML. KP>Дальше, смотря на получившиеся схемы в документации, выбираешь узел, с которым связанно наибольшее количество других узлов. Обычно таких узлов несколько, так что берешь любой из них. Разбираешься с узлом, понимаешь почему с ним столько связей, пишешь заметки в тетради. После того как пройдешь основные узлы, станет более менее понятно, с чем ты имеешь дело. Если есть время, стоит немного посмотреть на второстепенные узлы. В процессе разбора активно читаешь сгенерированные из кода странички (благо Doxygen делает удобную навигацию).
KP>На этот процесс стоит потратить до 1-й недели. По прошествию которой у тебя будет более-менее сносное представление о проекте (как минимум ты сможешь задавать нормальные вопросы коллегам). KP>Дальше берешь задачку и начинаешь решать ее исходя из имеющихся знаний, в процессе дорабатываешь свои заметки по поводу архитектуры.
В итоге обычно получается много знаний, которые не связаны, и применения которым найти не получается, т.к. нет понимания верхнего дизайна проекта.
Тут в самую точку подходит пословица — "за деревьями леса не видим".
Имеет смысл найти архитектора/дизайнера(не гуй)/многоопытного разработчика, которые могут пояснить макроструктуру проекта. Основные идеи, концепции, логические блоки и их структуру.
И уже только после этого можно опускаться до диаграмм классов и исходников.
Иначе так и не получится выйти из мирка пары классов и их связи.
Алгоритм следующий. Берешь Doxygen + Graphwiz и строишь максимально подробную "документацию" для всего проекта. Включаешь построение UML моделей, генерацию кода в виде HTML.
Дальше, смотря на получившиеся схемы в документации, выбираешь узел, с которым связанно наибольшее количество других узлов. Обычно таких узлов несколько, так что берешь любой из них. Разбираешься с узлом, понимаешь почему с ним столько связей, пишешь заметки в тетради. После того как пройдешь основные узлы, станет более менее понятно, с чем ты имеешь дело. Если есть время, стоит немного посмотреть на второстепенные узлы. В процессе разбора активно читаешь сгенерированные из кода странички (благо Doxygen делает удобную навигацию).
На этот процесс стоит потратить до 1-й недели. По прошествию которой у тебя будет более-менее сносное представление о проекте (как минимум ты сможешь задавать нормальные вопросы коллегам).
Дальше берешь задачку и начинаешь решать ее исходя из имеющихся знаний, в процессе дорабатываешь свои заметки по поводу архитектуры.
Здравствуйте, zorba, Вы писали:
Z>Когда-то работал в крупной компании. Использовал именно этот метод. К своему стыду, даже через два года нифига не понимал за пределами своего маленького мирка в котором давали поработать. Не хочу повторить еще раз эту ошибку...
А стоит ли считать это ошибкой? Когда вообще НУЖНО знать как работает вся система в подробностях? И почему на работе это нужно делать самому?
Мне кажется важно оставаться на определенном уровне абстрагирования. Если допустим, я определяю архитектуру проекта, я не собираюсь подробно разбираться во всех деталях работы конкретной части. Достаточно чтобы она работала "в концепте". Детали определяет разработчик части. И разработчику части совсем не обязательно знать в деталях как работает весь проект в целом, достаточно иметь общее представление.
Зачем мне допустим, изучать как работает система печати, когда достаточно знать как ее использовать, ведь править её я не буду.
Здравствуйте, zorba, Вы писали:
Z>Просто делал это по мере необходимости год за годом. А сейчас мне хотелось бы "положить винт с исходниками на ночь под подушку, проснуться, и вуаля!" Т.е. я ищу совета людей которые столкнулись с подобной задачей и нашли эффективные методы ее решения.
А испанский так не хочешь выучить? Моментально ничего не бывает. Что-то из серии, как выучить что-то за 21 день?
Допустим есть огроменный проект. Как максимально эфективно разобратся в нем? Я обычно стараюсь гонять его под отладчиком, смотрю workflow, и т.д. Эффективность не слишком высока. Особенно неприятно, что "за бортом" остаюстся огромные фрагменты кода не учавствующие в основном workflow. Есть идея попробовать тупо читать файл за файлом и строить диаграммы.
Когда-то работал в крупной компании. Использовал именно этот метод. К своему стыду, даже через два года нифига не понимал за пределами своего маленького мирка в котором давали поработать. Не хочу повторить еще раз эту ошибку...
U>Начинаю исправлять ошибки и добавлять функциональность, т.е. решать текущие задачи.
Здравствуйте, zorba, Вы писали:
Z>Когда-то работал в крупной компании. Использовал именно этот метод. К своему стыду, даже через два года нифига не понимал за пределами своего маленького мирка в котором давали поработать. Не хочу повторить еще раз эту ошибку...
А в чем смысл понимать код за пределами своего мирка, если тебе задачи выходящие за рамки этого мирка не дают?
U>>Начинаю исправлять ошибки и добавлять функциональность, т.е. решать текущие задачи.
Это начальный этап. После прохождения этого этапа начинаешь думать как следует изменить архитектуру для того, чтобы код стал проще.
Здравствуйте, zorba, Вы писали:
Z>Когда-то работал в крупной компании. Использовал именно этот метод. К своему стыду, даже через два года нифига не понимал за пределами своего маленького мирка в котором давали поработать. Не хочу повторить еще раз эту ошибку...
А что в этом необычного? Что в этом отрицательного?
M>И тобой изучена каждая строчка .Net Framework-а, дизасемблировал полностью Windows? С чем ты там еще работаешь?
Не нужно передергивать. Кстати ядро винды (плюс WRK, ReactOS и утекшие исходники Win2000) продизассемблировал и прочитал вдоль и поперек
8 лет работаю в одной фирме, в которой нахожусь с самого основания. Очень приятно когда понимаешь или можешь легко понять как работает любая строчка в любом файле. При переходе в другую фирму хотелось бы максимально эффективно потратить время на освоение наработанного кода.
Здравствуйте, zorba, Вы писали:
Z>8 лет работаю в одной фирме, в которой нахожусь с самого основания. Очень приятно когда понимаешь или можешь легко понять как работает любая строчка в любом файле. При переходе в другую фирму хотелось бы максимально эффективно потратить время на освоение наработанного кода.
Ну если ты разобрался в Windows, что мешает делать так же? Например, решая конкретную задачу заглядывать чуть-чуть больше в те методы, что используются? И с каждой новой фрикцией входить глубже и глубже?
Просто делал это по мере необходимости год за годом. А сейчас мне хотелось бы "положить винт с исходниками на ночь под подушку, проснуться, и вуаля!" Т.е. я ищу совета людей которые столкнулись с подобной задачей и нашли эффективные методы ее решения.
M>Ну если ты разобрался в Windows, что мешает делать так же? Например, решая конкретную задачу заглядывать чуть-чуть больше в те методы, что используются? И с каждой новой фрикцией входить глубже и глубже?
Здравствуйте, zorba, Вы писали:
Z>Допустим есть огроменный проект. Как максимально эфективно разобратся в нем? Я обычно стараюсь гонять его под отладчиком, смотрю workflow, и т.д. Эффективность не слишком высока. Особенно неприятно, что "за бортом" остаюстся огромные фрагменты кода не учавствующие в основном workflow. Есть идея попробовать тупо читать файл за файлом и строить диаграммы.
Z>Как Вы подходите к такой задаче?
Был в такой ситуации.
Практика показала следующее.
Если не сделать над собой усилие и не потратить время целенаправленно изучая систему — даже спустя 1-2 года никакое просветление не приходит само. То есть научаешься ходить строго по циркулю, ни шагу в сторону от типового кода и не понимаешь, почему нужно именно так.
К счастью, в системе всего несколько процентов кода, который следует прочесть.
Его надо идентифицировать и целенаправлено изучать.
Как идентифицировать — это шаманская наука в каждом конкретном случае.
Здравствуйте, Undying, Вы писали:
U>Это начальный этап. После прохождения этого этапа начинаешь думать как следует изменить архитектуру для того, чтобы код стал проще.
Зрелый этап — начинаешь понимать, что не стоит менять архитектуру без крайней необходимости. Архитектура — не самоцель. Цель — удовлетворение кастомеров.
Здравствуйте, _Obelisk_, Вы писали:
U>>Это начальный этап. После прохождения этого этапа начинаешь думать как следует изменить архитектуру для того, чтобы код стал проще. _O_>Зрелый этап — начинаешь понимать, что не стоит менять архитектуру без крайней необходимости. Архитектура — не самоцель. Цель — удовлетворение кастомеров.
Думать над тем как можно было сделать проще надо в независимости от того собираешься завтра архитектуру менять или нет. Хотя бы для того, чтобы завтра при решение схожей задачи решить ее лучше.
Здравствуйте, Murom, Вы писали:
M>Имеет смысл найти архитектора/дизайнера(не гуй)/многоопытного разработчика, которые могут пояснить макроструктуру проекта. Основные идеи, концепции, логические блоки и их структуру.
M>И уже только после этого можно опускаться до диаграмм классов и исходников. M>Иначе так и не получится выйти из мирка пары классов и их связи.
Зависит от твоего подхода к разработке. То что ты пишешь — подход типичного кодера, которому вобщем-то на все, за пределами его задчи, пофигу. Но, безусловно, он тоже работает.
Здравствуйте, zorba, Вы писали:
U>>Начинаю исправлять ошибки и добавлять функциональность, т.е. решать текущие задачи.
Z>Когда-то работал в крупной компании. Использовал именно этот метод. К своему стыду, даже через два года нифига не понимал за пределами своего маленького мирка в котором давали поработать. Не хочу повторить еще раз эту ошибку...
Поддерживаю. Тоже шел по этому пути. В итоге я и через месяц и через два и через пять работал так же медленно, как в первый день работы. Ну почти. Лично мне без схем и подробных объяснений вообще не понять тонны кода, где даже комментариев почти нет. Где-то должен быть документ, который описывает архитектуру, начиная с самого абстрактного уровня и заканчивая описанием реализации. К сожалению таких документов почти что не встречал. Сам же стараюсь делать их, когда прихожу к некой конечной точке разработки.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
