一位架構師的感悟:過度忙碌使你落後

我踩過的坑,希望大家不用再踩。

到現在我工作17年了, 擔任架構師的職位也超過了10年,擔任過像HP、Amazon這樣的世界級團隊的架構師,也擔任過像匯量科技這樣快速成長的中小企業的技術領導。應InfoQ邀請分享一下我的工作感悟,分享內容部分來自成功總結,更多是來自失敗的反思,希望我踩過的坑大家可以不用再踩。

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

作爲技術人員,我們已經習慣於作爲問題的解決者給出設計方案,而很少以問題提出者的身份去思考設計方案。團隊中常見的典型矛盾,就是產品團隊和研發團隊之間的矛盾。作爲研發團隊,我們常吐槽產品團隊的需求不合理、不懂技術等。其實我們可以試着把自己的工作再往前移一下,不僅僅是去設計架構、實現產品的需求,同時也試着去實現客戶的需求,甚至發現潛在的需求。

這時我們就變成了在設計上提出問題的人,你會發現提出問題的同時,在很多時候也需要同樣深入的思考。設計一個好的問題,甚至比解決問題更難。

其實即便是軟件開發領域的大神Frederick P. Brooks Jr.(《人月神話》的作者)也會有同樣的感嘆。

“The hardest part of design is deciding what to design.”

– 《The design of design》, by Frederick P. Brooks Jr.

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

也許是由於人性的貪婪,對於軟件系統我們同樣想要更多:更多功能、更好的性能、更好的伸縮性、擴展性等等。作爲軟件架構師要明白軟件架構設計就是一種取捨或平衡。當大家都在往裏面加東西的時候,架構師更應該來做這個說“不”的人。

軟件設計和定義過程中存在很多取捨,例如:

  • 完善功能和儘早發佈的取捨。
  • 伸縮性和性能的取捨。

著名的CAP原則,就是一個很好的取捨指導策略。爲了更好的取捨,保持架構風格的一致性,在一開始架構師就應該根據系統的實際需求來定義一些取捨的原則,如:

  • 數據一致性擁有最高優先級。
  • 提前發佈核心功能優於完整發布等。

非功能性需求決定架構

因爲軟件是爲了滿足客戶的功能性需求的,所以很多設計人員可能會認爲架構是由要實現的功能性需求決定的。但實際上真正決定軟件架構的其實是非功能性需求。

架構師要更加關注非功能性需求,常見的非功能性包括:性能,伸縮性,擴展性和可維護性等,甚至還包括團隊技術水平和發佈時間要求。能實現功能的設計總是有很多,考慮了非功能性需求後才能篩選出最合適的設計。

以上架構模式來自《面向模式的軟件架構》的第一卷,這套書多年來一直是架構師的必讀經典。面向架構的模式就是爲不同的非功能性需求提供了很好的參考和指導。圖中的Micro-Kernel模式,更加關注可擴展性和可用性(錯誤隔離)。

“簡單”並不“容易”

很多架構師都會常常提到保持簡單,但是有時候我們會混淆簡單和容易。簡單和容易在英語裏也是兩個詞“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.”

–SteveJobs

真正的一些簡單的方法其實來自於對問題和技術更深入的理解。這些方案往往不是容易獲得的、表面上的方法。簡單可以說蘊含着一種深入的技巧在其中。

下面我來舉一個例子。

首先我們來回顧一下軟件生命週期中各個階段的成本消耗佔比。以下是來一個知名統計機構的分析報告。我們可以看到佔比最大的是維護部分,對於這一部分的簡化將最具有全局意義。

我曾經開發過一個設備管理系統,移動運營商通過這個系統來管理移動設備,實現包括設備的自動註冊、固件和軟件的同步等管理功能。這些功能是通過一些管理系統與移動設備間的預定義的交互協議來完成的。

電信專家們會根據業務場景及需求來調整和新增這些交互協議。起初我們採用了一種容易實現的方式,即團隊中的軟件工程會根據電信專家的說明,將協議實現爲對應代碼。

之後我們很快發現這樣的方式,讓我們的工作變得沒那麼簡單。

“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

正如軟件開發大師MartinFowler提到的,“溝通”往往是導致軟件項目失敗的主要原因。前面這個項目最大的問題是在系統上線後的運行維護階段,電信專家和開發工程師之間會不斷就新的協議修改和增加進行持續的溝通,而他們的領域知識和詞彙都有很大的差別,這會大大影響溝通的效率。因此這期間系統的運行維護(協議的修改)變得十分艱難,不僅協議更新上線時間慢,而且由於軟件工程對於電信協議理解程度有限,很多問題都要在實際上線使用後才能被電信專家發現,導致了很多的交換和反覆。

針對上面提到的問題,後來我們和電信專家一起設計了一種協議設計語言(並提供可視化的工具),這種設計語言使用的電信專家所熟悉的詞彙。然後通過一個類似於編譯器的程序將電信專家定義好的協議模型轉換爲內存中的Java結構。這樣整個項目的運行和維護就變得簡單高效了,省去了低效的交流和不準確人工轉換。

我們可以看到一開始按電信專家的說明直接實現協議是更爲容易的辦法,但就整個軟件生命週期來看卻並不是一個簡單高效的方法。

永遠不要停止編碼

架構師也是程序員,代碼是軟件的最終實現形態,停止編程會逐漸讓你忘記作爲程序員的感受,更重要的是忘記其中的“痛”,從而容易產生一些不切實際的設計。

大家可能聽說過在Amazon,高級副總裁級別的Distinguish Engineer(如:James Gosling,Java之父),他們每年的編碼量也非常大,常在10萬行以上。

風險優先

架構設計很重要的一點是識別可能存在的風險,尤其是非功能性需求實現的風險。因爲這些風險往往沒有功能性需求這麼容易在初期被發現,但修正的代價通常要比修正功能性需求大非常多,甚至可能導致項目的失敗,前面我們也提到了非功能性需求決定了架構,如數據一致性要求、響應延遲要求等。

我們應該通過原型或在早期的迭代中確認風險能夠通過合理的架構得以解決。

絕對不要把風險放到最後,就算是一個項目要失敗也要讓它快速失敗,這也是一種敏捷。

從“問題”開始,而不是“技術”

技術人員對於新技術的都有着一種與身俱來的激情,總是樂於去學習新技術,同時也更有激情去使用新技術。但是這也同樣容易導致一個通病,就是“當我們有一個錘子的時候看什麼都是釘子”,使用一些不適合的技術去解決手邊的問題,常常會導致簡單問題複雜化。

我曾經的一個團隊維護過這樣一個簡單的服務,起初就是一個用MySQL作數據存儲的簡單服務,由團隊的一個成員來開發和維護。後來,這位成員對當時新出的DynamoDB產生了興趣,並學習了相關知識。

然後就發生下面這樣的事:

  • 用DynamoDB替換了MySQL。
  • 很快發現DynamoDB並不能很好的支持事務特性,在當時只有一個性能極差的客戶端類庫來支持事物,由於採用客戶端方式,引入了大量的額外交互,導致性能差別達7倍之多。這時候,這個同學就採用了當時在NoSQL領域廣泛流行的最終一致技術,通過一個Pub-Sub消息隊列來實現最終一致(即當某對象的值發生改變後會產生一個事件,然後關注這一改變的邏輯,就會訂閱這個通知,並改變於其相關數據,從而實現不同數據的最終一致)。
  • 接着由於DynamoDB無法提供SQL那樣方便的查詢機制,爲了實現數據分析就又引入了EMR/MapReduceJob。

到此,大家可以看到實現一樣的功能,但是複雜性大大增加,維護工作也由一個人變成了一個團隊。

過度忙碌使你落後

對於IT人而言忙碌已成爲了習慣,加班常掛在嘴邊。“996”工作制似乎也變成了公司高效的標誌。而事實上過度的忙碌使你落後。經常遇見一些朋友,在一個公司沒日沒夜的幹了幾年,沒有留一點學習時間給自己。幾年之後倒是對公司越來越“忠誠”了,但忙碌的工作同時也導致了沒有時間更新知識,使得自己已經落後了,連跳槽的能力和勇氣都失去了。

過度忙碌會導致沒有時間學習和更新自己的知識,尤其在這個高速發展的時代。我在工作經歷中發現過度繁忙通常會帶來以下問題:

  • 缺乏學習導致工作能力沒有提升,而面對的問題卻變得日益複雜。
  • 技術和業務上沒有更大的領先優勢,只能被動緊緊追趕。試想一下,要是你都領先同行業五年了,還會在乎通過加班來早一個月發佈嗎?

反過來上面這些問題會導致你更加繁忙,進而更沒有時間提高自己的技術技能,很快就形成了一個惡性循環。

練過健身的朋友都知道,光靠鍛鍊是不行的,營養補充和鍛鍊同樣重要。個人技術成長其實也一樣,實踐和學習是一樣重要的,當你在一個領域工作了一段時間以後,工作對你而言就主要是實踐了,隨着你對該領域的熟悉,能學習的到技術會越來越少。所以每個技術人員都要保證充足的學習時間,否則很容易成爲井底之蛙,從而陷入前面提到的惡性循環。

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

作者簡介:

蔡超,Mobvista技術VP兼首席架構師,SpotMax雲服務創始人。擁有超過15 年的軟件開發經驗,其中9年任世界級 IT 公司軟件架構師/首席軟件架構師。2017年加入Mobvista,任公司技術副總裁及首席架構師,領導公司的數字移動營銷平臺的開發,該平臺完全建立於雲計算技術之上,每天處理來自全球不同region的超過600億次的請求。

在加入Mobvista之前,曾任亞馬遜全球直運平臺首席架構師,亞馬遜(中國)首席架構師,曾領導了亞馬遜的全球直運平臺的開發,並領導中國團隊通過AI及雲計算技術爲中國客戶打造更好的本地體驗;曾任 HP(中國)移動設備管理系統首席軟件架構師,該系統曾是全球最大的無線設備管理系統(OMA DM)(客戶包括中國移動,中國聯通,中國電信等);曾任北京天融信網絡安全技術公司,首席軟件架構師,領導開發的網絡安全管理系統(TopAnalyzer)至今仍被政府重要部門及軍隊廣爲採用,該系統也曾成功應用於 2008 北京奧運,2010 上海世博等重要事件的網絡安全防護。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章