十年的職場之路堅持不易，分享下我的「IT 職場」經驗。
時光飛逝，我事業中第一個十年已然結束了。在這十年裏，讓我收穫了很多，跟大家分享一下我在 IT 職場方面的一些個人經驗，不一定對每個人都實用，請大家僅作參考吧。
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）
不要一開始就把系統設計得非常複雜，不要陷入“過度設計”的深淵。應該讓系統足夠的簡單，而卻又不失擴展性，這是其中的難點。
一個成功的項目，離不開每個人的努力，分享下我曾經的項目管理經驗。
給大家提出以下 10 點建議及其目標：
- Sprint 第一天，需要將目標定義清楚，並讓團隊所有人都知道「確保建立一致的目標並使之明確」；
- 若出現需求變更，則優先排到下次迭代，特殊情況需特殊處理「確保本次迭代可以按時完工」；
- Scrum Master 將迭代中的需求分解爲任務，每個任務只能有一個任務負責人，且不超過一個人天「確保每日任務可評估」；
- 讓 Product Owner 直接與相關開發人員確定需求，Scrum Master 需一同參與「確保需求與實現不會發生偏差」；
- 每日定時站會，時長不超過 15 分鐘，規模不要太大「確保任務完成情況與計劃保持一致」；
- 每日進行一次代碼評審，由 Scrum Master 負責，並在次日將評審結果通知給相關開發人員「確保代碼質量不要下降」；
- 各個團隊的 Scrum Master 保持每日溝通一次，時間不要超過 15 分鐘「確保項目管理不會出現風險」；
- 每次迭代結束，讓大家稍微放鬆一下，可提供一些團隊活動，比如聚餐「確保團隊能夠更加凝聚」；
- Scrum Master 需要給團隊一些承諾，比如項目獎金或特殊福利等「確保團隊更加有激情」；
- 對於情緒異常的員工，Scrum Master 需及時與其溝通「確保不要讓一個人的情緒影響整個團隊」；
此外，作爲項目管理者，需要不斷在團隊中加強以下 5 點文化：
- 方向一致
- 當面溝通
- 全情投入
- 充分信任
- 說到做到
真正的開源並非只是代碼的開源，而是思想的開源
談談我對「開源」的看法，國內的開源的現在如何，對比國外呢？
我個人認爲，真正的開源並非只是代碼的開源，而是思想的開源。在做開源項目之前，建議能將自己的想法共享出來，而不是 埋頭閉門造車。我不反對“重造輪子”，因爲我們需要更好的輪子，輪子好了車子才能跑得快。凡是有利也有弊，我們也不能盲目地選擇開源技術，因爲並不是適合 別人的技術就適合自己，而是需要根據自身的需求，選擇最適合的開源技術，搭建恰如其分的架構。
有大量的新技術，我首先會去關注它，瞭解它是做什麼的，可以解決什麼問題，但我一開始絕不會去深入研究它，更不會去看它的源碼，因爲一旦遇到這方面的需求場景，我就會從這個“知識庫”中去尋找最好的解決方案，如果仍然尋找不到最合適的開源技術，我纔會嘗試自己去實現。
技術人的歸途
走技術這條路，歸途是什麼？是否轉型又該如何抉擇呢？
至少有好幾條路線是可以走的，比如：深入技術、轉型做產品、轉型做管理等，需要根據自己的特長和性格來選擇，做自己喜歡的事情。
從技術轉管理，對自身的要求比較高，說具體點，需要看自己的情商，爲人處世的經驗，與人溝通的技巧，自己也需要有足夠的胸懷，去包容一些事情，還需要自己有足夠的人格魅力去吸引別人，讓別人願意跟着你一起做事。管理有些東西是很難從書本上學到的，但一些經典的管理理論是必須要去學的。
相比較而言，繼續深入技術或者從技術轉產品會容易一些了，因爲很多時候都不太需要與人打交道。