【讀後總結】程序員修煉之道---從小工到專家

[TOC]

【讀後總結】程序員修煉之道---從小工到專家

一，我的讀後總結

本書相對比較基礎，不是那種大規模程序設計、高併發設計等等，主要是針對程序員的一些基本素質和一些基本常規編程設計作一些梳理和規範，對於初入職的程序員，養成這些良好素質是很是有必要的；對於已經入職多年的程序員，回顧一下本書，而後結合自身狀況看看是否可以基本達到本書中的一些素養也是有必要的。

總體而言，有必定的經驗性總結，相對來講比較基礎，對開發者也有必定的做用；對我我的而言，裏面不少的素養、設計規範之類都有必定了解，不過可能平時作的不夠完全，所以看完以後，仍是有必定的收穫，至少有了這樣的文檔性的總結，方便後續快速檢閱查看。

二，程序、架構設計方面

1，避免重複，進行復用

複用能夠減小代碼臃腫，也能夠下降改動風險（一個改動，要改動多處，容易遺漏），增長開發效率。以下幾個狀況可能會使得有重複的代碼，須要注意儘可能避免：

• 代碼模塊功能相似
• 不一樣語言要實現同一功能
• 不一樣開發者實現同一個相似功能

2，靈活的設計、隔離性

項目開發中，常常會遇到某個功能需求改變，或者某個底層資源改變，或者數據結構的改變，要作到撤銷的最小代價，注意項目永遠沒有最終最肯定的抉擇

代碼架構的設計要保持靈活性、隔離性、可替代性；如某種負載均衡算法的替換，如istio數據平面的替換等。

這個架構設計須要：

• 解耦

• 接口抽象

  • 抽象出各類不一樣接口，如虛基類、純虛基類、接口和實現

• 隱藏細節

  • 接口暴露的方式，須要隱藏一些私有的細節處理，對外暴露統一的外部方法

• 隔離

  • 如何保證互不影響，互無論理

• 元數據方式

3，解耦合【正交性】

劃分出細粒度的模塊，而後各個模塊之間解耦合，好比有一個函數的得墨忒耳法則.得墨忒耳定律也叫作「最少了解原理」，是一種軟件設計原理，尤爲是應用到面向對象的程序設計中，基本原理爲：

• 每一個對象對其餘對象只能有最少的瞭解：只有整體才能接近個別對象；
• 每一個對象只能和本身的朋友對話：不要和陌生人說話；
• 只和本身最親密的朋友對話。

必定儘可能不要開發設計出強耦合的系統，要劃分模塊、分層設計，這樣能夠提升效率，也能下降風險，不然，會牽一髮而動全身。最簡單的如MVC架構模型，上層應該能夠支持多種形態，改動一個模塊應該隻影響另一個模塊的調用而不是影響全局

每一個模塊的設計須要有暴露給外部的，同時也會須要有私有的。解耦合的設計的理念就是：

• 分層
• 分模塊
• 抽象

4，分層架構設計

程序架構要分層，分而治之，劃分不一樣功能的子模塊；劃分模塊以後，就要考慮模塊（子服務）之間如何通訊問題，經常使用的方案如：

• pub/sub：發佈訂閱模式

  • 只對感興趣事件進行訂閱

• MVC模式

  • Model-View-Controller

5，元數據的設計

用元數據（metadata）描述應用的配置選項、參數、用戶偏好等，不少程序設計中都用到了元數據，尤爲是一些開源的大型項目中，那麼元數據究竟是啥？元數據是指數據的數據，廣義上就是任何對應用描述的數據。如數據庫schema或數據詞典。schema含有名稱、存儲長度等屬性進行描述的屬性，咱們應該要能夠訪問和操做這些信息，就像對數據庫中任何其餘數據同樣。

典型狀況系，元數據應該在運行時而不是編譯時被訪問和使用。優雅的方式是使用元數據進行數據配置和驅動應用，達到這樣的目標：聲明式思考，也便是規定要作什麼而不是怎麼作，並建立高度靈活的程序。核心設計思想就是將抽象放進代碼，細節放進元數據，這樣的優點在於：

• 設計必需要解耦合，這樣會更靈活

• 須要建立更健壯、更抽象的設計；細節的處理推遲到程序以外

  • 這個，我尚未理解明白

• 可定製，如插件化，無需修改程序

6，軟件程序的併發和次序

時間是軟件架構的一個常常被忽略的方面，這裏的時間指的是程序自身的時間因素：

• 併發：同一時間發生多個事件
• 次序：事件在時間中的相對位置

尤爲是互聯網的開發設計中，併發是一個不可忽視的因子，設計之初就必需要考慮進來；如何防止併發衝突？如何保證高併發？

防止併發衝突，改善併發性，一個可能的原則就是分析工做流，能夠經過UML活動圖去分析。

另外，併發方面的編程，要考慮到多進程、多線程、多協程；服務端架構設計還要考慮高併發，如何擴縮容等

7，原型->基礎框架->逐漸填充

當需求並不明朗的時候，或者當須要從0到1的時候，能夠先快速搭建一個基礎框架，實現一個最簡單的訴求，固然須要劃分模塊、分層等基礎設計，不用太過複雜，先實現效果，而後逐漸填充和豐富，小版本重構和優化，最終造成一個大的項目

前期必定須要原型的配合，先構建原型出來，而後再逐步迭代優化，須要注意：

• 正確性
• 完整性
• 健壯性
• 風格

原型設計中須要考慮：

• 組件的定義和責任劃分是否清晰
• 耦合是否最小、是否細粒度
• 接口定義、約束是否知足訴求

8，進行預估和評審

任何項目都須要進行預估，預估一下總體時間、風險點、項目大小等；預估完了以後，進行初步設計，設計了以後須要再進行評審：

• 拆分組件、拆分模塊
• 細粒度組件、子模塊的預估
• 項目進度的預估
• 項目風險的預估
• 需求的評審
• 項目的評審
• 架構設計的評審

三，程序編碼方面

要不斷批判全部代碼，包括本身的和別人的！！！

1，理解代碼的工做原理

• 不要盲目的寫代碼，要先理清原理、需求、設計等等，最後纔是編碼

• 要制定階段性的規劃

• 思考全部可能的邊界並處理好全部邊界條件，不要靠猜

• 每一行代碼都要清楚含義，確保本身寫的代碼就是本身要表述的流程，對代碼白盒化

• 嚴格的測試用例、正常條件、異常條件

• copy原有代碼的時候，想一想，是否可以優化？原有代碼是否合適？

2，理清系統性能

要時刻估算程序的運行狀況，QPS=10w如何，QPS=100W如何？ QPS=1000W的時候又當如何？由於隨着變化，大多數狀況下都不是線性變化的。估算的範圍包括但不限於：系統的處理時間、佔用內存、CPU、磁盤io等

那如何估算？除了已有知識和經驗可以幫助估算外，還能夠進行建模估算：

• 循環
• 嵌套循環
• 二分法
• 分而治之
• 組合

3，代碼隨時重構

架構須要優化，代碼也隨時須要優化，前期的代碼總會有優化之處

當代碼出現重複、過期的知識、性能問題、耦合性太強的時候就必需要進行重構；並且咱們須要常常性的重構而且要早早的開始重構，不然越到後面，歷史包袱越大；每次迴歸本身的代碼，都要考慮，可否重構，能否更優？

若是後面一個項目copy或者沿用前一個項目，那麼後面的項目，必定要比前面的項目架構要更優，必定要作出改變，不然就不會有成長。

重構的時候須要注意一些技巧如：重構的時候不要新增功能，重構以前須要有較爲全面的單元測試用例，重構完了以後須要全面測試

4，編寫易於測試的代碼和豐富的測試用例

單元測試、集成測試

小模塊的測試

豐富的測試用例

示例代碼

5，按合約設計（DBC）

人不可能寫出十分完美的軟件，不符合預期的程序、接口時有發生，咱們須要防衛性的編碼，所以就是對方的都不可信任，好比輸入參數。

按合約設計的思想在於充分利用前置條件、後置條件、類不變項。其實意思就是一切要按照事先約定的合約進行，如何保證呢?那麼必須在設計的時候考慮：輸入域的範圍、邊界條件是如何、輸出數據是怎樣、能夠輸出什麼不能夠輸出什麼。

一些好的姿式包括：斷言、預處理、提早返回錯誤和崩潰。關於提早返回錯誤和崩潰的意義在於對於輸入的檢測上，要保證最初輸入的異常就返回而不用等到程序開始計算運行以後才返回

6，程序發生奔潰的處理

程序發生錯誤、奔潰是沒法避免的，可是咱們須要知道，若是錯誤已經發生，那麼表明程序必定在某些地方存在問題，尤爲是一些沒法必現的問題，那麼就須要咱們在錯誤發生以後可以有足夠的信息去分析它並fix它。檢查每個可能的錯誤，尤爲是意料以外的錯誤是一種良好的實踐。

若是程序發生一些極端錯誤以後，若是沒有終止程序，頗有可能致使後端數據產生髒數據或者後端請求出現批量異常等等。所以須要及早拋出異常

經過斷言來檢測輸入參數，在c、c++中是經常使用的優雅姿式，可是不要用斷言去處理真正的錯誤流程

處理好錯誤流程和異常處理流程、捕獲異常並進行處理，可是須要區分什麼狀況下才是真正的異常，這個可能須要根據實際狀況去分析

7，解決疑難雜症問題的思路

要知道，任何問題都有解決方案，只是你暫時沒有找到，或者沒有找到合適的。排查問題的方法：梳理出全部可能的路徑，先不要排除任何東西，而後逐一檢查並排除。

對於疑難雜症的重要的思考點：

• 這個問題是思路是否正確？注意力在這上面是否正確？
• 是否有更容易的方法？
• 爲何如此難以解決？
• 必須是這種方式解決嗎 ？
• 這個爲何是一個問題 ？
• 真的必須解決嗎 ？

四，項目管理相關

1，需求相關

項目是否可以成功？項目的各類需求？

業務項目而言，會有產品經理提需求；基礎項目而言，須要咱們開發人員本身挖掘需求、蒐集需求，其中最重要就是挖掘需求

一個典型例子：

• 只有指定人員才能查看檔案【good】
  • 這樣的需求過來，開發人員會設計一套權限管理系統，方便後續擴展
• 只有領導和人事部門才能查看檔案【bad】
  • 這樣的需求過來，開發人員可能只是作一個簡單的配置，進行前置靜態檢測
  • 只要需求改變，就可能沒法知足，甚至須要修改代碼

由於這就告訴咱們幾點：

• 需求頗有多是常常變更的，需求是否合理，如何知足日益變化的需求
• 需求的陳述表達
• 設計的時候必定要考慮後續的兼容性和擴展性
• 抽象很重要

2，思考清楚再開始啓動項目

若是有疑惑，必定要反覆思考清楚，等一塊兒都思考清楚，準備就緒後再開始編碼、項目設計。

由於一旦沒有思考清楚，極可能致使返工，或者是無用功，就怕就是折騰一兩個月後發現前面都作錯了！

3，程序的規範

程序須要有必定的規範，尤爲是多人協做的程序

4，自動化工做流程

工做流程自動化、項目自動化，構建、編譯、部署等；這個在咱們目前現有系統和工做中基本已經都是自動化了，如CI、CD等

5，各類類型的測試

自動化測試，早測試、常測試，測試佔編碼很大一部分；項目須要單元測試、集成測試；須要有必定的覆蓋度。主要測試種類包括：

• 單元測試
• 集成測試
• 驗證和校驗
• 性能測試
• 可用性測試
• 資源耗盡、錯誤和恢復

6，文檔和註釋

關於文檔方面，很重要，可是常常會發現文檔跟不上代碼節奏，能夠將代碼生成文檔。另外就是代碼註釋，註釋也常常跟不上代碼節奏。所以須要注意文檔和註釋的編寫、及時更新等

五，其餘零散經驗

• 對象屬性的讀寫不要直接暴露字段，應該用方法封裝，方便將來調整，也可以保持一致性

• 檢查每個可能的錯誤，尤爲是意料以外的錯誤是一種良好的實踐。

• 經過斷言來檢測輸入參數，在c、c++中是經常使用的優雅姿式，可是不要用斷言去處理真正的錯誤流程

• 元數據的設計

【"歡迎關注個人微信公衆號：Linux 服務端系統研發，後面會大力經過微信公衆號發送優質文章"】