做了十年的技術，我從來都沒有放棄過它，相反，我非常熱愛它，因為我一直以來都很喜歡學習，希望能學到更多的東西，這樣遇到了具體的技術問題，可以隨時從自己積累的知識庫中找到最佳的解決方案。此外，目前我在公司雖然不怎么寫代碼了，但我還是會利用自己工作閑暇之余寫一點開源項目或者代碼框架等。

工作過很多大大小小的公司，那么公司最值錢的東西是什么呢？

我認為是實實在在做事情的程序員們。

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

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

他們需要理解產品經理真正的意圖，把想法變成現實，讓產品真正落地；

他們更容易把握細節，而這些細節往往決定著產品的命運與成敗；

他們突如其來的跳槽，對我們的項目的交付有直接的影響；

他們在一起工作的氣氛，能體現技術公司的文化與底蘊。

由此看來，對程序員的重視是相當有必要的，我們需要關心每一位程序員的職業發展，讓他們在團隊里能夠充分地發揮出自己的能力。

我們也需要對他們倍加關注，挖掘出有能力、肯吃苦、敢擔當的人，給他們更多的機會，讓他們成為技術領袖。

互聯網技術公司需要大量這樣的程序員：

他們是一群有著技術信仰的人，他們是一群熱愛編程的人，他們是一群不解決問題睡不好覺的人；

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

他們不喜歡被忽悠，不喜歡被冷落，更不喜歡被驅動；

他們需要尊重，需要培養，更需要激情！

具體說說程序員需要具備哪些素質。

我個人是這樣理解真正的程序員的：

深愛技術，一天不寫代碼手就會癢，就喜歡那種成就感；

為了一個問題可以廢寢忘食，有時會在夢中都能寫代碼；

代碼潔癖癥患者，喜歡優雅代碼，寫代碼就像寫詩一樣；

善于分析問題，能快速看清問題的本質，并動手解決它；

喜歡研究優秀源碼，學習大師的杰作，善于歸納與總結；

有自己的開源項目或技術博客，喜歡學習，更喜歡分享；

會關注技術圈子的新聞動態，時常會參加線下技術沙龍；

知道軟件開發不是一個人在戰斗，更需要的是團隊協作；

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

十年的職場之路堅持不易，分享下我的「IT 職場」經驗。

時光飛逝，我事業中第一個十年已然結束了。在這十年里，讓我收獲了很多，跟大家分享一下我在 IT 職場方面的一些個人經驗，不一定對每個人都實用，請大家僅作參考吧。

大家既然都是做技術的，那我們不妨先從技術這個話題開始說起吧。我要與大家分享的第一點經驗就是：

1. 把技術當成工具

技術這東西，其實一點都不神秘，它只不過是一個工具，用這個工具可以幫助我們解決實際問題，就這么簡單。

我們每天在面對技術，市面上也有很多技術，真的沒有必要把這些技術都拿過來學習一遍，然后想辦法找個場景去應用它。如果真的這樣做了，那么只能說明技術不是工具，而是玩具，技術不是這樣玩的。

我們應該從另一個角度來看待技術，不妨從自己的實際工作環境出發，現在需要什么，我們就學什么，而不要漫無目的的追求一些新技術。當然，對于新技術還是需要有所關注的，至少需要知道這個新技術是干什么用的，而且還要善于總結，將有價值的技術收集起來，以備將來使用，當需要使用的時候再來深入研究。

人的精力是有限的，人的生命也是短暫的，要善于利用自己的時間，合理地學習技術。

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

作為一名技術人員，除了學習與應用技術以外，還需要為自己做一個正確的職業規劃，清晰認識自己究竟屬于哪種技術人才，是技術專家類型的，還是技術管理類型的。路到底該怎么走？需要自己做出決定。

在我們職業路線上，最重要的人莫過于老板（我指的老板可以是公司大老板，也可以是自己的頂頭上司），對待自己的老板，我也有一些經驗：

2. 把老板當成情人

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

講一個真實的故事吧。記得曾經我的一位同事，技術非常好，做東西非常快，質量也很高，同事們都覺得他是牛人，但他從來都不懂得在老板面前表現自己，老板也只是覺得他是可以做事的，但升職加薪的事情往往總是不會優先考慮他。

大家很定會問：怎樣在老板面前表現自己呢？其實方法有很多，由于篇幅有限，我先提供三招吧：

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

第二招：把自己每天的工作簡單記錄一下，每周匯總一次，以郵件的形式發送給老板，讓老板知道自己每天在做什么。每月寫一篇本月工作總結與下月工作計劃，同樣發郵件給老板。年底可以寫一個年終工作總結，打印出來，悄悄地放在老板的桌子上。

第三招：借匯報工作為理由，定期請老板出去吃飯，制造面對面單獨溝通的機會。在談話過程中，強調自己愿意幫助老板分擔工作壓力。

對待老板其實很簡單，只要能幫他做事，又能讓他開心，他基本上就搞定了。老板搞定了，自己的職業發展才會平步青云。但千萬別忽略了還有一群人，他們或許是自己的團隊戰友，或許是自己的競爭對手，沒錯！他們就是同事。如何處理同事關系呢？以下便是我的經驗：

3. 把同事當成小孩

處理與同事關系，其實比處理與老板關系要稍微復雜一點，因為同事有多種身份，他們可以是隊友，也可以是對手。如果大家在一起做同一個項目，那么這樣的同事就是隊友；如果為了競爭某個項目、崗位、資源，導致同級別的同事之間發生利益上的競爭，那么這樣的同事就是對手。

對于隊友而言，要學會主動給他們提供幫助，讓大家能夠體會到團隊協作的氣氛，在一起學習，在一起成長，在一起分享。可以時常跟大家一起聚餐，買點零食讓大家品嘗。

隊友關系往往比較好處理，關鍵在于自己能否真正懂得去分享。很多技術人員，最不愿意的就是分享，因為擔心自己花了很多精力學到的知識，分分鐘就被別人學會了，自己失去了優勢。這種心態最好不要在團隊里產生，這樣只會讓自己變得越來越封閉，越來越渺小，隊友們也會逐漸排擠自己。

對于對手而言，要想辦法讓自己成為他的兄弟，告訴他，咱們是兄弟，應該相互幫助。如果有機會，可以在老板面前，當著對手的面，夸獎自己的對手。做出這樣的行為，其實并不會讓老板覺得自己不如對手，而會讓老板認為自己在用心去容納對手。大家在一起工作，就是一種緣分，都是跟老板打工的，真的沒有必要搞得不愉快。

其實同事就是自己的小伙伴，不妨把他們當成是單純可愛的小孩吧，用自己的心去“收買”他們。

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

4. 把客戶當成病人

客戶有需求，但沒有技術，而我們有技術、有經驗、有產品，正好可以幫助他們實現需求，從而提高他們的工作效率，這樣客戶才會心甘情愿地把錢放入我們的口袋。所以，在客戶面前，我們要表現出高超的專業精神，不要被客戶牽著我們的鼻子走，我們在客戶面前就是技術權威，就需要這樣的自信。從服裝、言行、郵件、文檔等各個方面，都要做到專業。

我們打算把自己的產品賣給客戶的時候，千萬不要一上來就對自己的產品夸夸其談，這往往會讓客戶感到厭煩。我們不妨先告訴客戶，他們已經“生病”了，而且病得不輕，如果不及時用藥的話，后果將不堪設想。也就是說，要讓客戶意識到自己現在所面臨的困境，讓客戶緊張，當他們正在思考如何應對的時候，我們再告訴他們，“藥”已經準備好了，可以隨時服用。

要讓客戶有種雪中送炭的感覺，這樣就對了，他們一定會主動了解我們的產品。我們要做到這一切，必須花精力來分析行業現狀，揣測客戶老板們每天在想什么。如果有機會進入客戶所在的公司工作一段時間，相信自己的感受會更加深入。

Java 會在很長的一段時間內是主流

為什么開發 Java Web 都要用框架？

我個人覺得框架有以下幾點作用：

讓開發更加高效，屏蔽底層技術細節，讓開發人員關注在具體業務上。

框架實際上也是一種規范，可以讓每位開發人員保持同樣的編碼風格。

會使用主流框架的開發人員，在人才市場上比較好獲取。

現在做 Java Web 開發都用哪些框架呢？

常用的比如 Spring MVC、Struts2 等，國內的 JFinal、Nutz 等也不錯，當然 Smart 也是一個很好的選擇。

有一定 Web 前端開發經驗的人，很多都會有這么個想法：那些寫框架的人好厲害，什么時候我才能寫一個自己的框架呢？有時候看看別人的框架代碼，又覺得很復雜，對此我有一些建議以及新人學習需要什么基礎？分享一些好的方法。

對于接觸 Java 不太久的朋友，建議按照以下幾個步驟來學習：

學習 Java 基礎語法與核心技術，包括 Servlet、JSP、JDBC 等。

熟練使用流行開源框架，包括 Spring、MyBatis 等。

研究開源框架源碼，并吸取其中優秀的架構。

此外，在學習的過程當中，建議做學習筆記，最好能通過博客的方式來記錄自己的收獲。

使用 Python、Perl、PHP、Ruby 等腳本語言開發 Web 程序，跟使用 Java 開發 Web 程序相比有什么不同或者優劣？

前者屬于動態語言，無需編譯，可通過解釋的方式來運行，而且 Java 需要首先通過編譯，將源文件轉為字節碼，且載入 Java 虛擬機才能運行，相對來說，Java 對環境的要求較高，但 Java 具備更強的面向對象能力。此外，Java 還擁有較廣的開源社區以及流行的開源中間件。因此，如果是做大型系統，建議使用 Java 來開發，而并非那些腳本語言。

針對 Web，Java、PHP、Python、.NET 之中未來發展前景最好的會是什么？

我認為 Java 在未來還會有一段很長的路，需要在語言本身上做到更加輕量級，用最少的代碼來實現目標功能；PHP 相對來說會比較平穩，它的特點非常突出，上手快且易于開發 Web 項目；Python 仍然不會有太大的用戶群體；.NET 加入開源社區太晚，且較 Java 而言并沒有太強的優勢，可能會走下坡路。

在軟件開發中有很多的設計模式，也有一些很高冷，談談我對軟件設計的理解，以及讓一些設計原則接地氣。

了解設計模式的朋友們，想必都聽說過“六大設計原則”吧。其實最經典的 23 種設計模式中或多或少地都在使用這些設計原則，也就是說，設計模式是站在設計原則的基礎之上的。所以在學習設計模式之前，很有必要對這些設計原則先做一下了解。

GoF（四人幫），傳說中的四位大神們，他們聯手搞出了一套設計模式，堪稱 OOD（面向對象設計）的經典之作！震驚了整個軟件開發領域。但這四個老家伙非常怪異，總是喜歡顯擺一些高深的理論，甚至有時候不說人話，十分讓人費解。

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

六大設計原則

先看一幅圖吧：

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

1. 單一職責原則（Single Responsibility Principle - SRP）

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

譯文：永遠不應該有多于一個原因來改變某個類。

理解：對于一個類而言，應該僅有一個引起它變化的原因。說白了就是，不同的類具備不同的職責，各施其責。這就好比一個團隊，大家分工協作，互不影響，各做各的事情。

應用：當我們做系統設計時，如果發現有一個類擁有了兩種的職責，那就問自己一個問題：可以將這個類分成兩個類嗎？如果真的有必要，那就分吧。千萬不要讓一個類干的事情太多！

2. 開放封閉原則（Open Closed Principle - OCP）

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

譯文：軟件實體，如：類、模塊與函數，對于擴展應該是開放的，但對于修改應該是封閉的。

理解：簡言之，對擴展開放，對修改封閉。換句話說，可以去擴展類，但不要去修改類。

應用：當需求有改動，要修改代碼了，此時您要做的是，盡量用繼承或組合的方式來擴展類的功能，而不是直接修改類的代碼。當然，如果能夠確保對整體架構不會產生任何影響，那么也沒必要搞得那么復雜了，直接改這個類吧。

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.

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

理解：父類能夠替換子類，但子類不一定能替換父類。也就是說，在代碼中可以將父類全部替換為子類，程序不會報錯，也不會在運行時出現任何異常，但反過來卻不一定成立。

應用：在繼承類時，務必重寫（Override）父類中所有的方法，尤其需要注意父類的 protected 方法（它們往往是讓您重寫的），子類盡量不要暴露自己的 public 方法供外界調用。

該原則由麻省理工學院的 Barbara Liskov 女士提出，她是美國第一位獲取計算機博士學位的女性，曾經也獲得過計算機圖靈獎。

4. 最少知識原則（Least Knowledge Principle - LKP）

原文：Only talk to you immediate friends.

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

理解：盡量減少對象之間的交互，從而減小類之間的耦合。簡言之，一定要做到：低耦合，高內聚。

應用：在做系統設計時，不要讓一個類依賴于太多的其他類，需盡量減小依賴關系，否則，您死都不知道自己怎么死的。

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

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

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

譯文：一個類與另一個類之間的依賴性，應該依賴于盡可能小的接口。

理解：不要對外暴露沒有實際意義的接口。也就是說，接口是給別人調用的，那就不要去為難別人了，盡可能保證接口的實用性吧。她好，我也好。

應用：當需要對外暴露接口時，需要再三斟酌，如果真的沒有必要對外提供的，就刪了吧。一旦您提供了，就意味著，您將來要多做一件事情，何苦要給自己找事做呢。

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.

譯文：高層模塊不應該依賴于低層模塊，它們應該依賴于抽象。抽象不應該依賴于細節，細節應該依賴于抽象。

理解：應該面向接口編程，不應該面向實現類編程。面向實現類編程，相當于就是論事，那是正向依賴（正常人思維）；面向接口編程，相當于通過事物表象來看本質，那是反向依賴，即依賴倒置（程序員思維）。

應用：并不是說，所有的類都要有一個對應的接口，而是說，如果有接口，那就盡量使用接口來編程吧。

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

只有滿足了這六大原則，才能設計出穩定的軟件架構！但它們畢竟只是原則，只是四人幫給我們的建議，有些時候我們還是要學會靈活應變，千萬不要生搬硬套，否則只會把簡單問題復雜化，切記！

補充設計原則

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

當要擴展類的功能時，優先考慮使用組合，而不是繼承。這條原則在 23 種經典設計模式中頻繁使用，如：代理模式、裝飾模式、適配器模式等。可見江湖地位非常之高！

2. 無環依賴原則（Acyclic Dependencies Principle - ADP）

當 A 模塊依賴于 B 模塊，B 模塊依賴于 C 模塊，C 依賴于 A 模塊，此時將出現循環依賴。在設計中應該避免這個問題，可通過引入“中介者模式”解決該問題。

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

應該將易變的類放在同一個包里，將變化隔離出來。該原則是“開放 - 封閉原則”的延生。

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

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

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

好萊塢明星的經紀人一般都很忙，他們不想被打擾，往往會說：Don’t call me, I’ll call you. 翻譯為：不要聯系我，我會聯系你。對應于軟件設計而言，最著名的就是“控制反轉”（或稱為“依賴注入”），我們不需要在代碼中主動的創建對象，而是由容器幫我們來創建并管理這些對象。

其他設計原則

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

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

2. 保持它簡單與傻瓜（Keep it simple and stupid - KISS）

不要讓系統變得復雜，界面簡潔，功能實用，操作方便，要讓它足夠的簡單，足夠的傻瓜。

3. 高內聚與低耦合（High Cohesion and Low Coupling - HCLC）

模塊內部需要做到內聚度高，模塊之間需要做到耦合度低。

4. 慣例優于配置（Convention over Configuration - COC）

盡量讓慣例來減少配置，這樣才能提高開發效率，盡量做到“零配置”。很多開發框架都是這樣做的。

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

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

6. 關注點分離（Separation of Concerns - SOC）

將一個復雜的問題分離為多個簡單的問題，然后逐個解決這些簡單的問題，那么這個復雜的問題就解決了。難就難在如何進行分離。

7. 契約式設計（Design by Contract - DBC）

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

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

不要一開始就把系統設計得非常復雜，不要陷入“過度設計”的深淵。應該讓系統足夠的簡單，而卻又不失擴展性，這是其中的難點。

真正的開源并非只是代碼的開源，而是思想的開源

談談我對「開源」的看法，國內的開源的現在如何，對比國外呢？

我個人認為，真正的開源并非只是代碼的開源，而是思想的開源。在做開源項目之前，建議能將自己的想法共享出來，而不是 埋頭閉門造車。我不反對“重造輪子”，因為我們需要更好的輪子，輪子好了車子才能跑得快。凡是有利也有弊，我們也不能盲目地選擇開源技術，因為并不是適合 別人的技術就適合自己，而是需要根據自身的需求，選擇最適合的開源技術，搭建恰如其分的架構。

有大量的新技術，我首先會去關注它，了解它是做什么的，可以解決什么問題，但我一開始絕不會去深入研究它，更不會去看它的源碼，因為一旦遇到這方面的需求場景，我就會從這個“知識庫”中去尋找最好的解決方案，如果仍然尋找不到最合適的開源技術，我才會嘗試自己去實現。

程序員該掌握的技術棧

二話不說上圖：

需要高清圖片及學習大綱上相關的視頻學習資料

現在加群即可獲取更加詳細的Java架構腦圖，還有Java工程化、高性能及分布式、高性能、高架構、zookeeper、性能調優、Spring、MyBatis、Netty源碼分析和大數據等多個知識點高級進階干貨的直播免費學習權限及相關視頻資料，群號：923116658

點擊鏈接加入群聊【Java架構解析】：https://jq.qq.com/?_wv=1027&k=5e1QsXb

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。