Mobvista首席架构师蔡超：工作感悟之失败与成功，我的8点总结
蔡超
讀完需要
9
分鐘速讀僅需 3 分鐘
蔡超，Mobvista 技術 VP 兼首席架構師，SpotMax 云服務創始人。擁有超過 15 年的軟件開發經驗，其中 9 年任世界級 IT 公司軟件架構師 / 首席軟件架構師。
2017 年加入 Mobvista，任公司技術副總裁及首席架構師，領導公司的數字移動營銷平臺的開發，該平臺完全建立于云計算技術之上，每天處理來自全球不同 region 的超過 600 億次的請求。
在加入 Mobvista 之前，曾任亞馬遜全球直運平臺首席架構師，亞馬遜（中國）首席架構師，曾領導了亞馬遜的全球直運平臺的開發，并領導中國團隊通過 AI 及云計算技術為中國客戶打造更好的本地體驗；
曾任 HP（中國）移動設備管理系統首席軟件架構師，該系統曾是全球最大的無線設備管理系統（OMA DM）（客戶包括中國移動，中國聯通，中國電信等）；
曾任北京天融信網絡安全技術公司，首席軟件架構師，領導開發的網絡安全管理系統（TopAnalyzer）至今仍被政府重要部門及軍隊廣為采用，該系統也曾成功應用于 2008 北京奧運，2010 上海世博等重要事件的網絡安全防護。
到現在我工作 17 年了， 擔任架構師的職位也超過了 10 年，擔任過像 HP、Amazon 這樣的世界級團隊的架構師，也擔任過像匯量科技這樣快速成長的中小企業的技術領導。
應 InfoQ 邀請分享一下我的工作感悟，分享內容部分來自成功總結，更多是來自失敗的反思，希望我踩過的坑大家可以不用再踩。
1
? ?
“提出問題”難于“解決問題”
作為技術人員，我們已經習慣于作為問題的解決者給出設計方案，而很少以問題提出者的身份去思考設計方案。團隊中常見的典型矛盾，就是產品團隊和研發團隊之間的矛盾。作為研發團隊，我們常吐槽產品團隊的需求不合理、不懂技術等。其實我們可以試著把自己的工作再往前移一下，不僅僅是去設計架構、實現產品的需求，同時也試著去實現客戶的需求，甚至發現潛在的需求。
這時我們就變成了在設計上提出問題的人，你會發現提出問題的同時，在很多時候也需要同樣深入的思考。設計一個好的問題，甚至比解決問題更難。
其實即便是軟件開發領域的大神 Frederick P. Brooks Jr.（《人月神話》的作者）也會有同樣的感嘆。
“The hardest part of design is deciding what to design.” -- 《The design of design》, by Frederick P. Brooks Jr.
2
? ?
決定“不要什么”比“要什么”更難
也許是由于人性的貪婪，對于軟件系統我們同樣想要更多：更多功能、更好的性能、更好的伸縮性、擴展性等等。作為軟件架構師要明白軟件架構設計就是一種取舍或平衡。當大家都在往里面加東西的時候，架構師更應該來做這個說“不”的人。
軟件設計和定義過程中存在很多取舍，例如：
完善功能和盡早發布的取舍。
伸縮性和性能的取舍。
著名的 CAP 原則，就是一個很好的取舍指導策略。為了更好的取舍，保持架構風格的一致性，在一開始架構師就應該根據系統的實際需求來定義一些取舍的原則，如：
數據一致性擁有最高優先級。
提前發布核心功能優于完整發布等。
3
? ?
非功能性需求決定架構
因為軟件是為了滿足客戶的功能性需求的，所以很多設計人員可能會認為架構是由要實現的功能性需求決定的。但實際上真正決定軟件架構的其實是非功能性需求。
架構師要更加關注非功能性需求，常見的非功能性包括：性能，伸縮性，擴展性和可維護性等，甚至還包括團隊技術水平和發布時間要求。能實現功能的設計總是有很多，考慮了非功能性需求后才能篩選出最合適的設計。
以上架構模式來自《面向模式的軟件架構》的第一卷，這套書多年來一直是架構師的必讀經典。面向架構的模式就是為不同的非功能性需求提供了很好的參考和指導。圖中的 Micro-Kernel 模式，更加關注可擴展性和可用性（錯誤隔離）。
4
? ?
“簡單”并不“容易”
很多架構師都會常常提到保持簡單，但是有時候我們會混淆簡單和容易。簡單和容易在英語里也是兩個詞“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.” --Steve Jobs
真正的一些簡單的方法其實來自于對問題和技術更深入的理解。這些方案往往不是容易獲得的、表面上的方法。簡單可以說蘊含著一種深入的技巧在其中。
下面我來舉一個例子。
首先我們來回顧一下軟件生命周期中各個階段的成本消耗占比。以下是來一個知名統計機構的分析報告。我們可以看到占比最大的是維護部分，對于這一部分的簡化將最具有全局意義。
我曾經開發過一個設備管理系統，移動運營商通過這個系統來管理移動設備，實現包括設備的自動注冊、固件和軟件的同步等管理功能。這些功能是通過一些管理系統與移動設備間的預定義的交互協議來完成的。
電信專家們會根據業務場景及需求來調整和新增這些交互協議。起初我們采用了一種容易實現的方式，即團隊中的軟件工程會根據電信專家的說明，將協議實現為對應代碼。
之后我們很快發現這樣的方式，讓我們的工作變得沒那么簡單。
“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 結構。這樣整個項目的運行和維護就變得簡單高效了，省去了低效的交流和不準確人工轉換。
我們可以看到一開始按電信專家的說明直接實現協議是更為容易的辦法，但就整個軟件生命周期來看卻并不是一個簡單高效的方法。
5
? ?
永遠不要停止編碼
架構師也是程序員，代碼是軟件的最終實現形態，停止編程會逐漸讓你忘記作為程序員的感受，更重要的是忘記其中的“痛”，從而容易產生一些不切實際的設計。
大家可能聽說過在 Amazon，高級副總裁級別的 Distinguish Engineer（如：James Gosling，Java 之父），他們每年的編碼量也非常大，常在 10 萬行以上。
6
? ?
風險優先
架構設計很重要的一點是識別可能存在的風險，尤其是非功能性需求實現的風險。因為這些風險往往沒有功能性需求這么容易在初期被發現，但修正的代價通常要比修正功能性需求大非常多，甚至可能導致項目的失敗，前面我們也提到了非功能性需求決定了架構，如數據一致性要求、響應延遲要求等。
我們應該通過原型或在早期的迭代中確認風險能夠通過合理的架構得以解決。
絕對不要把風險放到最后，就算是一個項目要失敗也要讓它快速失敗，這也是一種敏捷。
7
? ?
從“問題”開始，而不是“技術”
技術人員對于新技術的都有著一種與身俱來的激情，總是樂于去學習新技術，同時也更有激情去使用新技術。但是這也同樣容易導致一個通病，就是“當我們有一個錘子的時候看什么都是釘子”，使用一些不適合的技術去解決手邊的問題，常常會導致簡單問題復雜化。
我曾經的一個團隊維護過這樣一個簡單的服務，起初就是一個用 MySQL 作數據存儲的簡單服務，由團隊的一個成員來開發和維護。后來，這位成員對當時新出的 DynamoDB 產生了興趣，并學習了相關知識。
然后就發生下面這樣的事：
用 DynamoDB 替換了 MySQL。
很快發現 DynamoDB 并不能很好的支持事務特性，在當時只有一個性能極差的客戶端類庫來支持事物，由于采用客戶端方式，引入了大量的額外交互，導致性能差別達 7 倍之多。這時候，這個同學就采用了當時在 NoSQL 領域廣泛流行的最終一致技術，通過一個 Pub-Sub 消息隊列來實現最終一致（即當某對象的值發生改變后會產生一個事件，然后關注這一改變的邏輯，就會訂閱這個通知，并改變于其相關數據，從而實現不同數據的最終一致）。
接著由于 DynamoDB 無法提供 SQL 那樣方便的查詢機制，為了實現數據分析就又引入了 EMR/MapReduceJob。到此，大家可以看到實現一樣的功能，但是復雜性大大增加，維護工作也由一個人變成了一個團隊。
8
? ?
過度忙碌使你落后
對于 IT 人而言忙碌已成為了習慣，加班常掛在嘴邊。“996”工作制似乎也變成了公司高效的標志。而事實上過度的忙碌使你落后。經常遇見一些朋友，在一個公司沒日沒夜的干了幾年，沒有留一點學習時間給自己。幾年之后倒是對公司越來越“忠誠”了，但忙碌的工作同時也導致了沒有時間更新知識，使得自己已經落后了，連跳槽的能力和勇氣都失去了。
過度忙碌會導致沒有時間學習和更新自己的知識，尤其在這個高速發展的時代。我在工作經歷中發現過度繁忙通常會帶來以下問題：
缺乏學習導致工作能力沒有提升，而面對的問題卻變得日益復雜。
技術和業務上沒有更大的領先優勢，只能被動緊緊追趕。試想一下，要是你都領先同行業五年了，還會在乎通過加班來早一個月發布嗎？反過來上面這些問題會導致你更加繁忙，進而更沒有時間提高自己的技術技能，很快就形成了一個惡性循環。
練過健身的朋友都知道，光靠鍛煉是不行的，營養補充和鍛煉同樣重要。個人技術成長其實也一樣，實踐和學習是一樣重要的，當你在一個領域工作了一段時間以后，工作對你而言就主要是實踐了，隨著你對該領域的熟悉，能學習的到技術會越來越少。所以每個技術人員都要保證充足的學習時間，否則很容易成為井底之蛙，從而陷入前面提到的惡性循環。
最后，以偉大詩人屈原的詩句和大家共勉：“路漫漫其修遠兮，吾將上下而求索“。希望我們大家都可以不忘初心，保持匠心！
-- 精彩推薦--
架構師成長之路系列
架構師，是否需要寫代碼？ 再認真看看蔡超老師的回答吧 - 永遠不要停止編碼
奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考 2020-09-19
Netstars CTO陳斌：架構師的成長之路
阿里6年，我的技術蛻變之路！
一個思維習慣，讓你成為架構師
收藏! 架構師需要掌握的99條鐵律
史海峰：萬字長文剖析技術人如何成長
30條架構原則：助你成為大牛架構師
牛逼的架構師是怎么煉成的？
架構大咖言傳身教：從程序員到架構師
技術大牛養成指南：吃的草夠多，你也能成為大牛（附思維導圖）
美團高級專家劉丁：工程師如何在工作中提升自己?
總結
以上是生活随笔為你收集整理的Mobvista首席架构师蔡超：工作感悟之失败与成功，我的8点总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： hdu-2209 翻纸牌游戏
- 下一篇： HDU 3001 Travelling