20人年的項目2個星期交接，你從哪裡入手？

作為程式開發人員，具備學習新知識的能力非常非常重要。這是由IT領域的特殊性決定的。我們所面臨的新知識不僅包括新語言、新技能、新工具，也可能會是一個全新的項目，甚至是全新的開發環境。最近，我身邊的一位同事就遇到了一個這樣的難題：由於組織架構調整，一個20人年的項目需要2個星期內交接到他手上。這是一個純粹的商業項目，前邊有customers不斷提出問題，後邊有公司領導不斷“關心”狀態更新，其壓力可想而知。讓我們設想一下，如果你處於這樣的環境，你會怎麼做？如何才能快速上手一個陌生系統呢？

關於這個問題，我先來談談自己的體會。其中一些觀點是近10年來類似經驗的總結，也包括一些身邊朋友的心得分享。

首先，我能想到的是要熟悉業務背景，也就是industry background knowledge
，因為再沒有什麼別的比搞清楚你要做什麼更重要了。不同的商務邏輯需要不同的軟體架構支撐，需要處理不同的work flow。盡量的去熟悉業務背景能夠讓你更加清楚你所面對的項目需要解決什麼樣的具體問題，能夠幫你快速建立關於當前項目的一個大的picture。磨刀不誤砍柴工，再怎麼著急，也要請你從這一步開始。

接下來幹什麼呢？一頭紮到代碼裡邊？別著急啊！問一問有沒有關於架構設計的文檔。因為接下來你需要的是從宏觀上理解軟體的架構，從大的層次上理解軟體的結構，瞭解軟體有哪些模組組成。這些模組是如何配合工作的？在進行任何細緻工作之前，你需要先勾勒出項目的粗線條。幾乎所有的軟體項目都離不開輸入/輸出以及資料的流動。先搞清楚data是如何在各個layer或者module之間傳遞，大體上需要什麼樣的邏輯功能來處理這些data。

經過以上兩步，你算是對手頭項目有了一個大體的認識。但是到此為止，你所有的認識還只是停留在靜態文檔的基礎上。接下來，按照我的經驗，你就要儘快的讓程式動起來----搭建好開發環境，準備好有代表性的sample input data，具體地調試進去。這時候，F5+F10+F11(VS)是你最好的幫手。好的代碼結構會儘可能清晰地表達程式的處理流程。當然，你不可能指望簡單地通過幾個迴圈就完全掌握別人幾個月甚至幾年的工作積累。但是，動態調試協助你真正地走到程式內部去一窺究竟。一旦對程式有了總體認識之後，我的個人感覺是debug來的越早越好。初期的調試盡量結合架構的認識去理解程式，不要再細節浪費過多的時間。遇到不太明白的地方先跳過，多次出現的核心對象先記載下來回頭再仔細研究。

經過幾輪初期調試之後，你會直觀地感受到程式的流程，但是很多具體的東西還是不太清楚。這時候，作為一個有心人，你會積攢出一大堆的問題。不斷出現的幾個核心對象，他們究竟是如何工作的？類與類之間的關係是如何設計的？用到了哪些設計模式？程式的資料對象是如何表達的？這些都已經是比較具體的問題了。能提出具體的問題才說明你的認識到了一定具體的層次。這時候如果具有良好的OOD和OOP經驗往往會會引導你往下思考。為了深入地剝絲抽繭，建議你不要停下來。開啟UML工具嘗試著分析一下核心class的結構層次。深入理解核心類型的核心方法（演算法）。具體分析一下資料模型的如何設計和封裝的。資料模型搞清楚了之後，可以嘗試著修改資料後看看程式是如何反應的，驗證一下自己理解的是否正確。等等，等等。

其實在有限的時間裡瞭解一個陌生系統，除了正確方法之外，還要能夠抓住重點。找到程式本身的pain points，看看那些是客戶反映最多抱怨最大的問題，這個也是作為項目本身需要你去著力解決的問題。

編程是門科學，但是代碼的組織和分析卻是門藝術。掌握一個新項目往往能能考驗一個人對新事物的理解能力。快速地理解能力離不開長時間的開發經驗積累，當然還有那一絲對於代碼本身的靈感。學無止境，閱讀和維護別人的代碼也是一種很好的學習方法。