在公司裡面，最開始的並不是從零開始乙個專案，那是不可能的，而且作為乙個新手程式設計師，很多時候，給你的可能只是乙個小模組，或者是乙個老的專案維護，且以後者居多，結合最近接手別人的專案的情況，做一下乙個小的總結。
原則：凡事多問，事無鉅細，做好驗證，不要怕麻煩別人(千萬不要怕自己問的問題比較弱智，沒關係的，畢竟接手的有可能是個爛攤子，如果交接的人連這些問題都懶得給你答覆，那你接手的八成是個大坑)
在接手的時候，需要獲取的材料和資訊，務必做好記錄，這會成為你以後交接給別人或者有新的開發人員加入的時候，最節省你時間的材料
專案原始碼位址，版本管理軟體是svn/git
專案需求文件，確認是最新版
專案設計文件，pdm，用到的框架，各個包的設計關係，確認是最後開發的對應的版本
專案介面文件，必須要有，這是和前端互動或者和其他系統互動的規範，一旦沒有這個文件，到時候所有的需求就都會壓到後端身上
開發環境搭建指南，專案啟動配置
專案開發遺留問題，必須要求交接的人整理乙份，已有的bug，未開發的功能，做好標註
資料庫表設計關係
獲取了材料之後：
由交接人員給演示系統的主要功能和操作方式，錄屏或者截圖做好記錄
搭建本地開發環境，如果有提供搭建指南，就按照指南確認可操作性，有錯誤就改正，如果沒有提供操作指南，那麼需要自己手寫乙份，記錄資訊
本地開發環境啟動之後，確認功能，明白每個選單和按鈕的功能，以及關係，對應到資料庫表的哪些，最好做好記錄，後端的功能不多，一般都是乙個業務流程鏈，記錄好截圖和操作方式，方便提供給測試
根據介面文件閱讀**，主要是看介面，跟蹤除錯乙個主功能
bug測試，挑一兩個bug重現，嘗試是否能夠理解如何修復這個bug
新需求開發，同上
關鍵：多問，多記錄
如何接手乙個專案
首先將專案 大目標 分為三個小目標 業務 技術 團隊運作。業務 請同事講一下，這個業務是做什麼的，解決什麼樣的問題，具體的業務流程是什麼樣子的。在這期間，不需要弄懂所有的細節，只需要建立起初步的框架。技術 你先得知道整個系統用到的技術棧，這樣你對系統用到的框架和工具就有數了。對外 系統對外提供哪些介...
如何快速接手乙個系統？
常規的做法是看設計文件 了解背景 維護 等。經過這一階段的體會，總結到以下可行的方法。a.先了解基本的框架 類庫的大概作用 b.從配置檔案入手，必須了解每乙個配置的含義，特別是該配置對應功能的實現邏輯。這對於維護系統 討論問題特別重要，如果連乙個配置都不知道，怎麼還能說在維護這個系統?c.把 重要的...
程式設計師怎麼快速接手乙個專案
如果你總是看見 多就發愁，看見 髒亂差就詛咒埋怨，看見 邏輯複雜就頭疼，搞不清呼叫關係就放棄，那你可能永遠也變不成 的主人，只能一次又一次被 蹂躪。所以，其實交接 最重要的事兒，就是 不要被浩渺如煙並且陌生怪誕的 嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。注意...