Что вы делаете, когда вдруг попадаете в большой проект?

Недавно я начал карьеру в разработке программного обеспечения после окончания пару лет назад в CS. Текущий проект, над которым я работаю, - это большой текущий проект, который имеет свое происхождение в 90-х годах с использованием C, С++ и Java. Поддерживается несколько платформ (UNIX, WIN и т.д.), Более старые технологии, такие как CVS, и некоторые документы, датированные в некоторых областях.

Степень моих навыков разработки программного обеспечения связана с посещением университета, поскольку у меня мало опыта в реальном мире. Я чувствовал, что у меня неплохая основа в CS, но я не могу не чувствовать себя слегка подавленным. Я рад быть частью чего-то такого огромного, но в то же время я чувствую, что много информации поглощает.

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

Я попытался проговорить исходный код и изучить, как все построено, но оно в той шкале, которую я никогда раньше не видел.

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

Ответ 1

Хороший вопрос. У меня не было вашего точного опыта, но в таких случаях мне нравится думать: "Как вы едите кита?" Ответ (предположительно) "один укус за раз". Разумные люди не ожидают, что вы сразу поймете все это, но они захотят увидеть прогресс. Возможно, есть небольшие области более крупного проекта, которые не слишком сложны, без слишком большого количества зависимостей. Работайте над пониманием одного из них, и вы являетесь одним из "укусов" (и/или "байт" ) ближе к опыту по всему проекту.

Ответ 2

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

сгенерируйте TreeMap исходного кода

Я бы использовал GrandPerspective на Mac или WinDirStat в Windows. Это даст вам некоторое представление о структуре файлов проекта (иногда это дает некоторые подсказки о структуре кода). Имея это, вы можете спросить своих коллег о некоторых кластерах, о том, что они делают, о том, как они относятся друг к другу.

узнать, как создать проект

Это важно, если вы все время компилируете, если собираетесь сделать какие-либо изменения. Выполнение тестов, выполненных во время сборки, всегда хорошо, поэтому попросите его также. Еще лучше, если есть какой-то сервер Structure101 или аналогичный инструмент

Это особенно полезно для проектов Java. Этот инструмент отлично справляется. Это даст вам более подробную информацию о структуре кода, а иногда и о системной архитектуре. Этот опыт может быть иногда затруднен, вы можете узнать из этого инструмента, что код в основном представляет собой Big Ball of Mud;)

найдите тесты и изучите их.

Если вам повезет, могут быть какие-то тесты JUnit или CPPUnit. Всегда полезно понять, что делают эти тесты. Это может быть хорошей отправной точкой для дальнейшего изучения кода.

Ответ 3

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

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

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

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

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

Ответ 4

"Я прочитал курс скорости и прочитал" Войну и мир "за двадцать минут, это связано с Россией". (Вуди Аллен)

Я согласен с тем, что говорили другие. Вам нужны некоторые инструменты, которые дают вам обзор кода. Я лично использовал inFusion (http://www.intooitus.com/inFusion), потому что он также предоставляет другие интересные данные рядом со структурой.

Ответ 5

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

Ответ 6

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

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

Причина этого в том, что:

Рефакторинг
дает вам цель для вас. В то время как "игра" "нарушение" кода велик - он не сфокусирован.
Для кода рефакторинга вам действительно нужно понять код.
Реорганизованный код оставляет код, который имеет меньше концепций для сохранения в памяти. Если вы не понимаете большую кодовую базу, это не потому, что вы выпускник, потому что никто не может сохранить более 7 (дать или принять несколько) за раз.
Если вы выполняете правильные рекомендации по рефакторингу, это означает, что вы будете писать тесты. Хотя, убедитесь, что вы будете работать над модулями, которые вы тестируете, поскольку письменные тесты могут быть очень трудоемкими (хотя и очень полезными).

В какой-то момент инвестируйте в покупку этой книги:

http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672

Но эти ссылки должны начать:

Признаки того, что ваш код нуждается в рефакторинге и какой рефакторинг использовать (из Refactoring - Martin Fowler) http://industriallogic.com/papers/smellstorefactorings.pdf

Таксономия кодовых запахов: http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm

Удачи!!!

Ответ 7

Я был в той же ситуации несколько лет назад, когда я присоединился к программному проекту с 50+ контрольными версиями ClearCase vs, 5 миллионов строк кода, а некоторые из них относятся к 1980-м годам.

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

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

Наконец - и я считаю, что это было самым ценным - выбросьте IDE, например Eclipse или NetBeans, поверх кода и начните читать его. Имея возможность перейти к определению любых функций или классов с помощью IDE, вы можете с легкостью перемещаться по массивной базовой линии программного обеспечения.

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