優秀的程序猿應具備哪些編程思維

關於優秀的程序猿應具備哪些編程思維，我也經常問自己這個問題，所以這篇文章聊聊對編程思維的看法，當然我的從業經驗有限，不會講得太學院派，主要是從項目開發過程的實操角度來講，因此下面講的一些觀點有局限性，歡迎大家留言拍磚或向我提問題。

一．面向對象而不是基於對象的思維

當前大部分編程語言如Java、C++、Python等等，都是支持面向對象編程特性的，這幾年我當面試官時經常會問這個問題：你是如何理解面向對象思想的？很多求職者現場都能熟練背書般說出面向對象的三大特性：繼承、封裝、多態，再問如何使用面向對象進行分析和設計就基本上就答不上來了，感覺他們對面向對象思想的認識僅僅停留在熟記這些概念上，基本都會在簡歷中寫上自己熟悉面向對象思想，但實際上卻沒能真正理解掌握和運用它，更別說具備面向對象的程序設計和開發能力去解決問題了。同時在項目開發過程中，你也會發現好些童鞋編寫出來的代碼僅僅是基於對象而不是面向對象的，也就是說還停留在面向對象的初級階段，什麼是基於對象？即是僅僅用了面向對象的封裝特性，把各種業務邏輯處理簡單地封裝成對象，然後雜亂無章地使用這些對象來實現業務，而面向對象是對業務的客觀世界關係邏輯進行抽象，並利用面向對象的封裝、繼承和多態的特性進行對象的設計，判斷是否做到面向對象主要看對象的關係結構是否使用了繼承和多態進行科學合理地設計，有沒「科學合理地設計」是它們的本質區別。

面向對象是一種思維方式，正確運用它使我們更好地進行軟體編碼構建、組織以及復用，但要想掌握這種思維方式並不簡單，面向對象的結構化和模塊化編碼思維方式需要通過不斷地思考和實踐運用才能獲得，然而很多企業基本都有自己相對成熟的技術體系和架構，很多程序猿只需紙葫蘆畫瓢地寫代碼實現業務邏輯即可，不會主動去學習和思考，這樣幾年下來編程思維方面將毫無提升，這一定程度上減弱了他們的編程能力，所以應該多看那些優秀的開源代碼或牛人寫的代碼，並認真思考自己的每一次的編碼設計，及時進行總結和思考，你將會從中逐漸獲得面向對象的正確編程思維。

二．軟體工程的設計思維

1.一些重要的系統設計原則

當我們理解和掌握了需求的全貌后就要開始系統設計，如網路服務架構和代碼架構設計以及技術方案的選型等，這時我們應把握好如下設計原則，總之系統設計不是尋求萬能的解決方案，而是追求合適和簡單，越簡單越好。

把握好CAP原則

CAP是指一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）。

一致性（Consistency）。

一致性指「all nodes see the same data at the same time」，即更新操作成功並返回客戶端完成後，所有節點在同一時間的數據完全一致。

可用性（Availability）

可用性指「Reads and writes always succeed」，即服務一直可用，而且是正常響應時間。

分區容錯性（Partition tolerance）

分區容錯性指「the system continues to operate despite arbitrary message loss or failure of part of the system」，即分散式系統在遇到某節點或網路分區故障的時候，仍然能夠對外提供滿足可用性的服務。

CAP理論認為：一個分散式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）三項中的兩項。通過CAP理論，我們知道無法同時滿足三個特性，那要捨棄哪個呢？對於多數大型互聯網應用的場景來說，主機眾多、部署分散，而且現在的集群規模越來越大，所以節點故障、網路故障是常態，當出現故障時可以降級服務，即保證P和A，捨棄C，雖然會影響用戶體驗，但沒達到造成應用無法服務的嚴重程度。

用好BASE原則

BASE是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）三個原則。

基本可用是指分散式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。如電商應用促銷時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也降級服務，這即是損失部分可用性的做法。

軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。

最終一致性是指系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況，在互聯網應用大量使用數據同步和分散式緩存即是數據最終一致性做法。

BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性是強一致性）時應用可採用適合的方式達到最終一致性（Eventual Consitency），因此互聯網應用應該遵循BASE原則來進行系統設計是科學合理的。

2.一些重要的資料庫設計原則

其實編碼大多時候是在跟數據打交道，即代碼是圍繞數據結構編寫的。良好的數據結構可以提升性能，使代碼變得簡單、清晰，數據結構清晰，圍繞著數據操作的代碼自然就清晰。所以我們在進行數據表結構設計要充分考慮如下設計原則。

滿足當前需求

這點無需贅述，數據表結構設計必須得滿足當前需求。

適當冗餘

為了提高性能，利用空間換時間是常用的方法，所以適當的冗餘是必要的，嚴格追求第三範式是不現實的，能做到第二範式已很不錯了。

適應可能的需求變化

設計就要考慮需求一定範圍的變化，所以預留一些表欄位設計適應可能發生的需求變化是完全合理的設計，當然不能過度設計。

應對數據量的高速增長

在設計表結構時要充分考慮好業務數據的增長速度及查詢條件欄位的情況，如果數據量在短時間內會快速增長且讀寫頻繁的數據，那就要考慮分表甚至是分庫，如果是爆增的一般不適合資料庫存儲了，要考慮大數據等存磁碟的技術實現方式。

3.一些重要的面向對象編碼設計（即程序設計）原則

實現業務功能不是如何去完成代碼而是如何設計和組織代碼，注意，是如何設計和組織代碼，設計和組織代碼除了要用到面向對象的思維外，個人認為還須重點把握如下5個編碼設計原則。

代碼重用原則(Code Reuse is Good)

重用代碼能提高代碼的可讀性，縮短開發時間。即是我們常說一些工具類和基類方法等抽出來，免得重複造輪子。

單一職責原則(Single Responsibility Principle)

低耦合原則(Minimize Coupling)

代碼的任何一部分應該減少對其他區域代碼的依賴關係，盡量不要使用共享參數。低耦合是完美結構系統和優秀設計的標誌。

開閉原則(Open/Closed Principle)

即對擴展是開放的而對修改是關閉的，這意味著模塊的行為方法是可擴展的。當需求改變時，我們可對模塊進行擴展，使其具有滿足那些改變的新行為，也即是說我們可以改變模塊的功能，對模塊行為進行擴展時，不必改動模塊的源代碼。這個原則比較難掌握，可在不斷編碼設計的思考總結中實現。

三．做懂業務的技術人

很多程序猿在進行編碼實現業務功能時不太願意想太多，只是照本宣科根據需求文檔按需實現出來，至於為什麼要做這樣的業務功能，其對業務運營作用有多大？有無更好技術代替方案？一概不想，只為做需求而做需求，只做需求翻譯機，做得更好些的主動進行技術優化， 在我看來，程序猿只做需求翻譯機和技術優化機是遠遠不夠的，要想成為優秀的程序猿必須成為懂業務的技術人，這樣有助於我們更準確理解把握好需求並能優質地實現業務功能，做產品的主人，能為產品運營提供更多技術支持，同時能為運營尋找更多技術驅動的業務點!

商戰智庫

乾貨，商業模式，老闆高管人手必備！

↑↑↑