關(guān)于優(yōu)秀的程序猿應(yīng)具備哪些編程思維褥蚯，我也經(jīng)常問自己這個問題，所以這篇文章聊聊對編程思維的看法妈橄，當然我的從業(yè)經(jīng)驗有限庶近，不會講得太學院派，主要是從項目開發(fā)過程的實操角度來講眷蚓，因此下面講的一些觀點有局限性鼻种，歡迎大家留言拍磚或向我提問題。

一．面向?qū)ο蠖皇腔趯ο蟮乃季S

當前大部分編程語言如Java沙热、C++叉钥、Python等等，都是支持面向?qū)ο缶幊烫匦缘母菝常@幾年我當面試官時經(jīng)常會問這個問題：你是如何理解面向?qū)ο笏枷氲耐抖樱亢芏嗲舐氄攥F(xiàn)場都能熟練背書般說出面向?qū)ο蟮娜筇匦裕豪^承、封裝爵川、多態(tài)动知，再問如何使用面向?qū)ο筮M行分析和設(shè)計就基本上就答不上來了，感覺他們對面向?qū)ο笏枷氲恼J識僅僅停留在熟記這些概念上橄登，基本都會在簡歷中寫上自己熟悉面向?qū)ο笏枷氚揪＃珜嶋H上卻沒能真正理解掌握和運用它，更別說具備面向?qū)ο蟮某绦蛟O(shè)計和開發(fā)能力去解決問題了兔甘。同時在項目開發(fā)過程中谎碍，你也會發(fā)現(xiàn)好些童鞋編寫出來的代碼僅僅是基于對象而不是面向?qū)ο蟮模簿褪钦f還停留在面向?qū)ο蟮某跫夒A段洞焙，什么是基于對象蟆淀？即是僅僅用了面向?qū)ο蟮姆庋b特性，把各種業(yè)務(wù)邏輯處理簡單地封裝成對象澡匪，然后雜亂無章地使用這些對象來實現(xiàn)業(yè)務(wù)熔任，而面向?qū)ο笫菍I(yè)務(wù)的客觀世界關(guān)系邏輯進行抽象，并利用面向?qū)ο蟮姆庋b唁情、繼承和多態(tài)的特性進行對象的設(shè)計疑苔，判斷是否做到面向?qū)ο笾饕磳ο蟮年P(guān)系結(jié)構(gòu)是否使用了繼承和多態(tài)進行科學合理地設(shè)計，有沒“科學合理地設(shè)計”是它們的本質(zhì)區(qū)別甸鸟。

面向?qū)ο笫且环N思維方式惦费，正確運用它使我們更好地進行軟件編碼構(gòu)建兵迅、組織以及復用，但要想掌握這種思維方式并不簡單薪贫，面向?qū)ο蟮慕Y(jié)構(gòu)化和模塊化編碼思維方式需要通過不斷地思考和實踐運用才能獲得恍箭，然而很多企業(yè)基本都有自己相對成熟的技術(shù)體系和架構(gòu)，很多程序猿只需紙葫蘆畫瓢地寫代碼實現(xiàn)業(yè)務(wù)邏輯即可瞧省，不會主動去學習和思考扯夭，這樣幾年下來編程思維方面將毫無提升，這一定程度上減弱了他們的編程能力鞍匾，所以應(yīng)該多看那些優(yōu)秀的開源代碼或牛人寫的代碼交洗，并認真思考自己的每一次的編碼設(shè)計，及時進行總結(jié)和思考候学，你將會從中逐漸獲得面向?qū)ο蟮恼_編程思維藕筋。

二．軟件工程的設(shè)計思維

1.一些重要的系統(tǒng)設(shè)計原則

當我們理解和掌握了需求的全貌后就要開始系統(tǒng)設(shè)計，如網(wǎng)絡(luò)服務(wù)架構(gòu)和代碼架構(gòu)設(shè)計以及技術(shù)方案的選型等梳码，這時我們應(yīng)把握好如下設(shè)計原則隐圾，總之系統(tǒng)設(shè)計不是尋求萬能的解決方案，而是追求合適和簡單掰茶，越簡單越好暇藏。

把握好CAP原則

CAP是指一致性（Consistency）、可用性（Availability）和分區(qū)容錯性（Partition tolerance）濒蒋。

一致性（Consistency）盐碱。

一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客戶端完成后沪伙，所有節(jié)點在同一時間的數(shù)據(jù)完全一致瓮顽。

可用性（Availability）

可用性指“Reads and writes always succeed”，即服務(wù)一直可用围橡，而且是正常響應(yīng)時間暖混。

分區(qū)容錯性（Partition tolerance）

分區(qū)容錯性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡(luò)分區(qū)故障的時候翁授，仍然能夠?qū)ν馓峁M足可用性的服務(wù)拣播。

CAP理論認為：一個分布式系統(tǒng)最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯性（Partition tolerance）三項中的兩項收擦。通過CAP理論贮配，我們知道無法同時滿足三個特性，那要舍棄哪個呢塞赂？對于多數(shù)大型互聯(lián)網(wǎng)應(yīng)用的場景來說泪勒，主機眾多、部署分散，而且現(xiàn)在的集群規(guī)模越來越大酣藻，所以節(jié)點故障曹洽、網(wǎng)絡(luò)故障是常態(tài)鳍置，當出現(xiàn)故障時可以降級服務(wù)辽剧，即保證P和A，舍棄C税产，雖然會影響用戶體驗怕轿，但沒達到造成應(yīng)用無法服務(wù)的嚴重程度。

用好BASE原則

BASE是指基本可用（Basically Available）辟拷、軟狀態(tài)（ Soft State）撞羽、最終一致性（ Eventual Consistency）三個原則。

基本可用（Basically Available）

基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時候衫冻，允許損失部分可用性诀紊，即保證核心可用。如電商應(yīng)用促銷時隅俘，為了應(yīng)對訪問量激增邻奠，部分用戶可能會被引導到降級頁面，服務(wù)層也降級服務(wù)为居，這即是損失部分可用性的做法碌宴。

軟狀態(tài)（Soft State）

軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性蒙畴。分布式存儲中一般一份數(shù)據(jù)至少會有三個副本贰镣，允許不同節(jié)點間副本同步的延時就是軟狀態(tài)的體現(xiàn)。

最終一致性（Eventual Consistency）

最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后膳凝，最終能夠達到一致的狀態(tài)碑隆。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況蹬音，在互聯(lián)網(wǎng)應(yīng)用大量使用數(shù)據(jù)同步和分布式緩存即是數(shù)據(jù)最終一致性做法上煤。

BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency祟绊，CAP的一致性是強一致性）時應(yīng)用可采用適合的方式達到最終一致性（Eventual Consitency）楼入，因此互聯(lián)網(wǎng)應(yīng)用應(yīng)該遵循BASE原則來進行系統(tǒng)設(shè)計是科學合理的。

2.一些重要的數(shù)據(jù)庫設(shè)計原則

其實編碼大多時候是在跟數(shù)據(jù)打交道牧抽，即代碼是圍繞數(shù)據(jù)結(jié)構(gòu)編寫的嘉熊。良好的數(shù)據(jù)結(jié)構(gòu)可以提升性能，使代碼變得簡單扬舒、清晰阐肤，數(shù)據(jù)結(jié)構(gòu)清晰，圍繞著數(shù)據(jù)操作的代碼自然就清晰。所以我們在進行數(shù)據(jù)表結(jié)構(gòu)設(shè)計要充分考慮如下設(shè)計原則孕惜。

滿足當前需求

這點無需贅述愧薛，數(shù)據(jù)表結(jié)構(gòu)設(shè)計必須得滿足當前需求。

適當冗余

為了提高性能衫画，利用空間換時間是常用的方法毫炉，所以適當?shù)娜哂嗍潜匾模瑖栏褡非蟮谌妒绞遣滑F(xiàn)實的削罩，能做到第二范式已很不錯了瞄勾。

適應(yīng)可能的需求變化

設(shè)計就要考慮需求一定范圍的變化，所以預(yù)留一些表字段設(shè)計適應(yīng)可能發(fā)生的需求變化是完全合理的設(shè)計弥激，當然不能過度設(shè)計进陡。

應(yīng)對數(shù)據(jù)量的高速增長

在設(shè)計表結(jié)構(gòu)時要充分考慮好業(yè)務(wù)數(shù)據(jù)的增長速度及查詢條件字段的情況，如果數(shù)據(jù)量在短時間內(nèi)會快速增長且讀寫頻繁的數(shù)據(jù)微服，那就要考慮分表甚至是分庫趾疚，如果是爆增的一般不適合數(shù)據(jù)庫存儲了，要考慮大數(shù)據(jù)等存磁盤的技術(shù)實現(xiàn)方式以蕴。

3.一些重要的面向?qū)ο?/b>編碼設(shè)計（即程序設(shè)計）原則

實現(xiàn)業(yè)務(wù)功能不是如何去完成代碼而是如何設(shè)計和組織代碼糙麦，注意，是如何設(shè)計和組織代碼舒裤，設(shè)計和組織代碼除了要用到面向?qū)ο蟮乃季S外喳资，個人認為還須重點把握如下5個編碼設(shè)計原則。

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

重用代碼能提高代碼的可讀性腾供，縮短開發(fā)時間仆邓。即是我們常說一些工具類和基類方法等抽出來，免得重復造輪子伴鳖。

單一職責原則(Single Responsibility Principle)

任一方法代碼的功能應(yīng)該保證只有單一的明確的執(zhí)行任務(wù)节值。

低耦合原則(Minimize Coupling)

代碼的任何一部分應(yīng)該減少對其他區(qū)域代碼的依賴關(guān)系，盡量不要使用共享參數(shù)榜聂。低耦合是完美結(jié)構(gòu)系統(tǒng)和優(yōu)秀設(shè)計的標志搞疗。

開閉原則(Open/Closed Principle)

即對擴展是開放的而對修改是關(guān)閉的，這意味著模塊的行為方法是可擴展的须肆。當需求改變時匿乃，我們可對模塊進行擴展，使其具有滿足那些改變的新行為豌汇，也即是說我們可以改變模塊的功能幢炸，對模塊行為進行擴展時，不必改動模塊的源代碼拒贱。這個原則比較難掌握宛徊，可在不斷編碼設(shè)計的思考總結(jié)中實現(xiàn)佛嬉。

三．做懂業(yè)務(wù)的技術(shù)人

很多程序猿在進行編碼實現(xiàn)業(yè)務(wù)功能時不太愿意想太多，只是照本宣科根據(jù)需求文檔按需實現(xiàn)出來闸天，至于為什么要做這樣的業(yè)務(wù)功能暖呕，其對業(yè)務(wù)運營作用有多大？有無更好技術(shù)代替方案苞氮？一概不想湾揽，只為做需求而做需求，只做需求翻譯機葱淳，做得更好些的主動進行技術(shù)優(yōu)化钝腺，在我看來抛姑，程序猿只做需求翻譯機和技術(shù)優(yōu)化機是遠遠不夠的赞厕，要想成為優(yōu)秀的程序猿必須成為懂業(yè)務(wù)的技術(shù)人，這樣有助于我們更準確理解把握好需求并能優(yōu)質(zhì)地實現(xiàn)業(yè)務(wù)功能定硝，做產(chǎn)品的主人皿桑，能為產(chǎn)品運營提供更多技術(shù)支持，同時能為運營尋找更多技術(shù)驅(qū)動的業(yè)務(wù)點!

注：部分資料摘自網(wǎng)絡(luò)蔬啡。

文/阿青诲侮，寫代碼寫詩寫職場的程序猿大叔，傾力原創(chuàng)簡單實用的硬干貨箱蟆，轉(zhuǎn)載此文請聯(lián)系阿青沟绪。