本身作為一個JAVA 開發人員，目前在公司已做了一年前端，最近部門一個參與重要任務的前端開發人員離職。他的很大一部分工作轉交給了我。現在還在交接期。寫博文記錄整個交接過程。

計劃：

1. 瞭解程式碼，瞭解業務，整理文件

            收集了相關的需求文件，簡單看了一下，一頭霧水。然後按照程式碼結構。自己用Excel畫了一個自己的理解的改專案架構圖。主要目的是加強自己對需求和程式碼的理解。對程式碼結構有了一個初步的理解。    --2018.7.30

            在測試的環境上面部署專案，實際操作該應用。和交接人交流了解業務流程，參考程式碼 的邏輯實現進行諮詢。   對程式碼結構 有了一個比較深入的裡瞭解，能夠基本明白每個模組的功能，在實際應用中對應哪塊實現。對實際業務有了一個初步的理解。 可以在測試的環境上配置主體功能   。-- 2018.7.31

           這幾天開發任務增多，沒有太多時間瞭解交接的工作。而且公司又有新的同時離職了。心態也比較浮躁。今天讓交接人整理了一份程式碼結構說明文件。打算明天以此為基礎再深入瞭解程式碼   。-- 2018.8.6

           這兩天重新讓交接人給自己講了一遍程式碼的邏輯。具體到每個模組的細節。一邊說明，自己也會提出一些問題。昨天開了需求會議，大致瞭解了這個專案幾乎未來半年的需求（無語......），又參考這個需求文件提問，對該專案和未來的需求多了一些瞭解。然後自己以前做的專案又有一批故障走過來，事情真多。 -- 2018.8.8

          交接人已正式離職，這段時間主要是故障驅動了解，配合後端和測試瞭解程式碼結構，也會尋思為什麼交接人的程式碼會什麼按照這個結構寫。總結起來交接人的編碼水平還是很高的。至少一些新增的需求都不會需要大批量去修改程式碼。雖然功能很複雜,程式碼邏輯也比較清晰，簡潔。未來需要再研究下程式碼裡面的邏輯結構，學習優秀的程式碼是怎麼寫的。--2018.8.14

2. 故障驅動加強

         處理了幾個簡單的故障，例如：自動化測試沒有給元件新增ID，沒有做某個簡單的引數校驗。--8.8

        處理故障：殘損業務修改前在前端新增校驗；某個引數格式下發錯誤，和傳統專案，後端開發，需求設計人員討論統一的規範。--8.10

        處理故障：有需求報文格式定義錯誤導致的故障，有可用性不好提出的故障，有很多故障都不是純粹的程式碼邏輯錯誤，需要配合測試，後端開發，需求人員，開發經理一起討論處理。--8.14

3. 著手新功能開發

       接收新功能開發：設定某個引數為自動配置，需要修改：介面展示，引數校驗，報文下發。分配工作量：3天。實際開發：2天。--8.14

經驗和總結：

       交期器算是正式結束了。半個月的過渡期。對這次新專案接手的經驗是：

       1. 對專案結構巨集觀的認識還是很重要的，包括具體的應用層面和程式碼層面。一定要將專案執行起來。自己多實際操作幾遍。這個過程可能需要多與測試人員，交接人，專案的其它開發人員多溝通。

       2.通過故障驅動開發，以及處理一些簡單的需求對於瞭解專案的細節很有幫助。在處理故障的過程中慢慢熟悉交接人的程式碼結構。

      3. 這次交接沒有涉及到新的技術，主要是業務層面的。如果涉及到新技術的交接。需要以後再積累經驗。