交接同事的專案，我的經驗談

隨著在這個行業的時間越長，漸漸開始會遇到要從同事那交接專案的時候。

我還記得第一次正式交接將離職的同事的專案時，我做的就是： clone 專案、複製 env 檔案、設定資料庫 ip、試著起服務，還有想辦法搞定本機的 python 環境 (在那之前沒怎麼寫過 python，專案是 django。)，然後聽同事介紹怎麼連上正式機和測試機，去手動部署。 基本上就是有什麼聽什麼，聽到什麼就趕快記下來，交接過程還錄音，以免之後想要回來重聽確認資訊。

後來再度遇到要交接了，這次不是一個 web 服務，而是資料處理的 pipeline，同事提供了處理 pipeline 的各台機器 ip、每台機器負責處理的任務、監測任務是否完成的儀表板、管理每台機器用的儀表板…，基本上就是「一個專案的官方介紹說明」。

隨著開發經驗越來越多，也開始有點想法，這次交接時，我開始主動找資訊：

• 如果今天遇到問題，你怎麼 debug? 你會從哪邊看？監測儀表板嗎？還是雲端服務的警告嗎？

• 最常發生問題的類型是什麼？多常發生？通常是以什麼樣的形式出現？是客戶來反應網站打不開嗎？還是你怎麼發現的？

• 接上一題：那你上次是怎麼解決的？

• 目前處理到一半的問題是什麼？是誰反映了什麼問題？你推測原因是什麼？處理到哪邊？我後續要怎麼觀察、判斷是不是修好了？

• 如果我想要實際跑跑看、測試看看，我可以用哪一組資料跑，而不會影響到別人？

以上幾點，可以總結說，是「用開發者的角度去假想專案」，來提出的問題。

另外也特別想補充，交接時，常常會過度專注在專案本身，但： 一個專案，code 裡面找得到的東西都不重要，最重要的是不在 code 裡面的東西，包含：

• 接了哪些外部服務？外部服務有沒有後台？有後台的話，帳號密碼是什麼？

• 開發過程總是要驗證，有些功能的驗證會牽涉到外部，例如：開發電商平台相關的功能時，常常就需要有「讓開發者測試用的線上商店」，用來安裝開發的服務，來進行測試。(不得不讚嘆一下 shopify 平台的強大生態系及開發者友善，可以一鍵生成測試商店，還幫你建好假資料)

「不在專案中的東西最重要」，這邊可以舉個例子：

一個服務的正式站、測試站，共用了一組外部服務的 key (譬如寄發 email 用的服務…舉例 Brevo 好了)。所以正式站跟測試站，兩者的操作，照理來說是分開的，但是對 Brevo 來說，兩個站都是在同一個帳號底下，等於共用了同一個資料 pool，導致會發生一些重複的資料建立失敗啦，或是兩個站的發信群組，在各自的服務中，是各自編號沒錯，但是到了 Brevo 卻變成編號重複了…之類的奇形怪狀的事。

以上，分享一些我的心得，希望對你有幫助。