做了十年的技術(shù)，我從來(lái)都沒(méi)有放棄過(guò)它，相反，我非常熱愛(ài)它，因?yàn)槲乙恢币詠?lái)都很喜歡學(xué)習(xí)，希望能學(xué)到更多的東西，這樣遇到了具體的技術(shù)問(wèn)題，可以隨時(shí)從自己積累的知識(shí)庫(kù)中找到最佳的解決方案。此外，目前我在公司雖然不怎么寫(xiě)代碼了，但我還是會(huì)利用自己工作閑暇之余寫(xiě)一點(diǎn)開(kāi)源項(xiàng)目或者代碼框架等。

工作過(guò)很多大大小小的公司，那么公司最值錢(qián)的東西是什么呢？

我認(rèn)為是實(shí)實(shí)在在做事情的程序員們。

他們雖然工資不高，每天坐在位置上敲著代碼，在很多人眼中被稱為“屌絲”或“宅男”，但我認(rèn)為恰恰就是這些人，他們才是公司最有價(jià)值的人。

他們有自己的理想，希望能夠通過(guò)自己的努力，從中得到那一點(diǎn)點(diǎn)所謂的成就感；

他們需要理解產(chǎn)品經(jīng)理真正的意圖，把想法變成現(xiàn)實(shí)，讓產(chǎn)品真正落地；

他們更容易把握細(xì)節(jié)，而這些細(xì)節(jié)往往決定著產(chǎn)品的命運(yùn)與成敗；

他們突如其來(lái)的跳槽，對(duì)我們的項(xiàng)目的交付有直接的影響；

他們?cè)谝黄鸸ぷ鞯臍夥?#xff0c;能體現(xiàn)技術(shù)公司的文化與底蘊(yùn)。

由此看來(lái)，對(duì)程序員的重視是相當(dāng)有必要的，我們需要關(guān)心每一位程序員的職業(yè)發(fā)展，讓他們?cè)趫F(tuán)隊(duì)里能夠充分地發(fā)揮出自己的能力。

我們也需要對(duì)他們倍加關(guān)注，挖掘出有能力、肯吃苦、敢擔(dān)當(dāng)?shù)娜?#xff0c;給他們更多的機(jī)會(huì)，讓他們成為技術(shù)領(lǐng)袖。

互聯(lián)網(wǎng)技術(shù)公司需要大量這樣的程序員：

他們是一群有著技術(shù)信仰的人，他們是一群熱愛(ài)編程的人，他們是一群不解決問(wèn)題睡不好覺(jué)的人；

他們不是打雜的，不是外包，更不是工具；

他們不喜歡被忽悠，不喜歡被冷落，更不喜歡被驅(qū)動(dòng)；

他們需要尊重，需要培養(yǎng)，更需要激情！

具體說(shuō)說(shuō)程序員需要具備哪些素質(zhì)。

我個(gè)人是這樣理解真正的程序員的：

深愛(ài)技術(shù)，一天不寫(xiě)代碼手就會(huì)癢，就喜歡那種成就感；

為了一個(gè)問(wèn)題可以廢寢忘食，有時(shí)會(huì)在夢(mèng)中都能寫(xiě)代碼；

代碼潔癖癥患者，喜歡優(yōu)雅代碼，寫(xiě)代碼就像寫(xiě)詩(shī)一樣；

善于分析問(wèn)題，能快速看清問(wèn)題的本質(zhì)，并動(dòng)手解決它；

喜歡研究?jī)?yōu)秀源碼，學(xué)習(xí)大師的杰作，善于歸納與總結(jié)；

有自己的開(kāi)源項(xiàng)目或技術(shù)博客，喜歡學(xué)習(xí)，更喜歡分享；

會(huì)關(guān)注技術(shù)圈子的新聞動(dòng)態(tài)，時(shí)常會(huì)參加線下技術(shù)沙龍；

知道軟件開(kāi)發(fā)不是一個(gè)人在戰(zhàn)斗，更需要的是團(tuán)隊(duì)協(xié)作；

保持良好健康的心態(tài)，用一顆積極向上的心去擁抱變化。

十年的職場(chǎng)之路堅(jiān)持不易，分享下我的「IT 職場(chǎng)」經(jīng)驗(yàn)。

時(shí)光飛逝，我事業(yè)中第一個(gè)十年已然結(jié)束了。在這十年里，讓我收獲了很多，跟大家分享一下我在 IT 職場(chǎng)方面的一些個(gè)人經(jīng)驗(yàn)，不一定對(duì)每個(gè)人都實(shí)用，請(qǐng)大家僅作參考吧。

大家既然都是做技術(shù)的，那我們不妨先從技術(shù)這個(gè)話題開(kāi)始說(shuō)起吧。我要與大家分享的第一點(diǎn)經(jīng)驗(yàn)就是：

1. 把技術(shù)當(dāng)成工具

技術(shù)這東西，其實(shí)一點(diǎn)都不神秘，它只不過(guò)是一個(gè)工具，用這個(gè)工具可以幫助我們解決實(shí)際問(wèn)題，就這么簡(jiǎn)單。

我們每天在面對(duì)技術(shù)，市面上也有很多技術(shù)，真的沒(méi)有必要把這些技術(shù)都拿過(guò)來(lái)學(xué)習(xí)一遍，然后想辦法找個(gè)場(chǎng)景去應(yīng)用它。如果真的這樣做了，那么只能說(shuō)明技術(shù)不是工具，而是玩具，技術(shù)不是這樣玩的。

我們應(yīng)該從另一個(gè)角度來(lái)看待技術(shù)，不妨從自己的實(shí)際工作環(huán)境出發(fā)，現(xiàn)在需要什么，我們就學(xué)什么，而不要漫無(wú)目的的追求一些新技術(shù)。當(dāng)然，對(duì)于新技術(shù)還是需要有所關(guān)注的，至少需要知道這個(gè)新技術(shù)是干什么用的，而且還要善于總結(jié)，將有價(jià)值的技術(shù)收集起來(lái)，以備將來(lái)使用，當(dāng)需要使用的時(shí)候再來(lái)深入研究。

人的精力是有限的，人的生命也是短暫的，要善于利用自己的時(shí)間，合理地學(xué)習(xí)技術(shù)。

不要把技術(shù)看得那么重要，別把它當(dāng)回事兒，把它當(dāng)工具就行了，它就像我們寫(xiě)字的筆一樣，用鉛筆能寫(xiě)字，用鋼筆一樣能寫(xiě)字。

作為一名技術(shù)人員，除了學(xué)習(xí)與應(yīng)用技術(shù)以外，還需要為自己做一個(gè)正確的職業(yè)規(guī)劃，清晰認(rèn)識(shí)自己究竟屬于哪種技術(shù)人才，是技術(shù)專家類型的，還是技術(shù)管理類型的。路到底該怎么走？需要自己做出決定。

在我們職業(yè)路線上，最重要的人莫過(guò)于老板（我指的老板可以是公司大老板，也可以是自己的頂頭上司），對(duì)待自己的老板，我也有一些經(jīng)驗(yàn)：

2. 把老板當(dāng)成情人

大家應(yīng)該非常清楚，情人是需要浪漫的，浪漫是需要驚喜的。老板其實(shí)跟情人一樣，也是需要驚喜的。我們做下屬的，要懂得找到合適的機(jī)會(huì)給老板帶來(lái)驚喜。我們跟情人談情說(shuō)愛(ài)，這是一種很好的溝通方式，可別忽略了跟老板“談情說(shuō)愛(ài)”，我們需要與老板保持良好的溝通，這種溝通并不僅僅是溜須拍馬。

講一個(gè)真實(shí)的故事吧。記得曾經(jīng)我的一位同事，技術(shù)非常好，做東西非常快，質(zhì)量也很高，同事們都覺(jué)得他是牛人，但他從來(lái)都不懂得在老板面前表現(xiàn)自己，老板也只是覺(jué)得他是可以做事的，但升職加薪的事情往往總是不會(huì)優(yōu)先考慮他。

大家很定會(huì)問(wèn)：怎樣在老板面前表現(xiàn)自己呢？其實(shí)方法有很多，由于篇幅有限，我先提供三招吧：

第一招：在給老板做程序演示的時(shí)候，不要只是單純的演示，不妨先用一個(gè) PPT，簡(jiǎn)單表達(dá)一下自己的解決方案，然后再做演示，這樣效果會(huì)好很多。老板會(huì)認(rèn)為自己是花了心思的，是想把事情做得更好的。

第二招：把自己每天的工作簡(jiǎn)單記錄一下，每周匯總一次，以郵件的形式發(fā)送給老板，讓老板知道自己每天在做什么。每月寫(xiě)一篇本月工作總結(jié)與下月工作計(jì)劃，同樣發(fā)郵件給老板。年底可以寫(xiě)一個(gè)年終工作總結(jié)，打印出來(lái)，悄悄地放在老板的桌子上。

第三招：借匯報(bào)工作為理由，定期請(qǐng)老板出去吃飯，制造面對(duì)面單獨(dú)溝通的機(jī)會(huì)。在談話過(guò)程中，強(qiáng)調(diào)自己愿意幫助老板分擔(dān)工作壓力。

對(duì)待老板其實(shí)很簡(jiǎn)單，只要能幫他做事，又能讓他開(kāi)心，他基本上就搞定了。老板搞定了，自己的職業(yè)發(fā)展才會(huì)平步青云。但千萬(wàn)別忽略了還有一群人，他們或許是自己的團(tuán)隊(duì)?wèi)?zhàn)友，或許是自己的競(jìng)爭(zhēng)對(duì)手，沒(méi)錯(cuò)！他們就是同事。如何處理同事關(guān)系呢？以下便是我的經(jīng)驗(yàn)：

3. 把同事當(dāng)成小孩

處理與同事關(guān)系，其實(shí)比處理與老板關(guān)系要稍微復(fù)雜一點(diǎn)，因?yàn)橥掠卸喾N身份，他們可以是隊(duì)友，也可以是對(duì)手。如果大家在一起做同一個(gè)項(xiàng)目，那么這樣的同事就是隊(duì)友；如果為了競(jìng)爭(zhēng)某個(gè)項(xiàng)目、崗位、資源，導(dǎo)致同級(jí)別的同事之間發(fā)生利益上的競(jìng)爭(zhēng)，那么這樣的同事就是對(duì)手。

對(duì)于隊(duì)友而言，要學(xué)會(huì)主動(dòng)給他們提供幫助，讓大家能夠體會(huì)到團(tuán)隊(duì)協(xié)作的氣氛，在一起學(xué)習(xí)，在一起成長(zhǎng)，在一起分享?？梢詴r(shí)常跟大家一起聚餐，買(mǎi)點(diǎn)零食讓大家品嘗。

隊(duì)友關(guān)系往往比較好處理，關(guān)鍵在于自己能否真正懂得去分享。很多技術(shù)人員，最不愿意的就是分享，因?yàn)閾?dān)心自己花了很多精力學(xué)到的知識(shí)，分分鐘就被別人學(xué)會(huì)了，自己失去了優(yōu)勢(shì)。這種心態(tài)最好不要在團(tuán)隊(duì)里產(chǎn)生，這樣只會(huì)讓自己變得越來(lái)越封閉，越來(lái)越渺小，隊(duì)友們也會(huì)逐漸排擠自己。

對(duì)于對(duì)手而言，要想辦法讓自己成為他的兄弟，告訴他，咱們是兄弟，應(yīng)該相互幫助。如果有機(jī)會(huì)，可以在老板面前，當(dāng)著對(duì)手的面，夸獎(jiǎng)自己的對(duì)手。做出這樣的行為，其實(shí)并不會(huì)讓老板覺(jué)得自己不如對(duì)手，而會(huì)讓老板認(rèn)為自己在用心去容納對(duì)手。大家在一起工作，就是一種緣分，都是跟老板打工的，真的沒(méi)有必要搞得不愉快。

其實(shí)同事就是自己的小伙伴，不妨把他們當(dāng)成是單純可愛(ài)的小孩吧，用自己的心去“收買(mǎi)”他們。

老板與同事，他們都是公司內(nèi)部的人，不管怎么說(shuō)，大家都在同一條船上，大家可以關(guān)上門(mén)吵一架，只要事情能夠解決就行。但對(duì)于我們的客戶而言，就需要用另外一種方法來(lái)處理好關(guān)系了。我是這樣認(rèn)為的：

4. 把客戶當(dāng)成病人

客戶有需求，但沒(méi)有技術(shù)，而我們有技術(shù)、有經(jīng)驗(yàn)、有產(chǎn)品，正好可以幫助他們實(shí)現(xiàn)需求，從而提高他們的工作效率，這樣客戶才會(huì)心甘情愿地把錢(qián)放入我們的口袋。所以，在客戶面前，我們要表現(xiàn)出高超的專業(yè)精神，不要被客戶牽著我們的鼻子走，我們?cè)诳蛻裘媲熬褪羌夹g(shù)權(quán)威，就需要這樣的自信。從服裝、言行、郵件、文檔等各個(gè)方面，都要做到專業(yè)。

我們打算把自己的產(chǎn)品賣給客戶的時(shí)候，千萬(wàn)不要一上來(lái)就對(duì)自己的產(chǎn)品夸夸其談，這往往會(huì)讓客戶感到厭煩。我們不妨先告訴客戶，他們已經(jīng)“生病”了，而且病得不輕，如果不及時(shí)用藥的話，后果將不堪設(shè)想。也就是說(shuō)，要讓客戶意識(shí)到自己現(xiàn)在所面臨的困境，讓客戶緊張，當(dāng)他們正在思考如何應(yīng)對(duì)的時(shí)候，我們?cè)俑嬖V他們，“藥”已經(jīng)準(zhǔn)備好了，可以隨時(shí)服用。

要讓客戶有種雪中送炭的感覺(jué)，這樣就對(duì)了，他們一定會(huì)主動(dòng)了解我們的產(chǎn)品。我們要做到這一切，必須花精力來(lái)分析行業(yè)現(xiàn)狀，揣測(cè)客戶老板們每天在想什么。如果有機(jī)會(huì)進(jìn)入客戶所在的公司工作一段時(shí)間，相信自己的感受會(huì)更加深入。

Java 會(huì)在很長(zhǎng)的一段時(shí)間內(nèi)是主流

為什么開(kāi)發(fā) Java Web 都要用框架？

我個(gè)人覺(jué)得框架有以下幾點(diǎn)作用：

讓開(kāi)發(fā)更加高效，屏蔽底層技術(shù)細(xì)節(jié)，讓開(kāi)發(fā)人員關(guān)注在具體業(yè)務(wù)上。

框架實(shí)際上也是一種規(guī)范，可以讓每位開(kāi)發(fā)人員保持同樣的編碼風(fēng)格。

會(huì)使用主流框架的開(kāi)發(fā)人員，在人才市場(chǎng)上比較好獲取。

現(xiàn)在做 Java Web 開(kāi)發(fā)都用哪些框架呢？

常用的比如 Spring MVC、Struts2 等，國(guó)內(nèi)的 JFinal、Nutz 等也不錯(cuò)，當(dāng)然 Smart 也是一個(gè)很好的選擇。

有一定 Web 前端開(kāi)發(fā)經(jīng)驗(yàn)的人，很多都會(huì)有這么個(gè)想法：那些寫(xiě)框架的人好厲害，什么時(shí)候我才能寫(xiě)一個(gè)自己的框架呢？有時(shí)候看看別人的框架代碼，又覺(jué)得很復(fù)雜，對(duì)此我有一些建議以及新人學(xué)習(xí)需要什么基礎(chǔ)？分享一些好的方法。

對(duì)于接觸 Java 不太久的朋友，建議按照以下幾個(gè)步驟來(lái)學(xué)習(xí)：

學(xué)習(xí) Java 基礎(chǔ)語(yǔ)法與核心技術(shù)，包括 Servlet、JSP、JDBC 等。

熟練使用流行開(kāi)源框架，包括 Spring、MyBatis 等。

研究開(kāi)源框架源碼，并吸取其中優(yōu)秀的架構(gòu)。

此外，在學(xué)習(xí)的過(guò)程當(dāng)中，建議做學(xué)習(xí)筆記，最好能通過(guò)博客的方式來(lái)記錄自己的收獲。

使用 Python、Perl、PHP、Ruby 等腳本語(yǔ)言開(kāi)發(fā) Web 程序，跟使用 Java 開(kāi)發(fā) Web 程序相比有什么不同或者優(yōu)劣？

前者屬于動(dòng)態(tài)語(yǔ)言，無(wú)需編譯，可通過(guò)解釋的方式來(lái)運(yùn)行，而且 Java 需要首先通過(guò)編譯，將源文件轉(zhuǎn)為字節(jié)碼，且載入 Java 虛擬機(jī)才能運(yùn)行，相對(duì)來(lái)說(shuō)，Java 對(duì)環(huán)境的要求較高，但 Java 具備更強(qiáng)的面向?qū)ο竽芰Α４送?#xff0c;Java 還擁有較廣的開(kāi)源社區(qū)以及流行的開(kāi)源中間件。因此，如果是做大型系統(tǒng)，建議使用 Java 來(lái)開(kāi)發(fā)，而并非那些腳本語(yǔ)言。

針對(duì) Web，Java、PHP、Python、.NET 之中未來(lái)發(fā)展前景最好的會(huì)是什么？

我認(rèn)為 Java 在未來(lái)還會(huì)有一段很長(zhǎng)的路，需要在語(yǔ)言本身上做到更加輕量級(jí)，用最少的代碼來(lái)實(shí)現(xiàn)目標(biāo)功能；PHP 相對(duì)來(lái)說(shuō)會(huì)比較平穩(wěn)，它的特點(diǎn)非常突出，上手快且易于開(kāi)發(fā) Web 項(xiàng)目；Python 仍然不會(huì)有太大的用戶群體；.NET 加入開(kāi)源社區(qū)太晚，且較 Java 而言并沒(méi)有太強(qiáng)的優(yōu)勢(shì)，可能會(huì)走下坡路。

在軟件開(kāi)發(fā)中有很多的設(shè)計(jì)模式，也有一些很高冷，談?wù)勎覍?duì)軟件設(shè)計(jì)的理解，以及讓一些設(shè)計(jì)原則接地氣。

了解設(shè)計(jì)模式的朋友們，想必都聽(tīng)說(shuō)過(guò)“六大設(shè)計(jì)原則”吧。其實(shí)最經(jīng)典的 23 種設(shè)計(jì)模式中或多或少地都在使用這些設(shè)計(jì)原則，也就是說(shuō)，設(shè)計(jì)模式是站在設(shè)計(jì)原則的基礎(chǔ)之上的。所以在學(xué)習(xí)設(shè)計(jì)模式之前，很有必要對(duì)這些設(shè)計(jì)原則先做一下了解。

GoF（四人幫），傳說(shuō)中的四位大神們，他們聯(lián)手搞出了一套設(shè)計(jì)模式，堪稱 OOD（面向?qū)ο笤O(shè)計(jì)）的經(jīng)典之作！震驚了整個(gè)軟件開(kāi)發(fā)領(lǐng)域。但這四個(gè)老家伙非常怪異，總是喜歡顯擺一些高深的理論，甚至有時(shí)候不說(shuō)人話，十分讓人費(fèi)解。

除了最經(jīng)典的六大設(shè)計(jì)原則以外，還有一些其他的設(shè)計(jì)原則也非常重要。我將盡可能地解釋這些晦澀的理論，希望看完之后，會(huì)讓您對(duì)這些設(shè)計(jì)原則稍微加深一些理解。若有不正確的地方，懇請(qǐng)大家指正！

六大設(shè)計(jì)原則

先看一幅圖吧：

這幅圖清晰地表達(dá)了六大設(shè)計(jì)原則，但僅限于它們叫什么名字而已，它們具體是什么意思呢？下面我將從原文、譯文、理解、應(yīng)用，這四個(gè)方面分別進(jìn)行闡述。

1. 單一職責(zé)原則（Single Responsibility Principle - SRP）

原文：There should never be more than one reason for a class to change.

譯文：永遠(yuǎn)不應(yīng)該有多于一個(gè)原因來(lái)改變某個(gè)類。

理解：對(duì)于一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因。說(shuō)白了就是，不同的類具備不同的職責(zé)，各施其責(zé)。這就好比一個(gè)團(tuán)隊(duì)，大家分工協(xié)作，互不影響，各做各的事情。

應(yīng)用：當(dāng)我們做系統(tǒng)設(shè)計(jì)時(shí)，如果發(fā)現(xiàn)有一個(gè)類擁有了兩種的職責(zé)，那就問(wèn)自己一個(gè)問(wèn)題：可以將這個(gè)類分成兩個(gè)類嗎？如果真的有必要，那就分吧。千萬(wàn)不要讓一個(gè)類干的事情太多！

2. 開(kāi)放封閉原則（Open Closed Principle - OCP）

原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.

譯文：軟件實(shí)體，如：類、模塊與函數(shù)，對(duì)于擴(kuò)展應(yīng)該是開(kāi)放的，但對(duì)于修改應(yīng)該是封閉的。

理解：簡(jiǎn)言之，對(duì)擴(kuò)展開(kāi)放，對(duì)修改封閉。換句話說(shuō)，可以去擴(kuò)展類，但不要去修改類。

應(yīng)用：當(dāng)需求有改動(dòng)，要修改代碼了，此時(shí)您要做的是，盡量用繼承或組合的方式來(lái)擴(kuò)展類的功能，而不是直接修改類的代碼。當(dāng)然，如果能夠確保對(duì)整體架構(gòu)不會(huì)產(chǎn)生任何影響，那么也沒(méi)必要搞得那么復(fù)雜了，直接改這個(gè)類吧。

3. 里氏替換原則（Liskov Substitution Principle - LSP）

原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

譯文：使用基類的指針或引用的函數(shù)，必須是在不知情的情況下，能夠使用派生類的對(duì)象。

理解：父類能夠替換子類，但子類不一定能替換父類。也就是說(shuō)，在代碼中可以將父類全部替換為子類，程序不會(huì)報(bào)錯(cuò)，也不會(huì)在運(yùn)行時(shí)出現(xiàn)任何異常，但反過(guò)來(lái)卻不一定成立。

應(yīng)用：在繼承類時(shí)，務(wù)必重寫(xiě)（Override）父類中所有的方法，尤其需要注意父類的 protected 方法（它們往往是讓您重寫(xiě)的），子類盡量不要暴露自己的 public 方法供外界調(diào)用。

該原則由麻省理工學(xué)院的 Barbara Liskov 女士提出，她是美國(guó)第一位獲取計(jì)算機(jī)博士學(xué)位的女性，曾經(jīng)也獲得過(guò)計(jì)算機(jī)圖靈獎(jiǎng)。

4. 最少知識(shí)原則（Least Knowledge Principle - LKP）

原文：Only talk to you immediate friends.

譯文：只與你最直接的朋友交流。

理解：盡量減少對(duì)象之間的交互，從而減小類之間的耦合。簡(jiǎn)言之，一定要做到：低耦合，高內(nèi)聚。

應(yīng)用：在做系統(tǒng)設(shè)計(jì)時(shí)，不要讓一個(gè)類依賴于太多的其他類，需盡量減小依賴關(guān)系，否則，您死都不知道自己怎么死的。

該原則也稱為“迪米特法則（Law of Demeter）”，由 Ian Holland 提出。這個(gè)人不太愿意和陌生人說(shuō)話，只和他走得最近的朋友們交流。

5. 接口隔離原則（Interface Segregation Principle - ISP）

原文：The dependency of one class to another one should depend on the smallest possible interface.

譯文：一個(gè)類與另一個(gè)類之間的依賴性，應(yīng)該依賴于盡可能小的接口。

理解：不要對(duì)外暴露沒(méi)有實(shí)際意義的接口。也就是說(shuō)，接口是給別人調(diào)用的，那就不要去為難別人了，盡可能保證接口的實(shí)用性吧。她好，我也好。

應(yīng)用：當(dāng)需要對(duì)外暴露接口時(shí)，需要再三斟酌，如果真的沒(méi)有必要對(duì)外提供的，就刪了吧。一旦您提供了，就意味著，您將來(lái)要多做一件事情，何苦要給自己找事做呢。

6. 依賴倒置原則（Dependence Inversion Principle - DIP）

原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

譯文：高層模塊不應(yīng)該依賴于低層模塊，它們應(yīng)該依賴于抽象。抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴于抽象。

理解：應(yīng)該面向接口編程，不應(yīng)該面向?qū)崿F(xiàn)類編程。面向?qū)崿F(xiàn)類編程，相當(dāng)于就是論事，那是正向依賴（正常人思維）；面向接口編程，相當(dāng)于通過(guò)事物表象來(lái)看本質(zhì)，那是反向依賴，即依賴倒置（程序員思維）。

應(yīng)用：并不是說(shuō)，所有的類都要有一個(gè)對(duì)應(yīng)的接口，而是說(shuō)，如果有接口，那就盡量使用接口來(lái)編程吧。

將以上六大原則的英文首字母拼在一起就是 SOLID（穩(wěn)定的），所以也稱之為 SOLID 原則。

只有滿足了這六大原則，才能設(shè)計(jì)出穩(wěn)定的軟件架構(gòu)！但它們畢竟只是原則，只是四人幫給我們的建議，有些時(shí)候我們還是要學(xué)會(huì)靈活應(yīng)變，千萬(wàn)不要生搬硬套，否則只會(huì)把簡(jiǎn)單問(wèn)題復(fù)雜化，切記！

補(bǔ)充設(shè)計(jì)原則

1. 組合 / 聚合復(fù)用原則（Composition/Aggregation Reuse Principle - CARP）

當(dāng)要擴(kuò)展類的功能時(shí)，優(yōu)先考慮使用組合，而不是繼承。這條原則在 23 種經(jīng)典設(shè)計(jì)模式中頻繁使用，如：代理模式、裝飾模式、適配器模式等?？梢?jiàn)江湖地位非常之高！

2. 無(wú)環(huán)依賴原則（Acyclic Dependencies Principle - ADP）

當(dāng) A 模塊依賴于 B 模塊，B 模塊依賴于 C 模塊，C 依賴于 A 模塊，此時(shí)將出現(xiàn)循環(huán)依賴。在設(shè)計(jì)中應(yīng)該避免這個(gè)問(wèn)題，可通過(guò)引入“中介者模式”解決該問(wèn)題。

3. 共同封裝原則（Common Closure Principle - CCP）

應(yīng)該將易變的類放在同一個(gè)包里，將變化隔離出來(lái)。該原則是“開(kāi)放 - 封閉原則”的延生。

4. 共同重用原則（Common Reuse Principle - CRP）

如果重用了包中的一個(gè)類，那么也就相當(dāng)于重用了包中的所有類，我們要盡可能減小包的大小。

5. 好萊塢原則（Hollywood Principle - HP）

好萊塢明星的經(jīng)紀(jì)人一般都很忙，他們不想被打擾，往往會(huì)說(shuō)：Don’t call me, I’ll call you. 翻譯為：不要聯(lián)系我，我會(huì)聯(lián)系你。對(duì)應(yīng)于軟件設(shè)計(jì)而言，最著名的就是“控制反轉(zhuǎn)”（或稱為“依賴注入”），我們不需要在代碼中主動(dòng)的創(chuàng)建對(duì)象，而是由容器幫我們來(lái)創(chuàng)建并管理這些對(duì)象。

其他設(shè)計(jì)原則

1. 不要重復(fù)你自己（Don’t repeat yourself - DRY）

不要讓重復(fù)的代碼到處都是，要讓它們足夠的重用，所以要盡可能地封裝。

2. 保持它簡(jiǎn)單與傻瓜（Keep it simple and stupid - KISS）

不要讓系統(tǒng)變得復(fù)雜，界面簡(jiǎn)潔，功能實(shí)用，操作方便，要讓它足夠的簡(jiǎn)單，足夠的傻瓜。

3. 高內(nèi)聚與低耦合（High Cohesion and Low Coupling - HCLC）

模塊內(nèi)部需要做到內(nèi)聚度高，模塊之間需要做到耦合度低。

4. 慣例優(yōu)于配置（Convention over Configuration - COC）

盡量讓?xiě)T例來(lái)減少配置，這樣才能提高開(kāi)發(fā)效率，盡量做到“零配置”。很多開(kāi)發(fā)框架都是這樣做的。

5. 命令查詢分離（Command Query Separation - CQS）

在定義接口時(shí)，要做到哪些是命令，哪些是查詢，要將它們分離，而不要揉到一起。

6. 關(guān)注點(diǎn)分離（Separation of Concerns - SOC）

將一個(gè)復(fù)雜的問(wèn)題分離為多個(gè)簡(jiǎn)單的問(wèn)題，然后逐個(gè)解決這些簡(jiǎn)單的問(wèn)題，那么這個(gè)復(fù)雜的問(wèn)題就解決了。難就難在如何進(jìn)行分離。

7. 契約式設(shè)計(jì)（Design by Contract - DBC）

模塊或系統(tǒng)之間的交互，都是基于契約（接口或抽象）的，而不要依賴于具體實(shí)現(xiàn)。該原則建議我們要面向契約編程。

8. 你不需要它（You aren’t gonna need it - YAGNI）

不要一開(kāi)始就把系統(tǒng)設(shè)計(jì)得非常復(fù)雜，不要陷入“過(guò)度設(shè)計(jì)”的深淵。應(yīng)該讓系統(tǒng)足夠的簡(jiǎn)單，而卻又不失擴(kuò)展性，這是其中的難點(diǎn)。

真正的開(kāi)源并非只是代碼的開(kāi)源，而是思想的開(kāi)源

談?wù)勎覍?duì)「開(kāi)源」的看法，國(guó)內(nèi)的開(kāi)源的現(xiàn)在如何，對(duì)比國(guó)外呢？

我個(gè)人認(rèn)為，真正的開(kāi)源并非只是代碼的開(kāi)源，而是思想的開(kāi)源。在做開(kāi)源項(xiàng)目之前，建議能將自己的想法共享出來(lái)，而不是 埋頭閉門(mén)造車。我不反對(duì)“重造輪子”，因?yàn)槲覀冃枰玫妮喿?#xff0c;輪子好了車子才能跑得快。凡是有利也有弊，我們也不能盲目地選擇開(kāi)源技術(shù)，因?yàn)椴⒉皇沁m合 別人的技術(shù)就適合自己，而是需要根據(jù)自身的需求，選擇最適合的開(kāi)源技術(shù)，搭建恰如其分的架構(gòu)。

有大量的新技術(shù)，我首先會(huì)去關(guān)注它，了解它是做什么的，可以解決什么問(wèn)題，但我一開(kāi)始絕不會(huì)去深入研究它，更不會(huì)去看它的源碼，因?yàn)橐坏┯龅竭@方面的需求場(chǎng)景，我就會(huì)從這個(gè)“知識(shí)庫(kù)”中去尋找最好的解決方案，如果仍然尋找不到最合適的開(kāi)源技術(shù)，我才會(huì)嘗試自己去實(shí)現(xiàn)。

程序員該掌握的技術(shù)棧

二話不說(shuō)上圖：

需要高清圖片及學(xué)習(xí)大綱上相關(guān)的視頻學(xué)習(xí)資料

現(xiàn)在加群即可獲取更加詳細(xì)的Java架構(gòu)腦圖，還有Java工程化、高性能及分布式、高性能、高架構(gòu)、zookeeper、性能調(diào)優(yōu)、Spring、MyBatis、Netty源碼分析和大數(shù)據(jù)等多個(gè)知識(shí)點(diǎn)高級(jí)進(jìn)階干貨的直播免費(fèi)學(xué)習(xí)權(quán)限及相關(guān)視頻資料，群號(hào)：923116658

點(diǎn)擊鏈接加入群聊【Java架構(gòu)解析】：https://jq.qq.com/?_wv=1027&k=5e1QsXb

總結(jié)

以上是生活随笔為你收集整理的十年Java路，和大家来谈谈系统架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。