黃勇,從事近十年的 JavaEE 應用開發工作,現任阿里巴巴公司系統架構師。對分佈式服務架構與大數據技術有深入研究,具有豐富的 B/S 架構開發經驗與項目實戰經驗,擅長敏捷開發模式。國內開源軟件推動者之一,Smart Framework 開源框架創始人。熱愛技術交流,樂於分享自己的工作經驗。著有《架構探險——從零開始寫Java Web框架》一書。
我的十年技術之路
和大家介紹下我目前所從事的工作。
我目前從事分佈式服務架構的設計與開發工作,在阿里的大數據平臺上進行應用程序開發。我們整個系統架構採用了“前後端分離”的思想,前端關注數據展現,後端關注數據生產,通過 REST服務將前後端整合起來,所有的應用都是無狀態的,可以做到水平擴展。我們將整個系統拆分成許多“微服務”,服務之間通過統一的接口來調用,每個服務是通過容器技術進行隔離,此外服務可發佈到統一的服務管理平臺上,可通過該平臺監控每個服務的運行狀態與生命週期事件,併為服務調用者提供了服務發現的能力,可對服務進行平滑升級。
阿里有許多優秀的中間件與基礎服務,可以快速幫助我們搭建應用系統,而且這些技術在阿里內部全是開源的,大家可以通過源碼和文檔學習到很多有價值的經驗。阿里也提供了濃厚的技術氛圍,每位同學都非常專注於自己的工作領域,大家對工作一絲不苟,相互配合,方向一致。
我是如何走上技術這條路的?
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 框架》這本書,目前該書正在各大網上書店售賣,我真心希望這本書能對一些想成為架構師的程序員們有所幫助,由於我個人水平有限,又是第一次寫書,寫得不好的地方還請大家多多包涵。
上面提到,寫博客給我帶來的收穫頗多,那麼我來分享下技術人如何寫博客,又應該以怎樣的態度對待。
我認為技術人員寫博客需要注意以下幾點:
思路要清晰,文章要有明確的大綱與標題。
對於實戰類型的文章,需要分步驟來描述。
多用短句,少用長句,能一句話說明白,就不用兩句話。
對於不太好理解的內容,最好能打比方來說明。
文章末尾需要有總結,用最精闢的語言歸納出這篇文章的主要內容。
寫博客首先是對自己所學知識的一個總結,此外,也為其他讀者提供了很好的教程,知識得到了廣播與傳遞。
技術一條不歸路,選擇了這條路從未有過放棄的想法。
做了十年的技術,我從來都沒有放棄過它,相反,我非常熱愛它,因為我一直以來都很喜歡學習,希望能學到更多的東西,這樣遇到了具體的技術問題,可以隨時從自己積累的知識庫中找到最佳的解決方案。此外,目前我在公司雖然不怎麼寫代碼了,但我還是會利用自己工作閒暇之餘寫一點開源項目或者代碼框架等。
工作過很多大大小小的公司,那麼公司最值錢的東西是什麼呢?
我認為是實實在在做事情的程序員們。
他們雖然工資不高,每天坐在位置上敲著代碼,在很多人眼中被稱為“屌絲”或“宅男”,但我認為恰恰就是這些人,他們才是公司最有價值的人。
- 他們有自己的理想,希望能夠通過自己的努力,從中得到那一點點所謂的成就感;
- 他們需要理解產品經理真正的意圖,把想法變成現實,讓產品真正落地;
- 他們更容易把握細節,而這些細節往往決定著產品的命運與成敗;
- 他們突如其來的跳槽,對我們的項目的交付有直接的影響;
- 他們在一起工作的氣氛,能體現技術公司的文化與底蘊。
由此看來,對程序員的重視是相當有必要的,我們需要關心每一位程序員的職業發展,讓他們在團隊裡能夠充分地發揮出自己的能力。
我們也需要對他們倍加關注,挖掘出有能力、肯吃苦、敢擔當的人,給他們更多的機會,讓他們成為技術領袖。
互聯網技術公司需要大量這樣的程序員:
- 他們是一群有著技術信仰的人,他們是一群熱愛編程的人,他們是一群不解決問題睡不好覺的人;
- 他們不是打雜的,不是外包,更不是工具;
- 他們不喜歡被忽悠,不喜歡被冷落,更不喜歡被驅動;
- 他們需要尊重,需要培養,更需要激情!
具體說說程序員需要具備哪些素質。
我個人是這樣理解真正的程序員的:
- 深愛技術,一天不寫代碼手就會癢,就喜歡那種成就感;
- 為了一個問題可以廢寢忘食,有時會在夢中都能寫代碼;
- 代碼潔癖症患者,喜歡優雅代碼,寫代碼就像寫詩一樣;
- 善於分析問題,能快速看清問題的本質,並動手解決它;
- 喜歡研究優秀源碼,學習大師的傑作,善於歸納與總結;
- 有自己的開源項目或技術博客,喜歡學習,更喜歡分享;
- 會關注技術圈子的新聞動態,時常會參加線下技術沙龍;
- 知道軟件開發不是一個人在戰鬥,更需要的是團隊協作;
- 保持良好健康的心態,用一顆積極向上的心去擁抱變化。
十年的職場之路堅持不易,分享下我的「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 方法供外界調用。
關注我:私信回覆“架構資料”獲取往期Java高級架構資料、源碼、筆記、視頻
Dubbo、Redis、設計模式、Netty、zookeeper、Spring cloud、分佈式、
高併發等架構技術