程序員如何快速上手一個自己不太熟悉的新項目？有什麼技巧？
典型的情景就是換工作，新工作的項目可能擁有很複雜的結構，而你對這個領域並不熟悉，也沒人指導你
不知道你有沒有經歷過一個五年或者更長工作年限的開發人員半路加入團隊的情況，可能第一兩個星期他會問一些業務或者技術問題，不過一兩個月他就可能在指導那些初級開發人員了。
什麼原因呢？因為他已經從過往經驗裡面總結出來一些套路了。
那麼套路是什麼呢？
1. 絕大部分業務系統，不管他後端是oracle、mysql、nosql還是內存資料庫，也不管他前端是web、h5、winform、android還是ios，它的核心功能都是由增刪改查組成然後通過通信、運算和人機交互串起來的，系統的複雜度主要體現在系統規模、性能、穩定性、業務流程、通信等方面。（部分工具類、基礎架構類系統可能不一樣）
2. 絕大部份系統，不管是基於Java、.NET、C++還是Nodejs技術，都是遵循某種或幾種設計模式分層進行開發的，最最常見的也就是MVC了。其他請參考一下設計模式教程。
那麼怎麼快速熟悉新的項目呢？同樣也是套路。
1. 先搞清楚新的系統是搞什麼的，就問簡單幾個問題，誰在用這個系統？用這個系統做什麼？然後自己根據這些問題去文檔找答案。
2. 弄清楚系統是怎麼分層、分模塊的，每層、每個模塊都用到了什麼技術和框架，之間是怎麼通信的。有架構設計文檔的話學習一下最好，沒用過的技術先查查資料知道個大概。
3. 把開發環境搭起來，通過幾個典型的功能弄清楚系統裡面增刪改查、通信、用戶交互是怎麼實現的。最簡單的方法是根據系統的分層，先從前端到資料庫把代碼疏通一下，搞不清楚的話打開debug模式一步一步走一下。
4. 經過上面三個步驟基本上就可以改幾個bug和照葫蘆畫瓢做個功能了。後面重點關注那些沒用過的技術和組件：先搞清它的目的、背景、實現原理和功能列表，再照著文檔做幾個demo，平常工作時把它的文檔建個快捷方式，隨手查詢學習一下。
5. 平常開發過程中如果遇到問題首先要相信：
1）絕大部分自己遇到的問題很多人已經遇到過並且解決了 。
2）絕大部分自己遇到的問題在當前系統裡面已經有了答案。
3）絕大部分自己遇到的問題在你用的框架和組件裡面都有現成的解決方案。
6. 對於規模比較大的系統或者系統集合，其實你平時工作接觸到的也就是其中的一個系統或者模塊，先把自己接觸的部分搞定就行了。
7. 對於老系統，首先建議看一下我另外一個回答：在感覺項目代碼的構架不行的時候,你們會怎麼辦? - Jim Jin 的回答
1）老系統其實滿是寶藏，裡面有很多你可以借鑒和學習的東西。
2）老系統也滿是坑，一個看起來毫不懸念的代碼改了以後可能會引發地震。
3）很多你看著不爽的代碼其實都是有道理的。
4） 不要在老系統裡面繼續挖坑。
5）看不懂的代碼不要動。
6）在你力所能及的範圍內讓老系統變的更美好。
我記得我實習的時候，當時我們公司做手游開發的。已經有好幾個項目。客戶端和伺服器都是幾個元老級的大牛搭建起來的框架，相當龐大。
當時我只是做客戶端UI部分，是最簡單的了，文檔齊全，但是上手起來也相當麻煩。
後台因為一直沒有齊全的文檔，也不敢交給我們這些實習生接觸。
然後我們公司開了個大牛真是讓我大開眼界。他來後自己拿著代碼每天研究，偶爾問幾個問題。
一周之後，他就可以跟其他大牛們嘰里呱啦討論問題了。
然後過不久他直接被併到後台。跟其他大牛一起做。
當時是心生崇拜。
後來有一定經驗了，慢慢發現，自己上手一些項目也會相當快。
接到一個全新的項目，先找開發文檔。很多時候底層只需要了解個大概。開發查查API，不懂的再問一問。很多時候都能遇到似曾相識的東西。
有些甚至看了開頭就看懂知道想寫什麼了。
很多開發經驗其實是互通的。這其實基於幾個原因。最重要的是因為他們本身也是經驗豐富的程序員，會把很多接觸過的理念放到代碼、設計當中。
一些基礎的部分大家都是一樣，並沒有看起來那麼複雜。
一個簡單的例子。一個熟悉設計模式的人，看別人的代碼能很快認出來，即便不同語言不同框架。但是沒接觸過的人肯定一頭霧水。
Office的源碼可以塞滿普通筆記本硬碟，一不小心在核心區域搞出了編譯錯誤的話，編譯器的錯誤信息還曾經log滿了1T的SSD導致恢復不了要格式化，所以我就經常需要幹這種事情，因為隨便找個人剛好熟悉我需要處理的代碼的概率無限趨近於0。
不過熟悉代碼還是很容易的，因為你只要先通讀設計文檔，然後去單步調試一下單元測試裡面你關心的內容，等到心裡有個大概了再看一遍代碼，就什麼都明白了。新接手一個系統，如果你的目的是假設需要你排查一個問題，你就能快速定位代碼位置這樣的要求即可的話，掌握系統的大體架構和核心流程即可。
大體手段都差不多，從全局角度理解問題，拆開看細節實現。
1，弄明白系統是什麼（定位，以及對外提供的功能）
2，有文檔就看系統的設計文檔，弄明白系統的模塊結構，理解系統是如何構成的。（如果沒文檔只好看代碼目錄結構了，然後試圖通過模塊間的介面梳理清楚模塊關係）
3，看一下核心功能實現，理解整個功能流程是如何走通。
Just Run it
在我剛成為WPS開發的時候，我面對的是幾十G以上的源代碼，代碼中很少有注釋，頭文件中也很少寫到這個類是做什麼用的，這個介面是做什麼用的，更重要的是，組裡的人說，我們並沒有什麼文檔，經驗都是口口相傳的，也沒有什麼人帶，一切都要靠自己去看代碼，當時我的心情是：
沒有多久就要開始改ｂｕｇ了，分配到我頭上的都是一些界面上的問題，慢慢就要改內核、ＩＯ等各種各樣的ｂｕｇ了，真的是很苦逼。（也多虧了這樣，極大提高了我的代碼能力。）
對於一個新工程，可以用像下面這樣的方法來快速上手：
１ 搭好編譯環境，並讓它跑起來。
２ 在一個簡單的功能入口設置一個斷點，看看程序運行到這裡，它的堆棧是怎麼樣的，然後去分析程序的結構、層次關係（ＭＶＣ什麼的）。
３ 在你覺得重要的類的構造函數、析構函數（如果有的話）處設置斷點，看看它們的生命周期是如何管理的。
４如果對於2、3都了解的話，就跟進工程的底層，了解程序的框架。框架都是簡單的，當了解了框架後，程序的功能的添加、刪除也就是加減法了。 WPS雖然沒OFFICE那麼大，但是我覺得它的複雜程度可以秒殺國內大部分軟體了吧。
如果是一個人獨攬一個新工程，沒有人帶，沒有文檔的情況下，就這樣試試吧。
年輕的時候接手別人代碼看不懂，心想：媽的大神啊！寫的我都看不懂
現在接手別人的代碼看不懂，心想：媽的傻逼啊！文檔呢？注釋呢？這變數名a,b,c,d,e的別說我看不懂你自己過兩天自己都看不懂了好么！這模塊特么怎麼劃分的？這類特么怎麼這樣寫？這輸入輸出搞笑的吧！
真正好的代碼是自解釋的，那些看似高深的代碼，大部分都是垃圾代碼（除了一些演算法，當然越是高深的演算法越要寫好介面和注釋好么！）
c，c++，c#，java，javascript，html這些林林總總的東西說白了就是一種語言，代碼說白了就是一篇小說，小說寫的你看不懂誰的鍋？當然是作者的鍋啊！！這年頭除了那些開創性的成果，大部分代碼都是從別人開源代碼摳出來重新拼接的結果，（從開源源碼摳還算好的，好多代碼還是csdn上摳下來的呢）
90%的代碼都沒那麼有價值非要你去弄明白，寫的那麼垃圾比他寫的好的開源代碼大有人在
我是分割線
_(:з」∠)__(:з」∠)__(:з」∠)_
其實最複雜的計算機知識都在學校里學過了，那時候sql語句是要自己寫的，排序是要自己做的，線程死鎖是要你自己處理的，指針是要記得釋放的，編譯原理你是要懂的（說實話我現在都沒在工作中遇到啥編譯原理問題。。。）
工作中碰到的各種struct，各種模式，各種類，各種庫，其實是讓你用更簡單的方式去實現原來需要在親手在計算機2級試卷和面試中上實現的功能，只不過人家封裝好了讓你用，為了讓你用的方便，又寫了一堆文檔，為了文檔好懂，又做了一個demo罷了
乍一看好嚇人，事實上他們都是你的朋友，你也沒必要全懂，有個全局概念，用到啥，弄懂啥就行了
mfc幾千個類誰敢說都懂？
我還沒完全弄懂，比他好用一萬倍的c#就普及了（去死吧，文檔視圖框架，去死吧，指針，去死吧classwizard）
android原生遊戲開發我才學了個皮毛，（害得我研究了一堆開源引擎。。。）發現大家都在用unity3d了
as3.0我還沒用習慣發現都在用html5了
不是你不明白，是世界變化快，程序員就得放開手腳去擁抱新東西，
開源的東西是讓你研究的，花錢買的引擎才是好用的（人家那文檔和教程寫的，很多還有機構專門做本地化，嘖嘖），那些既不想研究開源框架，又不捨得花錢買商業框架的所謂it公司，拿個所謂的架構讓你搞，說白了就是浪費人青春
你會很快把之前那些亂七八糟的架構和垃圾公司的offer扔到垃圾堆里去的
ps：不過opencv怎麼還是那個opencv。。。這麼多版本了還是不能內存轉碼jpg。。。你把內存存成jpg文件然後再讀取成內存是在搞笑么。。。觀其大略，不求甚解
僅從單個項目的角度而言，有兩個思路：
1. 按介面從上往下梳理
2. 按資料庫從下往上梳理
需要梳理的東西主要有兩個：
1. 類/方法/函數之間的調用關係
2. 參數傳遞與變化
通過上面的方法基本能整理出一套從介面到各處理類/方法/函數再到資料庫的邏輯鏈條，然後再具體看每個類/方法/函數的實現，基本就能快速上手了
一點淺見熟悉項目一般都是看設計文檔，需求文檔，閱讀源碼，實現需求；
但是！大部分中小型初創或創業型企業哪有那麼多文檔，天天加班趕項目時間都不夠用，老闆一般都是結果導向的，只要完成功能模塊無bug，而且都喜歡搞敏捷開發。 還有時間寫設計文檔？所以 呵呵噠；
閱讀他人代碼這種事情對入行不久功力不太深的都會稍有吃力感，代碼風格這種事情除非你運氣非常好遇到了相同派系。其實我最初自己擼的碼(那時候不太寫注釋)過幾天回頭去看，自己也是懵圈的(這TM真的是我寫的？)；所謂 碼別三日當刮目相看(捂臉)~
好吧，講講我很早以前接手爛尾項目的一個死辦法吧。就是注釋，逐行注釋，有注釋就再加上自己理解的，沒有注釋就自己添加。抽絲剝繭的時候碰到完全不懂的函數千萬別跳，別總認為這個方法不重要那個方法不弄懂也沒關係，那不如不看。還有就是調試。
開發文檔什麼的有的話 至少提升70%的上手速率 問題是很多老舊的程序沒有開發文檔 甚至沒有或極少有注釋的時候 怎麼辦？
好的設計應該是面向介面的 但前人寫得爛怎麼辦 或者因為歷史問題 各種分支被強行加入 面對耦合嚴重的系統 怎麼看其中的代碼？
直說吧 當以上問題嚴重要一定程度 又沒有有經驗的人帶的時候 根本沒法看 你能做的僅僅是維護 fix bug而已 這個時候 二分法找bug絕大多數情況下是效率最高的
然後找在哪裡輸入 這個時候你會遇到一堆混雜的callback 必須憑感覺和人品 找到核心的交互函數 記住（往往藉助筆記）邏輯 注意不要糾結於細節 一些奇怪的if條件看不懂就直接忽略 抓住主線就行
如果前面的實踐失敗 就從輸出開始找 反著來
雖然上面的方法開起來一點也不優雅 不geek 卻是我工作中用到十分有效的方法 藉助筆記來記錄也是關鍵之一 因為普通人不太可能記得住那麼多變數和函數名以及調用過程
安裝好開發環境，跑起來運行的項目。跟進一個最簡單的功能點。登錄頁面，F12Z找到該頁面。找到類似觸發的按鈕（提交，保存之類的）。在找到他的後台action類。DEBUG跟進。然後基本就是差不多的套路。最後就是數據sql的執行。差不多就那些
從實現一個小需求開始
從一個功能入手，前端到後台一層層看，結構差不多就明白了
從客戶角度出發，就能理解你想要哪些結果，除非不會
你這麼說出來，那就簡單多了！
你要這麼寫出來，那可就不一樣了！
研究需求，功能debug，業務實現：
推薦閱讀：
※碩士畢業，第一份工作在華為很不開心，不到一年就想離職，這種想法和心態正常合理嗎？
※Kindle 軟體開發團隊有多少人？
※如何理解「如果你寫程序沒用 undocumented API，那一定是因為你的程序沒什麼了不起的功能」？
※Shader的編寫到底應該是美術的事情還是程序的事情？
※請別人來做一個電影網站模板需要多少錢？