Как Вы обрабатываете крупные проекты? [закрытый]

Я бы посоветовал вам купить и внимательно прочитать эту книгу . Она предоставляет вам МНОГО информации по этому поводу, гораздо больше, чем вы найдете здесь.

Существуют ли инструменты, которые могут помочь визуализировать структуру / поток?

Последняя версия Visual Studio 2010 позволяет создавать диаграммы архитектуры .

http://ajdotnet.wordpress.com/2009/03/29/visual-studio-2010-architecture-edition/

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

Каждый раз, когда я начинаю новый проект, я трачу 2-3 дней бегло читая код и делая заметки. Я в основном просматриваю все решение сверху вниз и делаю карту в текстовом редакторе каждого (значимого) класса в каждом проекте и того, что он делает.

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

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

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

Что касается потенциальных инструментов, вы можете изучить NDepend . Это инструмент анализа кода, с упором на выявление внутренней организации и зависимостей кодовой базы ( см. Этот пост для типичных результатов) и выявление проблем с качеством кода. Я лично не использовал его, но Патрик Смаккиа, один из разработчиков продукта, опубликовал несколько постов, в которых он применяет NDepend к некоторым классическим приложениям ( здесь, например, NUnit ) и обсуждает, что это означает, и я нашел их интересными.

Небольшой мозговой штурм:

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

Поговорите с людьми - как разработчиками, так и ПОЛЬЗОВАТЕЛЯМИ, чтобы почувствовать приложение.

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

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

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

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

Затем отобразите (или сделайте иерархическую) схему основных функций системы; классифицируйте их по категории, цели или модулю. Если система выполняет какие-то рабочие потоки или бизнес-транзакции, попытайтесь построить какую-то диаграмму состояния / перехода, документируя каждое (и перекрестно ссылаясь на каждое состояние / переход к подсистеме или модулю в системе, которая за это отвечает.)

Как только он у вас есть, вы можете копать в соответствии с функцией. Лучше всего копать для определенной цели, например, для исправления ошибки. Вы находите логический модуль или категорию, относящуюся к этому исправлению ошибки, у вас есть предварительные и дополнительные условия;тогда вы можете копать именно в этом исправлении (или около него).

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

Если нет руководства пользователя, реализовать проект в соответствии с вашими встречами с пользователями / связями пользователей. Это может служить руководством для реализации руководства разработчика / администратора для системы, которую вы только что унаследовали (если когда-либо будет возможность реализовать ее.)

Если код не находится в системе управления версиями, поместите его в нее. Неважно, какой SCS вы выберете (может быть, даже CVS, фу!) Важно как можно скорее поместить его в систему контроля версий.

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

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

Удачи.

1. Используйте Profiler , чтобы увидеть основные функции и события в вашем проекте (самый быстрый способ изучить фреймворк)
2. Очень хорошо изучите бизнес-логику, чтобы лучше понимать код.
3. Документирование каждого нового, что вы изучаете - setup wiki (вы удивитесь, как быстро все забудется)
4. Вы можете использовать Visio для рисования диаграмм моделей баз данных. (держите их под рукой при изучении кода)

Это то, что помогло мне, когда я унаследовал предыдущий проект (50+ разработчиков, 70+ ГБ базы данных, 1 ГБ исходного кода и даже ни одной строчки комментариев в коде (может быть, несколько :), и все, что написано на иностранном языке)

Я бы предложил две вещи, которые могут помочь:

• Ориентируйтесь на продуктивность. Другими словами, найдите изменение, которое необходимо внести, и используйте его, чтобы узнать, как работает эта часть системы. Ваши изменения могут быть не самыми элегантными без полного понимания программного обеспечения, но вы сделаете работу в течение нескольких дней / недель.

• Следите за вещами из пользовательского интерфейса. То есть, если изменение касается действий, которые пользователь делает в диалоговом окне, найдите этот диалог в коде (относительно легко), а затем работайте в обратном направлении, чтобы увидеть, какие части кода предоставляют данные для этого диалога, как диалог взаимодействует с системой и т. Д. Пытаться найти «где в коде X» очень сложно без хорошей документации, но найти «где находится код, относящийся к этому диалогу» довольно просто и это дает вам точку входа в код.

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

Когда вы будете готовы что-то изменить, как сказал @Jaxidian, Эффективная работа с устаревшим кодом - отличный ресурс.

Поговорите с пользователями или прочтите руководство и / или, если оно существует, пройдите курс обучения работе с системой (внутренние отделы обучения иногда собрали их вместе, если пользователей много).

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

Если у вас уже есть команда, вы можете поручить каждому по части framework, и результат их исследования должен быть где-то прописан, например, вики. После этого дайте каждому задание, подобное тому, что уже выполнено в системе (с функциональной точки зрения)

Например: если в вашем приложении отображается список продуктов, вы можете отобразить список заказов (сложность должна быть примерно такой же), точно так же, как это делается на самом деле в приложении. Чем интереснее: попробуйте отредактировать и сохранить в БД.

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

Таким образом, вы увидите, как все делается довольно просто + ваша команда будет в курсе этих знаний.