引言：

有時候我們開發專案不是從專案一開始就參與的，那麼，如何在專案進行到一半時，儘快的瞭解並上手這個專案，或者在專案已經完成的情況下，如何進行重構優化維護，這些都需要我們儘快瞭解專案。

------------------------------------------------------------------------------------------------------------------

1. 「當個小白」

       把自己當做使用者吧，看看自己的需求是什麼，自己的問題是什麼。這個會從巨集觀上決定你的大方向不會走偏，同時也可以很好的幫助你瞭解這個系統是幹嘛的。

從使用者的角度出發，我是幹什麼的，我平時都要做哪些事情，我現在有哪些問題需要解決，這個系統能幫我做哪些事情，這個系統用的是否容易上手……在這個體驗的過程中，相信你就會清楚自己要幹什麼了。

2. 「開發文件 & 資料庫」

       目前個人認為，熟悉資料庫是很快捷的一個方式。

因為資料庫是根據需求來的，那些表，欄位是不會無緣無故冒出來的，相信前面的程式設計師也是費了一些心思根據需求設計的。而且，從程式碼來看，實現方式多種多樣，但是資料庫還是比較固定的，各種邏輯功能都是以它為基礎建立的。理清楚這些表的結構關係，每個欄位的意義，這個系統你也就瞭解的七七八八了。

當然，開發文件，交接文件，這些前人留下來的資料也是很好的參考資料。而且，有時候， 本人指導也不如文件來的實際，因為本人記得沒他文件記得全，同時文件的資訊不會失真。

3. 「 模式 | 框架  | 架構 | 平臺 」

       很多時候專案難以上手的原因也在於不瞭解的專案中的設計模式、框架、架構、平臺。

因為你可能知道每句程式碼是什麼意思，但是放在一起就不知道它們在幹什麼。或者你知道它們在幹什麼，但是不知道為什麼要這麼寫。如果讓你寫程式碼，你不知道怎麼從哪裡寫，寫些什麼。

這時候你就需要知道，這個系統用什麼設計模式了？為什麼要用這個設計模式？這個系統的架構是什麼？在這個架構上如何實現功能的？以及自己是否熟悉這個框架，這個平臺。如果其中有不熟悉，查資料，看視訊，儘快的去掌握這些。

4. 「走一條線」

       很多人會說，走一條線你就明白這個系統了。

的確，在你上面的基礎打好了之後，通過熟悉系統中的原始碼。走幾條線是一個很好的方法。上面的內容很像是理論，而這個就很像是動手實踐了。

關於理論和實踐，結合起來是一個很好的辦法。這裡我的個人經歷就是，理論有時候過於抽象枯燥，難以結合實際；而實踐有時候難以明白原理，或者與一反三。這時候，理論聯絡實踐也需要結合自己的情況進行優化，可以上來簡單的實踐明白難點，提出問題，為理論學習提供方向，理論學習中也可以不斷實踐，驗證自己的成果。

至於這個節奏，需要自己探索。

5. 「研究技術難點」

       在上面的內容都完成之後，就可以上手開發或維護了，如果還是不知道怎麼寫，照著之前的程式碼寫一條線就OK了。現在來說，應該可以說已經上手了。至於業務範圍內的具體技術難點，自己研究就好了。

小結：

這裡只是提供一個簡單的流程以作參考，相信在做過一些專案之後，這些已經成為一種本能或者習慣。如果你是技術大牛，有多年工作經驗的人，可能只需要瞭解一下需求，簡單走一遍程式碼，就可以很好的上手了。所以，如果說經驗較少，自己很不瞭解要做的專案，難以下手，可以參考一下流程，看看自己在什麼問題上止步不前。

最後，希望通過不斷的總結，將一些事情具體流程化，從而不斷自己的效率。