可能不管新手老手有些程序員，接手一個項目之後都會多少有些迷惘。
以下是本人總結出來的一點小心得，如果錯誤希望大家給我留言，一起討論：
最重要的事兒
如果你總是看見代碼多就發愁，看見代碼髒亂差就詛咒埋怨，看見代碼邏輯複雜就頭疼，搞不清調用關係就放棄，那你可能永遠也變不成代碼的主人，只能一次又一次被代碼蹂躪。
所以，其實交接代碼最重要的事兒，就是：
不要被浩渺如煙並且陌生怪誕的代碼嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。
【注意心態】：不要以追求完美的心態去接手項目，不要試圖搞懂整個項目。
千萬不要找到對應的控制器方法，一行一行讀代碼！！！！因爲過去的功能已經完成了，需要修改該功能時，你才需要讀過去的代碼，方便修改。即使遇到不會使用的框架也不要緊，你知道業務邏輯後，可以直接寫原生。
要的是結果（老大要功能以最快的速度做出來），以任務爲第一。讓自己的價值先綻放出來，而不是自己的研究學習能力。否則，會出現，你研究了整個項目的框架結構，熟知了所有的技術要點，卻被無情的踢了出來，因爲你的價值並沒有表現出來。先站穩，再向上爬。必須對即將進行的階段學習有個預估
接手方法：不變應萬變
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、看控制器方法中，打印最後的結果，然後看視圖層，是怎麼展示的
