來自 PTT shter (飛梭之影)的經驗談，但不論是哪一種語言或系統，接手不熟悉專案時的基本起手式約都是：找系統「啟動點」、功能「呼叫點」、下手去「嘗試改」、用業務來「猜測邏輯」，最重要的，已經運行良好的系統，可千萬不要因為自以為是而改壞了！
 |
| Photo by Sigmund on Unsplash |
將 shter (飛梭之影)的步驟整理如下，供日後埋下技術債的自己參考：
- 掌握啟動前的入口：大部分程式語言都會有一個從作業系統下命令開始執行的進入點，可能會載入 config、環境變數、命令參數這些東西，要先清楚這些東西的配置意義是什麼
- 掌握啟動後的入口：如果是 Server或常駐程式，在執行階段就會有監聽行為。可能來自於 http API、socket、message hook、Redis subscribe ....要嘗試找到這些呼叫點的function，嘗試塞 log或 print出來，追蹤一些上下游關係，然後學習用工具打約定好的通訊格式測試，像 postman或去 redis丟 pub
- 嘗試動動手腳：掌握入口後，就知道哪邊會像大腦發出命令，而要讓程式將命令傳達到該去的地方。所以要先假定一個起點跟終點，比如 rabbitMQ 收到訊息經過邏輯運算會將結果存進 redis某個 key值，那就去追 function的資料流向以及中途被包裝成什麼樣的資料結構，最後又轉成什麼樣的字串存 redis
- 起身連續動作：獨立的資料處理都掌握的差不多後，接著就要看系統 state machine跟 life cycle結構的運作模型，自己去新增一些狀態、設計一些複雜的腳本看看程式運作的結果跟預期是否相同。配合前面三點，自己去修改 config丟不同參數、開發一個測試的入口，然後呼叫已知的 function卻在邏輯中判斷命令夾帶自定義的 config參數並達成某些狀態條件時要引導至自己另外寫的 function寫 log，這樣就有辦法介入原有程式並增加新功能
- 外部工具先學有用到的部分：例如 redis 寫資料有很多命令，set, hset, rpush ..每個的用法和適合的場景不同，照理說科班教育會讓你全部學懂避免誤用才去實作。但你接手別人程式面對陌生工具時，其實是要反過來根據程式的資料結構去搞清楚這個指令的用法。先別浪費時間知道他們存在 redis 內有何差別，現階段要看的只是在程式內從介面定義讀回來的資料長什麼樣子。除非個人很有興趣
（而且時間多），否則訓練自己在 code內看到對 redis 呼叫的指令能快速從文件中找到用法說明更重要 - 一知半解下的行車紀錄：到這階段差不多你就可以開發新需求，但會有很長一段時間你覺得自己是在一知半解下做出新功能的。很多時候是從 try error發現一條可以正確執行完的路就走了，然後不知道狀態或資料變了會產生 side effect。別慌！在你不懂的地方加註解，給個編號，然後在自己的文件中寫上編號並紀錄起來。當 side effect 發生時，你有機會從文件中判斷可能與哪幾條有關，去 code搜尋註解所在檔案有助縮小判斷的範圍
- 不要改壞勝過不要怕改壞：有些人會說就是要放膽去改不要怕壞！從零開發是如此，因為那是自己寫的，掌握度高，又沒有曾經穩定運作的印象，壞就壞了再修就好。但今天是在很多東西沒摸熟不懂的情況下，接一個已架構好的系統，維持運作穩定才不會給自己找麻煩，老闆對你的新人印象才會好。一堆需求進來，先挑自己有把握的，並告訴 PM想先上但你會花超過預期時間的東西。大多專案管理者會同意先完成一個不起眼的功能，完勝引人注目卻花超久時間還搞不定的需求。在穩定中累積經驗也累積自信，再慢慢往可能改壞的功能開發
- 換輪胎：過一陣子可能突然發現好多新功能自己其實重複造了輪子，只是當初看不出來某個 function 跟你寫的目的相同。研究對方寫法，你會柳暗花明又一村；這時候你的思考邏輯會漸漸與原作者同化，突然開竅了，看懂很多東西了，這才是你可以開始不要怕改壞準備對模組重構或大展身手的階段。
看完你可能還會想要：
沒有留言:
張貼留言