Подтвердить что ты не робот

Как вы обрабатываете крупные проекты?

Я только что унаследовал большой проект, ранее закодированный примерно 4-5 людьми. Документация состоит из комментариев и не очень хорошо написана. Я должен быть в курсе этого проекта. Как начать? Он состоит из множества исходных файлов. Вы просто копаетесь? Существуют ли инструменты, которые могут помочь визуализировать структуру/поток?

4b9b3361

Ответ 1

Если у вас есть шанс, я попробую поговорить с оригинальными дизайнерами и разработчиками. Спросите их о каких-либо серьезных проблемах дизайна или недостатках проекта. Является ли проект в хорошей форме и нуждается только в техническом обслуживании или есть основные компоненты, которые необходимо добавить или переработать? Что будет самым большим препятствием для поддержания проекта? Возьмите один или два из них на обед (отдельно), если у вас есть бюджет для него, поскольку они могут быть более свободны говорить о проблемах за пределами офиса.

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

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

Удачи.

Ответ 2

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

Ответ 3

Мозговой штурм для вас:

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

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

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

Ответ 5

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

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

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

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

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

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

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

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

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

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

Удачи.

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

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