>[danger]【注意心態】：不要以追求完美的心態去接手項目，不要試圖搞懂整個項目。 千萬不要找到對應的控制器方法，一行一行讀代碼！！！！<span style="color:red;">因為過去的功能已經完成了，需要修改該功能時，你才需要讀過去的代碼，方便修改</span>。即使遇到不會使用的框架也不要緊，你知道業務邏輯后，可以直接寫原生。 &nbsp; 要的是結果（老大要功能以最快的速度做出來），<span style="color:red;">以任務為第一。讓自己的價值先綻放出來</span>，而不是自己的研究學習能力。否則，會出現，你研究了整個項目的框架結構，熟知了所有的技術要點，卻被無情的踢了出來，因為你的價值并沒有表現出來。先站穩，再向上爬。必須對即將進行的階段學習有個預估 # :-: 代碼看不懂怎么辦 如果你總是看見代碼多就發愁，看見代碼臟亂差就詛咒埋怨，看見代碼邏輯復雜就頭疼，搞不清調用關系就放棄，那你可能永遠也變不成代碼的主人，只能一次又一次被代碼蹂躪。 所以，其實交接代碼最重要的事兒，就是： 不要被浩渺如煙并且陌生怪誕的代碼嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。  # :-: 接手方法：不變應萬變 1.項目維護有三寶：溝通 、文檔 、代碼跑。目標：了解業務邏輯流。 這三點很好理解，<span style="color:red;">初步接手要請教前輩給你點一點業務重點、難點，讓自己熟悉下</span>；接著就是看系統的文檔了，可以讓自己迅速的了解整個項目的方方面面；最后就是走代碼，因為前輩的指點可能有誤，文檔的書寫可能有漏，作為一個優秀的程序員只相信自己走的代碼，用自己的代碼去驗證文檔，才是最正確的做法。文檔只是給了你方向。走代碼才能真實的了解具體的業務邏輯 2.重點攻擊：數據結構+ER模型。目的：熟知項目的數據結構關系。 其實從事多年的老鳥可以發現，不管是C/S或者B/S，怎樣的開發<span style="color:red;">最后都是無非是底層數據庫的數據排列篩選好后傳遞到前臺</span>。所以對待一個新的項目，去研究它的數據結構和庫表是很有效的。這就要求我們對數據結構這塊進行深入研究。 項目出活四部曲，跟、改、理、測要一起。 1. 跟：抓住一個功能點，深入的調試跟蹤流程，分析代碼直到弄明白為止。 2. 改：修改源代碼，編譯運行，看修改前后有什么變化，這是感知代碼用途的最佳途徑。 3. 理：嘗試弄清整個項目的業務邏輯 4. 測：熟悉業務邏輯后，清庫測試，測驗是否符合自己所想。