關於程序設計的一些基本原則

敬畏每一行代碼

調整代碼時，一定要盡最大努力評估對業務的影響，並告知相關負責人。這是一個做事的方法和態度問題。

正確性

程序必須滿足需求，健壯。

安全性

需要限制用戶非法訪問系統和資源，對重要操作記錄審計日誌。

可測試性和可維護性

程序不只是讓機器來運行，也不是只有作者一個來閱讀的。因此程序必須容易閱讀，便於單元測試，集成測試。在筆者工作的幾家互聯網公司中也經常發現程序不好維護，不好測試的情況。這樣會導致在後續日常開發中，有種無從下手，重構又看不懂代碼，最後只能擱淺將就。這是一種很不好的現象，我們必須樹立正確的做事態度，然後把這些不好的地方盡量改善到最優。這是一個優秀程序員的基本素養。

容量評估

處理數據時，要考慮容量有多大。評估影響範圍，針對大數據量，可能要考慮對其它業務的影響，比如大量寫入數據會導致同步鏈非同步複製壓力增大。

性能

基於功能需求及非功能需求，對性能設定一個目標。比如京東618，淘寶又11，可能會評估峰值，會壓測到10倍，甚至100倍的流量峰值。

消息處理要考慮是否需要保證順序性，是否需要冪等性

我們一般都喜歡順序地去幹事情，比如回到家打開門，放下背包，然後開始準備做飯。在程序開發中也會經常遇到這種場景，比如在插入待辦時，可能會先刪除相關待辦，再插入新的相關待辦。如果這兩個地方依次向MQ發送消息，有可能這兩個消息分別被兩個處理器接收到，那麼就有可能刪除操作在插入之後執行。這樣就導致程序邏輯錯誤。

易用性

程序正確，安全，性能好是基本需求，我們還要考慮如何讓用戶易於使用，交互是否繁瑣，能不能盡量讓用戶少操作。需要考慮實際使用場景和條件限制，比如用戶工作的現場網路不穩定，或都需要自費流量等等。

監控

我們需要對程序的運行進行各種指標的監控，比如是否可用，內存佔用，CPU佔用是否正常，磁碟佔用是否異常，可用空間是否充足。在日常運營中還隨時關注異常郵件，並對一些關鍵日常進行復盤分析，並進行優化處理等等。尤其是在上線後幾天里要重點關注一下。

向後兼容

我們現在主要使用微服務架構，比如我們現在的產品主要使用dubbo來實現微服務架構。那麼我們在產品迭代過程中就要考慮向後兼容問題。比如一個dubbo服務，被很多業務使用。某一天，作者重構代碼，想把一個欄位的類型從Integer調整為enum。如果不升級jar的版本號，直接修改，然後只發布了服務，沒有發布各個依賴的業務，那麼就會出現各個業務無法繼續使用這個服務的問題。那麼這種dubbo介面的變化會引起服務調用失敗的問題，如何才能檢測出來？？？

冒煙所有功能？如果不能冒煙所有功能就可能出現問題。

強制限定，介面、實體只能加不能改，保證向後兼容性。 結合

在開發過程開始之前以及開發過程中，要有明確的分析及設計，合理劃分程序結構、類，確保職責單一，易於維護，易於擴展，易於測試。比如我在一個複雜Job的開始過程中，將所有功能開始在一個類中，所有功能由一個入口函數組裝起來，結果發現性能很差，不便於測試，不便於非同步化，不便於監控，不便於分片處理。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！