我最近在CS幾年前畢業後開始從事軟件開發工作。目前我正在進行的項目是一個大型的正在進行的項目，它起源於90年代，結合了C，C++和Java。有多種平臺（UNIX，WIN等）受到支持，像CVS一樣使用舊技術，以及某些地區的日期文檔。當你突然投入大型項目時，你會做什麼？
我的軟件開發技能的程度源於去大學，因爲我沒有什麼真實世界的經驗。我覺得自己在CS有一個很好的基礎，但我不得不讓所有人都感到有些壓力。我很高興能夠成爲如此巨大的一部分，但同時我覺得它需要吸收很多信息。
我的同事們一直都是很棒的人，並且回答了很多問題。我的僱主僱用了我，知道我是入門級的。
我已經嘗試過繞過源代碼，並檢查如何構建所有東西，但它的規模我從來沒有見過。
更多有經驗的人在加入大型項目時如何定位？當你加快速度時，你做了哪些常見的任務？
好問題。我沒有你的確切經驗，但在這種情況下，我喜歡想，「你怎麼吃鯨魚？」答案（可預見）是「一次一口」。合理的人不會指望你立即掌握整個事情，但他們會希望看到進步。也許在大型項目中有一些小的領域不太複雜，沒有太多的依賴關係。努力去理解其中的一個，並且你是一個「咬」（和/或「字節」），更接近整個項目的專業知識。
+1，但是你應該把它從'咬'改爲'字節'：P – Cam 2010-07-23 06:29:27
這個建議適用於很多案件，而且幾乎在任何工作中。 – 2010-07-23 09:43:26
熟悉所有現有的文檔，我會盡力得到大局。從字面上看。
我會在Windows上使用Mac上GrandPerspective或WinDirStat的TreeMap。它會給你一些關於項目文件結構的見解（有時它會給出關於代碼結構的一些提示）。有了這些，你可以問你的同事一些集羣，他們做什麼，他們是如何相互關聯的。
這是重要的是有它編譯所有的時間，如果你即將做任何修改。在構建時執行測試總是一件好事，所以也要問這個問題。更好的是，如果有某種continuous integration服務器就位。如果有的話，看看它的配置 - 弄清楚構建是如何完成的。如果沒有CI服務器，但您已經掌握瞭如何構建項目的知識，請在您的本地計算機上創建一個服務器，並將其展示給您的同事 - 他們應該愛上它。
這是非常有用特別是對於Java項目。這個工具做得很好。這將爲您提供更多關於代碼結構的細節，有時還會介紹系統架構。這方面的經驗可能是有時很難，你可以從這個工具，一個代碼基本上是一個Big Ball of Mud學習;）
如果你是幸運的可能有一些JUnit或CPPUnit測試。嘗試瞭解那些測試正在做什麼總是很好的。進一步探索代碼可能是一個很好的起點。
「尋找測試，並探索它們」 - 是的，並寫下新的，特別是如果沒有任何測試。這迫使你開始低級地理解代碼，然後你可以從那裏開始工作。 – MatrixFrog 2010-07-23 08:07:32
我同意第一個評論，但我也認爲你必須學習並以某種方式看到大局。你必須至少跟蹤代碼的主要流程。
我的同事一直偉大的人民 並回答了很多問題，我。我 僱主僱我知道我 入門級。
你沒有什麼可擔心的，你是僱主知道你是什麼能夠和你的同事似乎急於幫助你 - 說實話大多數開發人員喜歡解釋給別人的東西......
從我所看到的情況來看，真正需要6年以上才能完全掌握一門語言，所以不要指望在一年之內成爲一名專家......甚至這些所謂的專家最終會學到一些新的東西他們的語言每天。
學習一個新的系統（大型）總是需要時間......系統通常不是在2周內建成，但多年以來，所以不要期望完全理解它。你最終會發現每個部分都是一片一片的。
我知道你的感受，因爲我覺得，一旦...
「我上過速讀課程，在20分鐘之內讀完‘戰爭與和平’，它涉及到俄羅斯。」 （伍迪艾倫）
我同意別人在我面前說的話。你需要一些工具來給你一個關於代碼的概述。我個人使用inFusion（http://www.intooitus.com/inFusion），因爲它在結構旁邊也提供了其他有趣的數據。
已經爲我工作最好的方法就是抓住從源頭控制一個副本，其中引發此版本離開的打算......
然後嘗試和重構代碼。如果你可以重構你知道你將在以後工作的代碼，那更好。
的原因，這是有效的，因爲：
不要投資於在某些時候買這本書：
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672
但這些鏈接應該讓你開始：
跡象表明，你的代碼需要重構和使用什麼refacoring（從重構 - Martin Fowler的） http://industriallogic.com/papers/smellstorefactorings.pdf
的代碼分類法氣味： http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
祝你好運！
幾年前，當我加入一個擁有50多個ClearCase版本控制vobs，500萬行代碼和一些可追溯到20世紀80年代的軟件項目時，情況完全相同。
我做的第一件事是查看每個源代碼控制的目錄，並快速總結我對該文件夾中的軟件做了什麼以及該代碼是什麼語言的最佳猜測。您可以通過查看這些文件夾中的文件名和任何評論或文檔來做出相當好的猜測。
然後，我查看了構建腳本，看看它們是否足夠可讀，以瞭解代碼不同部分之間的依賴關係。
最後 - 我相信這是最有價值的 - 在代碼之上拋出像Eclipse或NetBeans這樣的IDE，並開始閱讀它的各個部分。通過使用IDE跳轉到任何函數或類的定義，您可以相對容易地移動大量的軟件基線。
總的來說，有一些信心 - 項目中的其他人不太可能知道所有的代碼，所以你也不需要。使用其他人所說的話來了解整體項目和接口以及需求（如果存在的話），並通過代碼深入瞭解最常用的類和方法。
哈。當我讀到「使用現場CVS的老技術」時，我突然感到很老舊。我在想：「不是那個 - 哦...... *嘆*」:) – Joshua 2010-07-23 07:45:27
應該是社區wiki – SilentGhost 2010-07-23 09:52:52