程式設計師怎麼快速接手一個專案
可能不管新手老手有些程式設計師，接手一個專案之後都會多少有些迷惘。
以下是本人總結出來的一點小心得，如果錯誤希望大家給我留言，一起討論：
最重要的事兒
如果你總是看見程式碼多就發愁，看見程式碼髒亂差就詛咒埋怨，看見程式碼邏輯複雜就頭疼，搞不清呼叫關係就放棄，那你可能永遠也變不成程式碼的主人，只能一次又一次被程式碼蹂躪。
所以，其實交接程式碼最重要的事兒，就是：
不要被浩渺如煙並且陌生怪誕的程式碼嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。
【注意心態】：不要以追求完美的心態去接手專案，不要試圖搞懂整個專案。
千萬不要找到對應的控制器方法，一行一行讀程式碼！！！！ 因為過去的功能已經完成了，需要修改該功能時，你才需要讀過去的程式碼，方便修改 。即使遇到不會使用的框架也不要緊，你知道業務邏輯後，可以直接寫原生。
要的是結果（老大要功能以最快的速度做出來），以任務為第一。讓自己的價值先綻放出來，而不是自己的研究學習能力。否則，會出現，你研究了整個專案的框架結構，熟知了所有的技術要點，卻被無情的踢了出來，因為你的價值並沒有表現出來。先站穩，再向上爬。必須對即將進行的階段學習有個預估
接手方法：不變應萬變
1.專案維護有三寶：溝通 、文件 、程式碼跑。目標：瞭解業務邏輯流。
這三點很好理解，初步接手要請教前輩給你點一點業務重點、難點，讓自己熟悉下；接著就是看系統的文件了，可以讓自己迅速的瞭解整個專案的方方面面；最後就是走程式碼，因為前輩的指點可能有誤，文件的書寫可能有漏，作為一個優秀的程式設計師只相信自己走的程式碼，用自己的程式碼去驗證文件，才是最正確的做法。文件只是給了你方向。走程式碼才能真實的瞭解具體的業務邏輯
2.重點攻擊：資料結構+ER模型。目的：熟知專案的資料結構關係。
其實從事多年的老鳥可以發現，不管是C/S或者B/S，怎樣的開發最後都是無非是底層資料庫的資料排列篩選好後傳遞到前臺。所以對待一個新的專案，去研究它的資料結構和庫表是很有效的。這就要求我們對資料結構這塊進行深入研究。
專案出活四部曲，跟、改、理、測要一起。
- 跟：抓住一個功能點，深入的除錯跟蹤流程，分析程式碼直到弄明白為止。
- 改：修改原始碼，編譯執行，看修改前後有什麼變化，這是感知程式碼用途的最佳途徑。
- 理：嘗試弄清整個專案的業務邏輯
- 測：熟悉業務邏輯後，清庫測試，測驗是否符合自己所想。
維護實用技巧：
- 任何舉動要備份
- 修改程式碼涉及到很多的依賴，所以新增程式碼相對而言風險較小。（時間充足：對方法進行包裝或者重寫，甚至是直接修改）。
- 多和原設計人員交流；
總結：要不停的試，不停的改
通用步驟：
1、找nginx的配置檔案，看看專案放在伺服器的哪個地方（由於是接手多個專案，都是以虛擬主機來放的）| 5分鐘
2、找對該專案熟悉的產品經理或同事（也包括測試）給你演示一把怎麼用，順便請教下主要功能。 | 30-60分鐘
分開問，軟體不會用，講邏輯找產品；
某些技術、程式碼看不懂，問搭檔；
整體專案的把控問專案經理；
3、小試牛刀：先熟悉軟體的前後臺各種操作，能體驗的都體驗一把（嘗試修改某個功能，有好多個環境，在本地改）。
4、記錄專案中該領域的專業詞語，找機會和同事請教，弄懂這個詞在這個領域是個什麼概念
思路1的具體步驟（從上而下）：
5、開啟f12看network找他前後臺菜單中對應的控制器（有的請求是在html中用a標籤跳轉的）。找到每個功能的對應的【增刪改查】或每個功能對應的方法名稱。如有沒見過看不懂的罕見寫法，查該版本的手冊，切記，統一框架不同版本的同一個方法用法可能都不一致
6、看他每個功能對應的控制器方法中的sql語句的構成
7、通過echo列印原生的sql語句（TP框架，拿sql語句的物件->getLastSql()），看查出來的結果是什麼，及通過檢視渲染到頁面的資料
8、看他的資料庫設計，先在心裡把表分個類（如 使用者的、商品的），然後找外來鍵關係
9、不要看完就了事，看完是記不住的，過倆天也都忘了。在舊專案中新建個控制器，模擬個功能點，模擬人家寫的方式，自己寫套增刪改查操作資料庫，展示給頁面
思路2的具體步驟（從下而上）：
1、先看公共函式庫，傳正確和錯誤的引數，分別測試，看出來的是什麼東西。不要看函式中的每一行程式碼
2、多層繼承的話，看他父類，父父類中，大概都有哪些方法，這些方法是做什麼的，在心裡記個大概
3、看控制器方法中，列印最後的結果，然後看檢視層，是怎麼展示的
