如果你總是看見**多就發愁，看見**髒亂差就詛咒埋怨，看見**邏輯複雜就頭疼，搞不清呼叫關係就放棄，那你可能永遠也變不成**的主人，只能一次又一次被**蹂躪。
所以，其實交接**最重要的事兒，就是：
不要被浩渺如煙並且陌生怪誕的**嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。
【注意心態】：不要以追求完美的心態去接手專案，不要試圖搞懂整個專案。
千萬不要找到對應的控制器方法，一行一行讀**！！！！因為過去的功能已經完成了，需要修改該功能時，你才需要讀過去的**，方便修改。即使遇到不會使用的框架也不要緊，你知道業務邏輯後，可以直接寫原生。
要的是結果（老大要功能以最快的速度做出來），以任務為第一。讓自己的價值先綻放出來，而不是自己的研究學習能力。否則，會出現，你研究了整個專案的框架結構，熟知了所有的技術要點，卻被無情的踢了出來，因為你的價值並沒有表現出來。先站穩，再向上爬。必須對即將進行的階段學習有個預估
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、看控制器方法中，列印最後的結果，然後看檢視層，是怎麼展示的
如何接手乙個專案
首先將專案 大目標 分為三個小目標 業務 技術 團隊運作。業務 請同事講一下，這個業務是做什麼的，解決什麼樣的問題，具體的業務流程是什麼樣子的。在這期間，不需要弄懂所有的細節，只需要建立起初步的框架。技術 你先得知道整個系統用到的技術棧，這樣你對系統用到的框架和工具就有數了。對外 系統對外提供哪些介...
如何快速接手乙個系統？
常規的做法是看設計文件 了解背景 維護 等。經過這一階段的體會，總結到以下可行的方法。a.先了解基本的框架 類庫的大概作用 b.從配置檔案入手，必須了解每乙個配置的含義，特別是該配置對應功能的實現邏輯。這對於維護系統 討論問題特別重要，如果連乙個配置都不知道，怎麼還能說在維護這個系統?c.把 重要的...
工作方法 快速接手乙個老專案
在公司裡面，最開始的並不是從零開始乙個專案，那是不可能的，而且作為乙個新手程式設計師，很多時候，給你的可能只是乙個小模組，或者是乙個老的專案維護，且以後者居多，結合最近接手別人的專案的情況，做一下乙個小的總結。原則 凡事多問，事無鉅細，做好驗證，不要怕麻煩別人 千萬不要怕自己問的問題比較弱智，沒關係...