一周的閃念膠囊，總有一個能幫助到你

• 2020 年 1 月 14 日
• 筆記

1、不管是做需求還是測試，都應該考慮整個鏈路，確保兼容性或者其他模組不受影響。比如內容創作改動，應該考慮到審核側、內容分發側是否正常。

2、需求一定要經過測試。不要站在自己的角度，以為測試人員無法測試某種場景。因為方法總比困難多，比如可以把鏈路當中修改的點單獨拎出來進行對比測試。還要多提一點的是，盡量在程式碼修改處添加日記，確保測試能覆蓋到。

3、輸出日記時也要避免空指針異常。如果在業務邏輯中不會出現空指針異常，卻在輸出日記時拋異常，那真的是冤大頭了。

4、批量回刷或者刪數據有風險，特別是無法恢復的物理硬刪除。所以此類場景應該由用戶主動觸發，而不是藉助定時任務批量執行。

5、數據和操作行為應該足夠方便溯源。比如圖片上傳、批量刪除數據。

6、程式碼上線時間也應該當成需求時間。當團隊嚴格控制程式碼上線流程，比如技術方案評審、程式碼評審、提測、灰度發布、線上監控，你就會發現上線成本還是很高的。所以，管理好開發隊列變得很重要。而秘決在於，品質優先，效率第二。

7、上游依賴介面檢查。不只是要檢查可用，還要檢查準確度和品質。比如每頁返回的數據量是否正常、返回的數據是否滿足合規性和可用性。

8、避免過度設計。某些歷史的實體POJO類的欄位類型千奇百怪，可能是包裝類Integer，也可能是基本類型Int，那麼在MyBatis框架中使用xml定義一個大而全的SQL，比如使用<if test="picNum !=null">來拼接Update方法，很容易將不需要處理的數據清空。當然根本原因是POJO定義的問題，不過這是歷史原因了，此時再修改它裡面的欄位類型，成本很高。所以，此時最好的方式是，新增的方法只更新它需要的，不要過度設計，不要急著考慮通用性。

9、開閉原則。它的意思是對擴展開放，對修改關閉。這個設計原則其實我們每天都在接觸，比如方法入參定義為實體對象，當需要新增一個參數時無需修改參數列表，只需要在實體類中新增一個欄位即可。這個原則的作用是應對變化的時候，還能夠保證系統的穩定性。

10、依賴倒置原則,低層模組依賴高層模組，它們都依賴抽象。上游依賴屬於原子類，具體細節不應該混雜在業務程式碼中。那樣程式碼復用性差，而且當該業務方法出問題時，不能直接判斷是否是業務程式碼的缺陷還是某個上游依賴的缺陷。甚至上游介面需要升級切換時，使用到它的都需要進行翻新，得不償失。所以上游介面盡量抽象出來並且添加相應監控。

11、增強系統健壯性。主動檢測不支援的情況並拋出異常，避免系統產生不可預期的結果，比如首先進行參數校驗再處理業務。很簡單的操作，但是可以有效增強系統的健壯性。