還在為如何成為優(yōu)秀架構(gòu)師而苦惱嗎?近日,匯量科技(Mobvista)集團(tuán)副總裁兼首席工程架構(gòu)師蔡超做客QCon+案例研習(xí)社線上發(fā)布會,為我們帶來了答案。

圖片來源于Mobvista

蔡超擁有17年軟件開發(fā)經(jīng)驗,其中有超過10年在HP、Amazon等世界級公司任職軟件架構(gòu)師/首席架構(gòu)師。先后領(lǐng)導(dǎo)開發(fā)了網(wǎng)絡(luò)安全管理系統(tǒng)(TopAnalyzer)、HP(中國)移動設(shè)備管理系統(tǒng)、亞馬遜全球的新外部直運(yùn)(External Fulfillment)平臺、亞馬遜物流+系統(tǒng)、亞馬遜全球客服系統(tǒng)以及大型彈性集群管理平臺SpotMax等?；诙嗄陮崙?zhàn)經(jīng)驗,蔡超總結(jié)并分享了他在架構(gòu)師成長之路上的8大竅門,為同行們帶來更多思考。

右1為匯量科技(Mobvista)集團(tuán)副總裁兼首席工程架構(gòu)師蔡超

以下是蔡超的分享內(nèi)容:

到現(xiàn)在我工作17年了,期間不僅在HP,Amazon這樣的世界級團(tuán)隊中擔(dān)任過架構(gòu)師,也在匯量科技這樣快速成長的企業(yè)中擔(dān)任過技術(shù)領(lǐng)導(dǎo)?；诔^十年的架構(gòu)師工作經(jīng)驗,我將和大家分享一下這些年的成功與失敗,希望能幫助大家避開那些我曾踩過的坑。

　　“提出問題”難于“解決問題”

作為技術(shù)人員我們往往習(xí)慣于給出設(shè)計方案,做一個問題的解決者,而很少做一個問題的提出者,去思考要設(shè)計什么。團(tuán)隊中最常見的典型矛盾是產(chǎn)品團(tuán)隊和研發(fā)團(tuán)隊的矛盾。作為研發(fā)團(tuán)隊,我們常吐槽產(chǎn)品團(tuán)隊的需求不合理,不懂技術(shù)等。

其實我們可以嘗試把自己的工作在往前移一下,不僅僅是去設(shè)計架構(gòu)實現(xiàn)產(chǎn)品的需求,而是去實現(xiàn)客戶的需求,甚至發(fā)現(xiàn)潛在需求。

變成在設(shè)計上提出問題的人后,你會發(fā)現(xiàn)提出問題同樣需要深入思考,設(shè)計一個好的問題,有時候甚至比解決問題更難。

即便是軟件開發(fā)領(lǐng)域的大神Frederick P. Brooks Jr.(《人月神話》的作者)也會有同樣的感嘆,“The hardest part of design is deciding what to design.” 這句話便是出自他的《The design of design》。

　　決定“不要什么”比“要什么”更難

也許是由于人性的貪婪,對于軟件系統(tǒng)我們同樣想要更多:更多功能,更好的性能,更好的伸縮性,擴(kuò)展性等等。作為軟件架構(gòu)師要明白軟件架構(gòu)設(shè)計其實是一種取舍或平衡。當(dāng)大家都在往里面加?xùn)|西的時候,架構(gòu)師更應(yīng)該來做這個說不的人。

軟件設(shè)計和定義過程中存在很多取舍,如完善功能和及早發(fā)布的取舍、伸縮性和性能的取舍等。如何做好取舍?著名的CAP原則就是一個很好的關(guān)于取舍的指導(dǎo)策略。為保持架構(gòu)風(fēng)格的一致性,在一開始架構(gòu)師就應(yīng)該根據(jù)系統(tǒng)的實際需求來定義一些取舍的原則,如:數(shù)據(jù)一致性擁有最高優(yōu)先級,提前發(fā)布核心功能優(yōu)于完整發(fā)布等。

　　非功能性需求決定架構(gòu)

很多設(shè)計人員可能會認(rèn)為架構(gòu)是由要實現(xiàn)的功能性需求決定的,但實際上真正決定軟件架構(gòu)的其實是非功能性需求。因此,架構(gòu)師需更加關(guān)注非功能性需求,如性能,伸縮性,擴(kuò)展性和可維護(hù)性,甚至包括團(tuán)隊技術(shù)水平和發(fā)布時間要求等。能實現(xiàn)功能性需求的設(shè)計方案有很多,只有考慮了非功能性需求后才能篩選出最合適的設(shè)計。

《面向模式的軟件架構(gòu)》這套書為不同的非功能性需求提供了很好的參考和指導(dǎo),多年來一直是架構(gòu)師們的必讀經(jīng)典。下圖的架構(gòu)模式便是來自這本書的第一卷,圖中的Micro-Kernel模式,更加關(guān)注可擴(kuò)展性和可用性(錯誤隔離)。

“簡單”并不“容易”

很多架構(gòu)師常常會提到保持簡單,但有時候我們往往會混淆簡單和容易。簡單和容易在英語里是兩個不同的詞“simple”和“easy”。

史蒂夫·喬布斯曾說過“Simple can be harder than complex:You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.To be truly simple, you have to go really deep.”

真正的簡單方法往往是來自于對問題和技術(shù)的更深入理解,簡單可以說蘊(yùn)含著一種深入的巧妙在其中。下面我來舉一個例子。

據(jù)數(shù)據(jù)顯示,在一款軟件系統(tǒng)的生命周期中,成本消耗占比最大的部分往往在于維護(hù)。因此如果能簡化維護(hù)部分,對于整個項目將具有全局性的意義。

我們曾經(jīng)為移動運(yùn)營商開發(fā)過一個系統(tǒng)設(shè)備管理系統(tǒng),移動運(yùn)營商期待通過該系統(tǒng)管理移動設(shè)備,因此,系統(tǒng)需實現(xiàn)包括設(shè)備的自動注冊,固件和軟件的同步等管理功能。這些功能可通過一些管理系統(tǒng)與移動設(shè)備間的預(yù)定義的交互協(xié)議來完成,過程中,電信專家們會根據(jù)業(yè)務(wù)場景及需求來調(diào)整和新增這些交互協(xié)議。起初我們采用了一種容易實現(xiàn)的方式,即團(tuán)隊中的軟件工程師根據(jù)電信專家的說明將協(xié)議實現(xiàn)為對應(yīng)代碼。

但很快我們便發(fā)現(xiàn)這樣的方式不僅沒有讓項目更容易,反而讓我們的工作變得更復(fù)雜。

“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”--Martin Fowler

正如軟件開發(fā)大師MartinFowler所說“溝通”往往是導(dǎo)致軟件項目失敗的主要問題。這個項目最大的問題是在系統(tǒng)上線后的運(yùn)行維護(hù)階段,電信專家和開發(fā)工程師之間會不斷就新的協(xié)議修改和增加持續(xù)溝通,而由于雙方的知識和詞匯存在很大區(qū)別,導(dǎo)致了溝通效率低、系統(tǒng)維護(hù)(協(xié)議的修改)變得十分艱難,協(xié)議更新上線慢等問題。同時,由于軟件工程對于電信協(xié)議的理解程度有限,很多問題往往在實際上線后才暴露出來,導(dǎo)致了很多交換和反復(fù)。

針對這一問題,我們和電信專家一起設(shè)計了一種協(xié)議設(shè)計語言(并提供可視化的工具)。這種設(shè)計語言使用的是電信專家所熟悉的詞匯,然后通過一個類似于編譯器的程序?qū)㈦娦艑＜叶x好的協(xié)議模型轉(zhuǎn)換為內(nèi)存中的Java結(jié)構(gòu)。整個項目的運(yùn)行與維護(hù)因此變得簡單高效,省去了低效的溝通和不準(zhǔn)確的人工轉(zhuǎn)換。

不難看出,一開始按電信專家的說明直接實現(xiàn)協(xié)議看似更為容易,但放在整個軟件的生命周期中,這卻并非一個簡單高效的方法。

永遠(yuǎn)不要停止編碼

架構(gòu)師也是程序員,代碼是軟件的最終實現(xiàn)形態(tài),停止編程會逐漸讓你忘記作為程序員的感受,更重要的是忘記其中“痛”,從而容易產(chǎn)生一些不切實際的設(shè)計。在亞馬遜,高級副總裁級別的distinguish Engineer,如被稱為Java之父的James Gosling等每年的編碼量均不低于10萬行。

風(fēng)險優(yōu)先

架構(gòu)設(shè)計很重要的一點(diǎn)是識別可能存在的風(fēng)險,尤其是非功能性需求實現(xiàn)的風(fēng)險。因為這些風(fēng)險往往沒有功能性需求這么容易在初期就被發(fā)現(xiàn),但修正的代價卻比修正功能性需求的代價大很多,嚴(yán)重時甚至可能導(dǎo)致項目失敗。

因此,我們應(yīng)該在原型或早期的迭代中確認(rèn)風(fēng)險,并通過合理的架構(gòu)解決風(fēng)險。絕對不要把風(fēng)險放到最后,就算是一個項目要失敗也要讓它快速失敗,這也是一種敏捷。

從“問題”開始,而不是“技術(shù)”

技術(shù)人員對新技術(shù)有著一種與身俱來的激情,總是樂于學(xué)習(xí)新技術(shù)和使用新技術(shù)。這容易導(dǎo)致一個通病,就是“當(dāng)我們有一個錘子的時候看什么都是釘子”,因而使用一些不適合的技術(shù)去解決手邊的問題,導(dǎo)致簡單問題復(fù)雜化。

我曾經(jīng)的一個團(tuán)隊便發(fā)生過類似事件,原本是一個用MySQL作數(shù)據(jù)存儲的簡單服務(wù),但由于當(dāng)時負(fù)責(zé)該項目的人員對彼時新出的DynamoDB產(chǎn)生了興趣并學(xué)習(xí)了相關(guān)知識,因此該成員決定使用DynamoDB替換MySQL。

之后很快發(fā)現(xiàn)DynamoDB并不能很好地支持事務(wù)特性,在當(dāng)時只有一個性能極差的客戶端類庫支持事務(wù),而由于采用了客戶端方式,引入了大量額外交互,導(dǎo)致性能差別達(dá)到7倍之多。

這時候,這個成員就采用了當(dāng)時在NoSQL領(lǐng)域廣泛流行的最終一致技術(shù),通過一個Pub-Sub消息隊列來實現(xiàn)最終一致(即當(dāng)某對象的值發(fā)生改變后會產(chǎn)生一個事件,然后關(guān)注這一改變的邏輯,就會訂閱這個通知,并改變于其相關(guān)數(shù)據(jù),從而實現(xiàn)不同數(shù)據(jù)的最終一致)。

接著由于DynamoDB無法提供SQL那樣方便的查詢機(jī)制,為了實現(xiàn)數(shù)據(jù)分析不得不又引入了EMR/MapReduceJob。

到此,大家可以看到雖然最后實現(xiàn)了一樣的功能,但是項目的復(fù)雜性大大增加,維護(hù)工作也由一個人變成了一個團(tuán)隊。

過度繁忙使你落后

對于IT人而言,加班是家常便飯,“996”似乎成為了公司高效的標(biāo)志。但事實上沒日沒夜的忙碌往往會擠壓我們的學(xué)習(xí)時間,導(dǎo)致我們失去知識更新的意識,不知不覺變得落后,最終失去跳槽的能力與勇氣。

在今天這個高速發(fā)展的時代,我在工作經(jīng)歷中發(fā)現(xiàn)過度繁忙往往會帶來以下問題,首先是缺乏學(xué)習(xí)導(dǎo)致工作能力難以提升無法面對日益復(fù)雜的需求;其次,在技術(shù)上與業(yè)務(wù)上喪失領(lǐng)先優(yōu)勢,只能被動追趕,而被動追趕又會讓我們更加忙碌,最終形成惡性循環(huán)。

個人技術(shù)的成長就像健身,僅靠鍛煉還不夠,營養(yǎng)的補(bǔ)充同樣重要。當(dāng)你在一個領(lǐng)域工作一段時間以后,工作對你而言就主要是實踐了,隨著你對該領(lǐng)域的熟悉,能學(xué)習(xí)的到的技術(shù)會越來越少。所以每個技術(shù)人員都要保證充足的學(xué)習(xí)時間,否則很容易成為井底之蛙,從而陷入前面提到的惡性循環(huán)。

最后,以偉大詩人屈原的詩句和大家共勉“路漫漫其修遠(yuǎn)兮,吾將上下而求索“希望我們大家都可以不忘初心,保持匠心!

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）