专访黄勇：Java在未来的很长一段时间仍是主流
專訪黃勇：Java在未來的很長一段時間仍是主流
發表于2015-09-06 13:18| 11640次閱讀| 來源CSDN| 70 條評論| 作者錢曙光
社區文旦專訪黃勇架構框架JavaJava Web width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-09-06%2F2825621&type=3&count=&appkey=&title=%E6%9C%AC%E6%96%87%E9%87%87%E8%AE%BF%E4%BA%86%E7%8E%B0%E4%BB%BB%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4%E5%85%AC%E5%8F%B8%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E5%B8%88%E9%BB%84%E5%8B%87%EF%BC%8C%E4%BB%8E%E4%BA%8B%E8%BF%91%E5%8D%81%E5%B9%B4%E7%9A%84JavaEE%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E5%B7%A5%E4%BD%9C%E3%80%82%E9%87%87%E8%AE%BF%E5%86%85%E5%AE%B9%E5%8C%85%E5%90%AB%E4%BA%86%E6%8A%80%E6%9C%AF%E4%BA%BA%E7%94%9F%E3%80%81IT%E8%81%8C%E5%9C%BA%E3%80%81%E7%A8%8B%E5%BA%8F%E5%91%98%E3%80%81Java%20Web%E6%A1%86%E6%9E%B6%E3%80%81%E7%A0%94%E5%8F%91%E7%AE%A1%E7%90%86%E3%80%81%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E3%80%81%E5%BC%80%E6%BA%90%E7%AD%89%E9%97%AE%E9%A2%98%EF%BC%8C%E5%B8%8C%E6%9C%9B%E4%BD%A0%E5%9C%A8%E6%8A%80%E6%9C%AF%E8%BF%99%E6%9D%A1%E8%B7%AF%E4%B8%8A%E4%B8%8D%E5%AD%A4%E5%8D%95%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1441805996962" frameborder="0" scrolling="no" allowtransparency="true">摘要：本文采訪了現任阿里巴巴公司系統架構師黃勇，從事近十年的JavaEE應用開發工作。采訪內容包含了技術人生、IT職場、程序員、Java Web框架、研發管理、敏捷開發、開源等問題，希望你在技術這條路上不孤單。【編者按】 一個普通的技術人講述不平凡的技術人生路。黃勇，在工作十年后，寫了一本書：《架構探險——從零開始寫Java Web框架》，這本書是給他十年技術路的最好禮物，今天我們有幸采訪了黃勇，請他談一談他的一路走來，也就技術人員發展的一些問題進行討論，以及分享他在研發管理、敏捷開發方面的研究。
本文內容很豐富，如果能夠用心花時間讀一讀，不僅對你的IT職業生涯、技術積累等有所幫助，也會產生一種前行的推動力，因為成功的人依然在努力。也請那些在拼搏的IT人，請繼續「相信夢想的力量」。
在 Web 開發方面，Java 經歷了怎樣的發展？初學者如何從零開始寫Java?Web框架？黃勇老師將攜 《架構探險——從零開始寫Java?Web框架》一書，接受網友們關于Java?Web框架的相關提問，與此同時，也歡迎大家來與黃勇老師交流技術人員入行、心態、技能，以及敏捷開發、開源等方面內容。
敬請關注：CSDN社區問答欄目的第二十二期：架構探險
黃勇（ 博客），從事近十年的?JavaEE?應用開發工作，現任阿里巴巴公司系統架構師。對分布式服務架構與大數據技術有深入研究，具有豐富的?B/S?架構開發經驗與項目實戰經驗，擅長敏捷開發模式。國內開源軟件推動者之一，Smart?Framework?開源框架創始人。熱愛技術交流，樂于分享自己的工作經驗。著有《架構探險——從零開始寫Java?Web框架》一書。
我的十年技術之路
CSDN：請和大家介紹下你和目前所從事的工作。
黃勇：大家好，我是黃勇。
我目前從事分布式服務架構的設計與開發工作，在阿里的大數據平臺上進行應用程序開發。我們整個系統架構采用了“前后端分離”的思想，前端關注數據展現，后端關注數據生產，通過?REST服務將前后端整合起來，所有的應用都是無狀態的，可以做到水平擴展。我們將整個系統拆分成許多“微服務”，服務之間通過統一的接口來調用，每個服務是通過容器技術進行隔離，此外服務可發布到統一的服務管理平臺上，可通過該平臺監控每個服務的運行狀態與生命周期事件，并為服務調用者提供了服務發現的能力，可對服務進行平滑升級。
阿里有許多優秀的中間件與基礎服務，可以快速幫助我們搭建應用系統，而且這些技術在阿里內部全是開源的，大家可以通過源碼和文檔學習到很多有價值的經驗。阿里也提供了濃厚的技術氛圍，每位同學都非常專注于自己的工作領域，大家對工作一絲不茍，相互配合，方向一致。
CSDN：你是如何走上技術這條路的？
黃勇：2006?年大學畢業，我離開了母校武漢理工大學，在院長薛勝軍老師的推薦下，我來到了上海，這個對于我來說非常陌生的地方。我有幸加入了一家名為“動量軟件”的創業公司，這家公司的老板曾經是亞信科技的?CTO，他也是普元軟件的創始人兼?CTO，他的名字叫黃柳青，他也是薛老師的大學同學。于是就這樣，我的老板成為了我的老師，我習慣叫他黃老師，包括公司其他資深的同事也成為了我的老師，因為我很想他們身上學到更多有價值的東西。
剛開始工作的時候我學習了什么是云計算？什么是?SaaS、PaaS、IaaS？我們花了三年時間開發了一款名為?ODE?的?PaaS?平臺，讓用戶可以在該平臺上量身定制自己的軟件，最終為客戶提供基于?SaaS?的產品。確實很驕傲，那時我們已經在做云了，只是沒想到后來云會在中國得到這么好的市場，可能當時只有黃老師一個人想到了吧。
在?2008?年，我為公司拿回了“第一桶金”，這也是我從程序員轉向項目經理的里程碑。當時我帶領團隊遠赴深圳，為國信證券公司開發經紀人管理系統，這個項目對于我個人而言卻是一筆至高無上的財富，我開始學習如何與人打交道，如何做需求分析，如何將需求轉變為技術，如何帶領團隊小伙伴一起工作。學到了太多太多，但我依然選擇在我工作第四個年頭里離開了動量軟件，我剛加入動量軟件的時候，公司只有?5?個人（包括老板和前臺），當我離開動量軟件的時候，公司已經有?200?人左右了。感謝黃老師！我在他身上學到了很多，他的思想和態度直到今天都還在影響著我。
我的第二份工作還是選擇了我最熟悉的證券金融行業，同樣也是一家創業型公司，在這家公司里我擔任了技術經理，管理了整個技術團隊，從項目的售前到售后，我都親自帶領團隊來完成。雖然在這家公司我只做了兩年，但在這短短的時間里，我學會了如何提高開發效率、如何培養技術團隊、如何選拔技術人才、如何建立企業文化。但最后我發現了一個問題，越是想做好，越是很難做好，為了做成一件事情需要做很多的嘗試，做事情缺乏正確并有效的方法。
回想我工作的前六年時間里，我一直都是在創業公司里成長，雖然可以快速學到東西，但似乎很難學到更加規范的做事方法。于是我選擇了新的工作機會，來到了?TCL?通訊，這是一家相當大的公司，公司的研發管理流程來源于法國阿里卡特公司。我在公司擔任?Java?架構師職位，也算是整個?Java?團隊的技術負責人，雖然團隊并不是特別地大。我在這家公司做了三年，學到了如何整合現有資源、如何按標準流程去做事、如何設計系統架構、如何進行異地工作、如何跨團隊工作、如何用英文來溝通。說實話，當時我沒有任何的工作壓力，可以按時上下班，從來都不會加班。雖然自己空閑的時間很多，但我并沒有選擇去浪費時間，而是開始寫點技術博客，也正是因為這些技術文章，才改變了我后續的職業發展道路。
我清楚的記得，那是在?2013?年?9?月?1?日，我在開源中國（oschina.net）網站發表了我人生的第一篇博文 《Smart?Framework：輕量級?Java?Web?框架》 ，這篇文章影響了我后續兩年。其實說句心里話，當我第一次寫這篇文章時，我心里是沒底的，這個框架只是根據自己的理解做出來的一個設想，當時甚至連一行代碼都沒寫過。我的想法是先將這個思想發表出來，讓大家討論起來，我會做一個決策，然后再親自做具體實現，最后我會將實現過程通過博文的方式展現給大家，后續大家會對我的實現進行點評，我會基于大家的建議進行改善。整個開源過程正好與敏捷的思想是一致的，有效溝通、小步快跑、擁抱變化、不斷改進。
也許就是我的技術文章吸引了很多廣大讀者，這里面不排除想邀請我加入的其它公司。我在?2014?年離開了?TCL?通訊，加入了易傳媒。為什么我要放棄如此舒適的工作環境，去加入一家還在不斷拼搏的企業呢？其實我看到的是未來互聯網的發展趨勢，廣告程序化交易以及廣告與大數據的結合，未來最值錢的一定是數據。抱著這樣的信心，我加入了易傳媒，擔任系統架構師職位。當時易傳媒正處于技術轉型的初期，需要將?.Net?全部遷移到?Java，這件事情對于我而言是非常有挑戰的。我的做法是：第一步定義開發規范與流程，第二步培養核心技術人員，第三步分階段進行改造。僅半年時間，我們所有的產品成功地遷移到了?Java?平臺，結果出乎大家的想象。公司市場也非常不錯，產品得到了業界的認可，訂單數源源不斷，大家每天都很忙碌，但卻很開心。而易傳媒的“易家人”企業文化，讓我所感動，不管是核心技術部門還是其它支持性部門，大家就像一家人一樣，你的事情就是我的事情。
直到?2015?年初，阿里巴巴與易傳媒建立了合作關系，兩家公司進行了深度合作，易傳媒公司與阿里媽媽事業部進行了整合，新阿里媽媽從此誕生了，于是我也成為了阿里巴巴的一員，目前負責阿里媽媽大數據品牌營銷產品的系統架構工作。就在兩家公司整合的過程中，我完成了人生中的處女作《架構探險?——?從零開始寫?Java?Web?框架》這本書，目前該書正在各大網上書店售賣，我真心希望這本書能對一些想成為架構師的程序員們有所幫助，由于我個人水平有限，又是第一次寫書，寫得不好的地方還請大家多多包涵。
CSDN：上面提到，寫博客給你帶來的收獲頗多，能不能分享下技術人如何寫博客？又應該以怎樣的態度對待？
黃勇：我認為技術人員寫博客需要注意以下幾點：
寫博客首先是對自己所學知識的一個總結，此外，也為其他讀者提供了很好的教程，知識得到了廣播與傳遞。
CSDN：技術一條不歸路，選擇了這條路是否有過放棄的想法？
黃勇：做了十年的技術，我從來都沒有放棄過它，相反，我非常熱愛它，因為我一直以來都很喜歡學習，希望能學到更多的東西，這樣遇到了具體的技術問題，可以隨時從自己積累的知識庫中找到最佳的解決方案。此外，目前我在公司雖然不怎么寫代碼了，但我還是會利用自己工作閑暇之余寫一點開源項目或者代碼框架等。
CSDN：你工作過很多大大小小的公司，你認為公司最值錢的東西是什么？
黃勇：我認為是實實在在做事情的程序員們。
他們雖然工資不高，每天坐在位置上敲著代碼，在很多人眼中被稱為“屌絲”或“宅男”，但我認為恰恰就是這些人，他們才是公司最有價值的人。
- 他們有自己的理想，希望能夠通過自己的努力，從中得到那一點點所謂的成就感；
- 他們需要理解產品經理真正的意圖，把想法變成現實，讓產品真正落地；
- 他們更容易把握細節，而這些細節往往決定著產品的命運與成敗；
- 他們突如其來的跳槽，對我們的項目的交付有直接的影響；
- 他們在一起工作的氣氛，能體現技術公司的文化與底蘊。
由此看來，對程序員的重視是相當有必要的，我們需要關心每一位程序員的職業發展，讓他們在團隊里能夠充分地發揮出自己的能力。
我們也需要對他們倍加關注，挖掘出有能力、肯吃苦、敢擔當的人，給他們更多的機會，讓他們成為技術領袖。
互聯網技術公司需要大量這樣的程序員：
- 他們是一群有著技術信仰的人，他們是一群熱愛編程的人，他們是一群不解決問題睡不好覺的人；
- ?他們不是打雜的，不是外包，更不是工具；
- 他們不喜歡被忽悠，不喜歡被冷落，更不喜歡被驅動；
- ?他們需要尊重，需要培養，更需要激情！
CSDN：你能具體說說程序員需要具備哪些素質嗎？
黃勇：我個人是這樣理解真正的程序員的：
CSDN：十年的職場之路堅持不易，能夠分享下你的「IT?職場」經驗？
黃勇：時光飛逝，我事業中第一個十年已然結束了。在這十年里，讓我收獲了很多，跟大家分享一下我在?IT?職場方面的一些個人經驗，不一定對每個人都實用，請大家僅作參考吧。
大家既然都是做技術的，那我們不妨先從技術這個話題開始說起吧。我要與大家分享的第一點經驗就是：
1. 把技術當成工具
技術這東西，其實一點都不神秘，它只不過是一個工具，用這個工具可以幫助我們解決實際問題，就這么簡單。
我們每天在面對技術，市面上也有很多技術，真的沒有必要把這些技術都拿過來學習一遍，然后想辦法找個場景去應用它。如果真的這樣做了，那么只能說明技術不是工具，而是玩具，技術不是這樣玩的。
我們應該從另一個角度來看待技術，不妨從自己的實際工作環境出發，現在需要什么，我們就學什么，而不要漫無目的的追求一些新技術。當然，對于新技術還是需要有所關注的，至少需要知道這個新技術是干什么用的，而且還要善于總結，將有價值的技術收集起來，以備將來使用，當需要使用的時候再來深入研究。
人的精力是有限的，人的生命也是短暫的，要善于利用自己的時間，合理地學習技術。
不要把技術看得那么重要，別把它當回事兒，把它當工具就行了，它就像我們寫字的筆一樣，用鉛筆能寫字，用鋼筆一樣能寫字。
作為一名技術人員，除了學習與應用技術以外，還需要為自己做一個正確的職業規劃，清晰認識自己究竟屬于哪種技術人才，是技術專家類型的，還是技術管理類型的。路到底該怎么走？需要自己做出決定。
在我們職業路線上，最重要的人莫過于老板（我指的老板可以是公司大老板，也可以是自己的頂頭上司），對待自己的老板，我也有一些經驗：
2. 把老板當成情人
大家應該非常清楚，情人是需要浪漫的，浪漫是需要驚喜的。老板其實跟情人一樣，也是需要驚喜的。我們做下屬的，要懂得找到合適的機會給老板帶來驚喜。我們跟情人談情說愛，這是一種很好的溝通方式，可別忽略了跟老板“談情說愛”，我們需要與老板保持良好的溝通，這種溝通并不僅僅是溜須拍馬。
講一個真實的故事吧。記得曾經我的一位同事，技術非常好，做東西非常快，質量也很高，同事們都覺得他是牛人，但他從來都不懂得在老板面前表現自己，老板也只是覺得他是可以做事的，但升職加薪的事情往往總是不會優先考慮他。
大家很定會問：怎樣在老板面前表現自己呢？其實方法有很多，由于篇幅有限，我先提供三招吧：
- 第一招：在給老板做程序演示的時候，不要只是單純的演示，不妨先用一個?PPT，簡單表達一下自己的解決方案，然后再做演示，這樣效果會好很多。老板會認為自己是花了心思的，是想把事情做得更好的。
- 第二招：把自己每天的工作簡單記錄一下，每周匯總一次，以郵件的形式發送給老板，讓老板知道自己每天在做什么。每月寫一篇本月工作總結與下月工作計劃，同樣發郵件給老板。年底可以寫一個年終工作總結，打印出來，悄悄地放在老板的桌子上。
- 第三招：借匯報工作為理由，定期請老板出去吃飯，制造面對面單獨溝通的機會。在談話過程中，強調自己愿意幫助老板分擔工作壓力。
對待老板其實很簡單，只要能幫他做事，又能讓他開心，他基本上就搞定了。老板搞定了，自己的職業發展才會平步青云。但千萬別忽略了還有一群人，他們或許是自己的團隊戰友，或許是自己的競爭對手，沒錯！他們就是同事。如何處理同事關系呢？以下便是我的經驗：
3.?把同事當成小孩
處理與同事關系，其實比處理與老板關系要稍微復雜一點，因為同事有多種身份，他們可以是隊友，也可以是對手。如果大家在一起做同一個項目，那么這樣的同事就是隊友；如果為了競爭某個項目、崗位、資源，導致同級別的同事之間發生利益上的競爭，那么這樣的同事就是對手。
對于隊友而言，要學會主動給他們提供幫助，讓大家能夠體會到團隊協作的氣氛，在一起學習，在一起成長，在一起分享。可以時常跟大家一起聚餐，買點零食讓大家品嘗。
隊友關系往往比較好處理，關鍵在于自己能否真正懂得去分享。很多技術人員，最不愿意的就是分享，因為擔心自己花了很多精力學到的知識，分分鐘就被別人學會了，自己失去了優勢。這種心態最好不要在團隊里產生，這樣只會讓自己變得越來越封閉，越來越渺小，隊友們也會逐漸排擠自己。
對于對手而言，要想辦法讓自己成為他的兄弟，告訴他，咱們是兄弟，應該相互幫助。如果有機會，可以在老板面前，當著對手的面，夸獎自己的對手。做出這樣的行為，其實并不會讓老板覺得自己不如對手，而會讓老板認為自己在用心去容納對手。大家在一起工作，就是一種緣分，都是跟老板打工的，真的沒有必要搞得不愉快。
其實同事就是自己的小伙伴，不妨把他們當成是單純可愛的小孩吧，用自己的心去“收買”他們。
老板與同事，他們都是公司內部的人，不管怎么說，大家都在同一條船上，大家可以關上門吵一架，只要事情能夠解決就行。但對于我們的客戶而言，就需要用另外一種方法來處理好關系了。我是這樣認為的：
4.?把客戶當成病人
客戶有需求，但沒有技術，而我們有技術、有經驗、有產品，正好可以幫助他們實現需求，從而提高他們的工作效率，這樣客戶才會心甘情愿地把錢放入我們的口袋。所以，在客戶面前，我們要表現出高超的專業精神，不要被客戶牽著我們的鼻子走，我們在客戶面前就是技術權威，就需要這樣的自信。從服裝、言行、郵件、文檔等各個方面，都要做到專業。
我們打算把自己的產品賣給客戶的時候，千萬不要一上來就對自己的產品夸夸其談，這往往會讓客戶感到厭煩。我們不妨先告訴客戶，他們已經“生病”了，而且病得不輕，如果不及時用藥的話，后果將不堪設想。也就是說，要讓客戶意識到自己現在所面臨的困境，讓客戶緊張，當他們正在思考如何應對的時候，我們再告訴他們，“藥”已經準備好了，可以隨時服用。
要讓客戶有種雪中送炭的感覺，這樣就對了，他們一定會主動了解我們的產品。我們要做到這一切，必須花精力來分析行業現狀，揣測客戶老板們每天在想什么。如果有機會進入客戶所在的公司工作一段時間，相信自己的感受會更加深入。
Java 會在很長的一段時間內是主流
CSDN：能否先簡答介紹下你的最新力作《架構探險——從零開始寫Java?Web框架》？面向的群體是怎樣的？有什么特別之處？
黃勇：建議有一定?Java?Web?開發經驗的讀者閱讀這本書，當然，如果大家想通過這本書來學習?Java?Web?核心技術也是非常不錯的，因為書中會有大量的實例來講解?Java?必備的基礎技能。此外，建議讀者們能親自動手去實踐，雖然書中所有的源代碼可以自由獲取，但我不建議大家只是看看代碼是怎么寫的，而錯過了一次很好的練手機會，因為所有的開發技能都需要不斷地練習，孰能生巧，巧能生輝。
CSDN：《架構探險——從零開始寫Java?Web框架》是你撰寫的第一技術書，是什么原因促使你寫這本的？
黃勇：記得那是在?2014?年?11?月底，我有幸結識了電子工業出版社博文視點編輯部的陳曉猛老師。陳老師建議我寫一本書，但我當時真的不知道該寫什么，我想可能在?Java?Web?方面還可以嘗試寫點東西吧，于是在他的鼓勵與幫助下，我就開始寫書了。陳老師告訴我，寫書其實就像寫博客一樣，當初我真這么覺得的，可是個人能力和經驗還是非常有限，第一次寫了?50?頁就再也寫不下去了，第二次竟然寫到了?100?頁，最后覺得自己的寫作思路有問題，還是放棄了，直到第三次我才把結構梳理清楚，一氣呵成地寫完了整本書。在這個過程中，是我妻子鼓勵并監督著我，那時我們的寶寶剛出生不久，每天在家里哭泣，我妻子把我一個人關在房間里，她獨自一人帶小孩，并操持著所有的家務，就是為了給我一個安靜的環境，讓我可以敞開思路，寫出更加優秀的作品。在此，請允許我對我妻子說一聲：辛苦了！我永遠愛你！
CSDN：寫書不是一件容易的事情，能不能談談在這段期間的辛酸和收獲？
黃勇：雖然寫書的過程比較艱辛，但對我個人卻有很大的收獲：
CSDN：為什么開發Java?Web都要用框架？
黃勇：我個人覺得框架有以下幾點作用：
CSDN：現在做Java?Web開發都用哪些框架呢？
黃勇：常用的比如Spring?MVC、Struts2?等，國內的?JFinal、Nutz?等也不錯，當然Smart?也是一個很好的選擇。
CSDN：有一定Web前端開發經驗的人，很多都會有這么個想法：那些寫框架的人好厲害，什么時候我才能寫一個自己的框架呢？有時候看看別人的框架代碼，又覺得很復雜，對此你有什么建議嗎？以及新人學習需要什么基礎？有哪些好的方法分享？
黃勇：對于接觸?Java?不太久的朋友，建議按照以下幾個步驟來學習：
此外，在學習的過程當中，建議做學習筆記，最好能通過博客的方式來記錄自己的收獲。
CSDN：使用?Python、Perl、PHP、Ruby?等腳本語言開發?Web?程序，跟使用?Java?開發?Web?程序相比有什么不同或者優劣？
黃勇：前者屬于動態語言，無需編譯，可通過解釋的方式來運行，而且?Java?需要首先通過編譯，將源文件轉為字節碼，且載入?Java?虛擬機才能運行，相對來說，Java?對環境的要求較高，但 Java?具備更強的面向對象能力。此外，Java?還擁有較廣的開源社區以及流行的開源中間件。因此，如果是做大型系統，建議使用 Java?來開發，而并非那些腳本語言。
CSDN：針對?Web，Java、PHP、Python、.NET?之中未來發展前景最好的會是什么？
黃勇：我認為?Java?在未來還會有一段很長的路，需要在語言本身上做到更加輕量級，用最少的代碼來實現目標功能；PHP?相對來說會比較平穩，它的特點非常突出，上手快且易于開發?Web?項目；Python仍然不會有太大的用戶群體；.NET?加入開源社區太晚，且較 Java?而言并沒有太強的優勢，可能會走下坡路。
CSDN：在軟件開發中有很多的設計模式，也有一些很高冷，能否談談你對軟件設計的理解，以及讓一些設計原則接地氣？
黃勇：了解設計模式的朋友們，想必都聽說過“六大設計原則”吧。其實最經典的?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）
不要一開始就把系統設計得非常復雜，不要陷入“過度設計”的深淵。應該讓系統足夠的簡單，而卻又不失擴展性，這是其中的難點。
敏捷開發模式的修煉之道
CSDN：請問你是如何接觸到敏捷開發的？你如何理解敏捷開發？
黃勇：曾經我們開發項目都是采用傳統的“瀑布式”流程進行開發，即需求、設計、開發、測試、上線等階段，其中每個階段都有明確的交付時間點，且每個階段都依賴于它的上個階段，一旦需求有變化，就會影響后續的每個階段，項目管理存在一定的風險。為了避免這個風險，做到更好地擁抱變化，我們嘗試使用了敏捷開發方法，最為典型的是?Scrum。我們參考Scrum?的流程結合自身的特點，總結了一套更容易落地的Scrum，后面我會跟大家講到一些相關細節。
我理解的敏捷開發實際上是一個輕量級的項目管理規范，因為我們可以將整個大的需求范圍拆分成若干迭代周期，我們為這些迭代周期設置明確的里程碑，且評估完成這些功能需要花費的成本，更重要的是，每次迭代完成以后，我們會對本次迭代進行一個回顧，取其精華，去其糟粕，不斷完善，持續改進。
CSDN：你認為國內的敏捷開發何時能成為主流？敏捷開發的未來走向是什么？
黃勇：我認為敏捷開發現在已經成為了主流，傳統開發模式已經出現了明顯的缺陷，隨著互聯網的發展，軟件開發的節奏會越來越快，變化也會越來越頻繁，需要我們能夠快速地發現變化，并進行及時地調整。
我認為敏捷開發的未來會變得更好，不僅僅在軟件開發行業，而且可能會在其它行業里也會得到應用，因為從客戶的角度來看，他們想要的是能通過最短的時間看到自己想要的東西，很多時候不做出一點東西出來，客戶是沒有任何想法的，所以需要將事情分解成多階段，迭代完成每個階段的里程碑，讓客戶滿意，才是企業最大的收獲。
CSDN：在你的工作生涯中，前期是在創業公司，后來是大公司，有著一套自己的敏捷開發模式，能夠談談在你現在使用的敏捷開發工具或方法？
黃勇：敏捷這個話題大家一直都在談論，也有很多關于敏捷的工具或方法，我個人比較傾向于?Scrum。我理解的敏捷其實是一種思想，Scrum?是對讓這個思想落地的一個參考。也就是說，我們大可不必完全拘泥于?Scrum?定義的規范，只需要參考它并結合自身的條件做適當調整即可。比如說，每日站會這個環節就非常重要，不管是放在每天上午，還是放在每天下午，總之最好要有固定的周期。此外，每次?Sprint（迭代）結束后除了有評審會以外，Scrum?Master?不要忘記對本次?Sprint?做一個回顧與總結，哪些是本次迭代中做的好的地方，哪些是做的不好的，再對比上次迭代的的結論，哪些是有改進的，哪些是新的問題。
Scrum?提供了三類角色，分別是：Product?Owner（一般由產品經理擔任）、Scrum?Master（一般由開發經理擔任）、Scrum?Team（包括開發與測試人員），其中，Scrum?Master?的角色至關重要，對項目的成敗起決定性作用。
阿里巴巴也在廣泛使用?Scrum?敏捷開發模式，而且整個項目幾十人都可以用?Scrum，只是首先需要將整個團隊拆分成若干小團隊，保證每個小團隊按照?Scrum?進行操作，此外，再將每個小團隊的?Scrum?Master?召集在一起，再做一輪?Scrum，這就是所謂的?Scrum?of?Scrum。過程稍微復雜一點，但可以將敏捷用于更大的團隊規模，并能保證敏捷的效果。
CSDN：你認為Scrum?Master?的角色至關重要，對項目的成敗起決定性作用。那敏捷開發中由產品經理擔任Scrum?Master會有什么問題？
黃勇：我個人不太建議由產品經理來擔當Scrum?Master，原因如下：
CSDN：敏捷開發過程中測試團隊的職責和產出是什么？
黃勇：在敏捷開發過程中，我認為測試團隊的職責有以下幾點：
CSDN：除了Scrum，還有XP、CM、FDD、ASD、DSDM等敏捷開發方法，如何去選擇一個合適的敏捷開發工具或者方法呢？
黃勇：敏捷開發方法有很多，不僅僅只有Scrum?一種，其實不妨相互借鑒，再結合自身的特點，定義一套適合自己的敏捷開發方法。例如XP?中所提倡的結對編程、持續集成、測試驅動等，這些都是很好的方法，值得借鑒。包括看板也是一個很不錯的工具，可以結合Scrum?來工作。
CSDN：從博客上，你也研究過「使用看板進行敏捷開發」，能不能分享你的研究成果？
黃勇：敏捷開發工具“看板”,該詞匯來自于島國，當我看到看板的英文時，我真的驚呆了，看板竟然就是?Kanban？！
我們可以結合?Scrum?與?Kanban，讓項目管理更加有效，讓資源分配更加合理，讓績效考核更加公平！
- 對于項目經理而言，最擔心的就是項目進度不可控，不知道每位開發人員具體的工作進度，有了?Kanban?一切都是那么地清晰。
- 對于開發經理而言，最擔心的就是資源分配不合理，忙的人忙死，閑的人閑死，有了?Kanban?一切都是那么地自然。
- 對于開發人員而言，最擔心的就是績效考核不公平，“憑什么我做的比他多，拿的工資卻比他少？不公平啊！”有了?Kanban?一切都是那么地公平。
可見，項目經理、開發經理、開發人員擁有了?Kanban，也就擁有了和諧與快樂！
那么?Kanban?到底是什么呢？我們先來看看這張表格吧：
下面我們來理解一下這個表格吧！
- 這個表格有?5?列：Backlog（原始需求）、Selected（被選中的需求）、Develop（開發階段）、Deploy（部署階段）、Live（上線階段）
- 其中?Develop?階段包括?2?個子階段：Ongoing（進行中）、Done（已完成）
- 包括?3?中角色：產品經理（紅色小人）、開發人員（藍色小人）、部署人員（綠色小人），其實還有項目經理，只是他/她貫穿于始終，所有就沒有畫出來了。
在?Backlog?中放置了許多小卡片，它們在?Kanban?中被稱為?WIP（Work?In?Process，在制品）。對于產品經理而言，WIP?是需求，而對于開發人員與部署人員而言，WIP?卻是任務。
實際這些?WIP?卡片上都帶有一些文字描述，包括：標題、描述、優先級等信息。
需要注意的是，Selected、Develop、Deploy?下方有一個數字，該數字表示此階段中最多可以放置的?WIP?數量。例如，在?Selected?中最多只能放?2?個?WIP；在?Develop?中（包括它的子階段）最多只能放置?2?個?WIP。這里的數字只是一個示例，具體多少可根據團隊實際情況而定。有一個經驗公式可以參考“WIP?上限?=?團隊規模?*?2?-?1”，減?1?表示大家需要協作，例如：4?人的團隊，WIP?上限是?7。
也許有人會提出，為什么沒有?Test?階段？——?這個可以有，這里只是一個示例而已，你不妨自行加上去。
對于多個項目而言，可以在這張表格中添加更多的泳道（行），每一行相當于一個項目，所有的項目進度清晰明了。
好！繼續我們的?Kanban，有意思的事情即將發生！
產品經理挑選了?2?個?WIP?到?Selected?中，此時，由開發經理決定該任務的技術難度，并由項目經理將任務分配到指定的開發人員，也可將同一個任務分配給兩個人，讓他們去結對編程。
開發人員（架構師與程序員）可對?Selected?中的需求進行工作量評估，可采用投票的方式進行，最終給出一個合理的評估值，整個估算過程，項目經理無需參與，主要是開發人員共同完成。
開發經理可以對任務設置一個“分值”，這個分值可直接影響到后續的績效考核，所以對大家來說，這個分值是公開可見的，誰做的多，誰做得少，一目了?然。當然，開發人員也可以主動承擔具有更具挑戰的任務（為了鍛煉自己，也為了多拿點錢），但任務分配的決定權始終在項目經理手中。
現在假設?A、B?兩個任務已經分別被不同的開發人員處理了，那么這些任務就應該移動到?Ongoing?中，同時，產品經理可以從?Backlog?中挑選出?2?個優先級較高的需求到?Selected?中。這樣就保證?Selected?與?Develop?都達到了?WIP?的上限。
有人已經把?A?做完了，那么?A?就可以移動到?Done?中了。隨后，部署人員就可以開始干活了。
部署人員就可以將?A?從?Done?中移動到?Deploy?中，表示部署人員正在做這件事情。同時，做完了?A?任務的開發人員可以再做其它新任務，只需從?Selected?中移動到?Ongoing?中，移動這件事情不是開發人員隨意操作的，而是有項目經理負責的。產品經理發現?Selected?中只有一個?D，就可以考慮放入一些新的需求了。
此時，部署人員遇到了問題，發現?A?部署的時候總是報錯，跑不起來了。同時，其他開發人員也完成了?B?任務。
完成了?B?任務的開發人員本來是可以做新需求的，但項目經理發現?Develop?中只能放?2?個任務，所以肯定是后面的階段出現了問題，導致整個流程受阻了。項目經理可以靈活調度人力資源，集中火力解決現在所遇到的問題。
所以項目經理不得不放棄新的任務，去讓開發人員去幫助部署人員來解決問題。此時，其他的開發人員還在進行?C?任務。
部署的問題還沒來得及解決，此時?C?任務也完成了，同時，產品經理也放入了新的?K?需求，確保?Selected?這個水池是裝滿水的。
整個部署問題看起來比較搞人，所有的開發人員全都上陣了，集中更多人的智慧，解決這個棘手的問題。此時，產品經理不能放入更多的需求，由于此時?Selected?已經滿額了。其實，開發人員面對太多的需求時，往往都會倍感壓力，身心憔悴。
看來這個部署問題，確實夠折騰的，連產品經理都過來了湊熱鬧了。但他或許不懂技術，但多個人多個頭腦吧，正所謂“當局者迷，旁觀者清”，最終經過大家的努力，肯定會攻克這座碉堡！
幾天之后，Kanban?流程依舊是穩定的，大家分工協作，人力資源合理利用。大家是一個團隊，目標就是把項目做好，不會因為自己的事情做完了就閑置了。
我們不妨將這張表格貼到墻上去吧！讓每個員工都可以看到，讓過路的老板們也可以看到我們的辛苦努力，這確實是一種非常好的項目管理方法！
CSDN：一個成功的項目，離不開每個人的努力，能夠分享下你曾經的項目管理經驗？
黃勇：給大家提出以下?10?點建議及其目標：
此外，作為項目管理者，需要不斷在團隊中加強以下 6 點文化：
真正的開源并非只是代碼的開源，而是思想的開源
CSDN：你在開源方面有著諸多的建樹，例如，你是Smart?Framework開源框架創始人，你對「開源」怎么看？國內的開源的現在如何，對比國外呢？
黃勇：我個人認為，真正的開源并非只是代碼的開源，而是思想的開源。在做開源項目之前，建議能將自己的想法共享出來，而不是 埋頭閉門造車。我不反對“重造輪子”，因為我們需要更好的輪子，輪子好了車子才能跑得快。凡是有利也有弊，我們也不能盲目地選擇開源技術，因為并不是適合 別人的技術就適合自己，而是需要根據自身的需求，選擇最適合的開源技術，搭建恰如其分的架構。
有大量的新技術，我首先會去關注它，了解它是做什么的，可以解決什么問題，但我一開始絕不會去深入研究它，更不會去看它的源碼，因為一旦遇到這方面的需求場景，我就會從這個“知識庫”中去尋找最好的解決方案，如果仍然尋找不到最合適的開源技術，我才會嘗試自己去實現。
CSDN：能夠介紹下你寫的Smart?Framework的輕量級?Java?Web?開發框架？
黃勇：基于對開源的熱愛，以及上述中我的開源態度。我寫了一款名為?Smart?Framework?的輕量 級?Java?Web?開發框架，它基于“微內核?+?多插件”的體系架構，基于?Servlet?3.0?規范，不依賴于?Spring、 Hibernate?等開源框架，提供?IOC、AOP、ORM?等輕量級解決方案，并具備良好的可擴展性，前端直接使 用?HTML?+?CSS?+?JS?開發模式，同時也兼容?JSP、JSTL、Tag?等技術，后端提供?REST?服務接口（基于?JSON?格 式），沒有任何的?XML?配置文件，真正的零配置。我認為這些特性足以開發一些簡單的?Web?應用程序，至于復雜的功能，就留給插件去完善吧。
當初寫?Smart?的時候并沒有想到大家會對這個框架會如此感興趣，抱著分享的態度，并不想去推廣這個產品，僅僅只是想找到能夠理解自己開源思想 的同道中人。世事總難料，已經有一些企業和個人開始使用這款框架了，并提供了大量的改造與擴展。我很欣慰，因為我基本上實現了自己的愿望，并希望將來會出 現有更好的?Java?Web?框架，丟掉重量級的帽子，披上輕量級的外衣。
技術人的歸途
編者注：在采訪期間，小編和一位同是十年工作經驗的coder聊天，發現他正陷于轉型做管理、深耕技術的泥潭，為此向黃勇老師請教，得出了一個非常不錯的中肯建議，也整理在這里，希望對你有所幫助。
CSDN：走技術這條路，歸途是什么？是否轉型又該如何抉擇呢？
黃勇：至少有好幾條路線是可以走的，比如：深入技術、轉型做產品、轉型做管理等，需要根據自己的特長和性格來選擇，做自己喜歡的事情。
從技術轉管理，對自身的要求比較高，說具體點，需要看自己的情商，為人處世的經驗，與人溝通的技巧，自己也需要有足夠的胸懷，去包容一些事情，還需要自己有足夠的人格魅力去吸引別人，讓別人愿意跟著你一起做事。管理有些東西是很難從書本上學到的，但一些經典的管理理論是必須要去學的。
相比較而言，繼續深入技術或者從技術轉產品會容易一些了，因為很多時候都不太需要與人打交道
CSDN：關于機遇，是可遇不可求的。比如，當管理，那也是有一定的環境造就，你得有這個機會去試一下，才知道自己是否感興趣做管理，以及是否適合等。
黃勇：沒錯，機遇太重要了，而且有些時候，機遇是可以考自己的努力去得到的，說到底還是與人溝通，讓自己的老板給自己機會，如果現在的公司給不了自己足夠的機遇，那么不妨考慮一下外面的機遇。總之，自己需要靈活處理，伴隨公司共同成長才是最好的。
CSDN：程序員相對比較「直」，也就是有啥說啥，事后或許才發現說了不該說的話，情商不高，如果改善這一情況呢？
黃勇：性格比較直，說話容易得罪人，這個很正常了，只不過首先需要向對方闡明自己的觀點，是為了把這件事情做好，和對方的目標是一致的，也就是說，首先與對方共同的價值觀，然后再說自己的想法，并多聽取對方的意見，盡量多和對方保持相同的看法，最后需要注意的是，自己不擅長的方面，盡量多聽少說，聽也是在學習。
在聽的過程中，可以表達自己的認識，并詢問對方是否這樣理解的。
CSDN：最后，你是怎么分配一天的時間的？閑暇時，喜歡做些什么來放松自己？
黃勇：平時工作我一般都比較忙，會議占據了我大部分時間，在自己僅有的工作時間里我會花更多的時間與團隊主管們進行溝通，讓大家保持一致的方向，這樣每個技術主管也會帶出更適合公司文化的團隊。總之，技術氛圍不是一兩天就能形成的，需要長時間的溝通，這個時間對于技術管理人員是必須要付出的。
在閑暇之余，我喜歡聽音樂，也喜歡和朋友聊天，朋友是自己的一面鏡子，可以通過這面鏡子來看清自己，其實人這一輩子都是在不斷地看清自己，認識自己。
寫給讀者的話：
非常感謝讀者們能夠花自己寶貴的時間來閱讀本文，其實我自己也和大家一樣，我們都在不斷地學習，不斷地提高自己，真心希望本文能夠幫助大家。此外，我也很期待大家能與我進一步互動，我平時也會在線下組織一些小規模的技術交流活動，希望大家能夠相互認識，相互分享，相互幫助。
聯系方式：hy_think@163.com
如果你對本文有任何建議，歡迎致郵CSDN編輯錢曙光：qianshg@csdn.n
總結
以上是生活随笔為你收集整理的专访黄勇：Java在未来的很长一段时间仍是主流的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Uber创始人：一个优秀创业者应具八种特
- 下一篇： 百度发布机器人助理度秘 “三大基石”炼成