如何提升團隊的研發效率？阿里工程師這么做
背景
大約在5年前，也就是2013年我剛加入阿里的時候，那個時候 DevOps 的風剛吹起來沒多久，有家公司宣稱能夠一天發布幾十上百次，這意味著相比傳統軟件公司幾周一次的發布來說，他們響應商業需求的能力可以甩后者幾條街，而且這差距根本不是加班能趕上的。今天的 AliExpress 技術團隊小幾百人的規模，可一天發布幾十次也已經司空見慣了，這主要得益于三個方面：
- 非常徹底地微服務化，拆分粒度很細，且旗幟鮮明地反對重二方庫。
- 阿里集團整體的運維標準化，尤其是 Docker 技術的全面覆蓋。
- AliExpress SRE 團隊不斷努力保證穩定性。
然而，效能這個東西，你永遠不會說：“夠了，夠快了”，尤其是在當下的消費型社會，人人都是消費者，而消費者恨不得腦子里的欲望剛閃現出來，你的商品或服務瞬間就到他面前。況且，隨著我們不斷國際化的步伐，新的因素必然會影響原來的高效能。
溝通帶寬衰減問題
***個因素是研發團隊自身的發展和變化，今天的 AliExpress 技術團隊已經是一個名副其實的分布式國際化團隊，工作地是杭州+深圳+莫斯科+馬德里+其他歐亞都市，外籍同學的比例是 15%，而且能看到這個比例會不斷提高，新的國外工作地點也會增加。而這樣的團隊，對比在同一層樓里的一群中國人組成的團隊，是有本質的區別的。
我們可以將人與人之間的溝通和網絡通信做類比，我們知道網絡通信是有帶寬的，從早期的撥號上網幾十K，到現在的家庭寬帶主流的幾十上百M，再到數據中心內部局域網內部G級別的數量級，帶寬越大，能傳輸的信息也就越多(通常浪費也就越多)。而人與人之間溝通也可以認為是有帶寬的，例如充分信任的全由中國工程師組成小團隊，平時相互一起吃飯散步聊天，大家彼此都特別了解，溝通起來就特別順暢，想到一個點子轉個朝向說兩句對方就懂了。可對于一個分布式國際化團隊來說，這個溝通帶寬可是衰減得厲害：
- 中文到英文的轉換，衰減一次。對于大多數人來說，英語不是母語，溝通的效率自然會降低。
- 單地到多地，衰減一次。電話，視頻，釘釘，都沒有面對面溝通來的高效。(否則大家都不會不約而同地刷臉了)
- 時差，再衰減一次。杭州和莫斯科的時差是5個小時，所以基本上北京時間上午我們是聯系不上莫斯科的同學的。
- 文化的差異，再衰減一次。例如很多我們可以用來增強感情的團建方法，擼串K歌王者吃雞，外籍同學可能完全不感冒。
那有人可能會說，既然溝通成本這么高，那直接在一個地方全部招中國工程師多簡單?這么做簡單是簡單的了，可都這么搞的話，怎么在全球范圍吸引優秀的人才呢?更何況 AliExpress 的用戶基本都是老外，這后面的人才如果全是中國人，聽起來這生意就不太靠譜對不?谷歌微軟亞馬遜，哪家不是在全世界搜羅***人才?
所以說，既然溝通帶寬的衰減是難以避免的，那我們唯有把對這帶寬的利用率提上去。具體我們已經做了，或者在做一些事情：
- 盡可能和行業主流技術接軌，降低工程師學習成本。我們基于開源 Spring Boot 做的阿里巴巴生態集成，摒棄 antx, webx, pandora，都是這個思路。
- English First：注釋，文檔，工具，英文必選，中文可選。
- 服務發現，讓所有微服務可見，增強自描述，可搜索。
擁抱 Kotlin
關于開發效率，我個人認為所有 Java 程序員都應該認認真真、仔仔細細去看下 Kotlin，因為這門語言太簡潔了，而且和 Java 可以無縫互操作，完全具備生產環境使用的條件。
有關簡潔，我這兩天把一塊 Java 代碼改成了 Koltin，在絲毫不降低可讀性的情況下(實際上可讀性是提高了)，代碼行妥妥地減少了 1/3 。
此外我忍不住分享一下最近我基于 Sergey 的 Kotlin HSF DSL 寫的一個將函數發布成 HSF 服務的功能：
只需要不到 15 行代碼，就可以啟動一個 Spring Boot 應用，把一個字符串小寫的功能發布成 HSF 服務，大家可以對比下 Java 需要寫多少東西。語言層面的升級，給框架，中間件，API設計帶來更多的可能性，這就能使我們砍掉更多的所謂腳手架代碼，讓業務代碼更精簡，更優雅，進而帶來效率提升。
作為程序員，如果只掌握一種語言，是非常危險的，因為這種語言的各種設計會禁錮你的思維。我自己會在業余看一些其他語言，不過在日常工作中基本也只能寫 Java(如果 shell 也算一種語言的話，還是寫過些 shell 的)。不過從現在開始，我會開始盡可能地用 Kotlin 寫代碼，我的團隊也全面把日常編程語言從 Java 切換到 Kotlin，其實我們都已經不算 Early Adoptor 啦，雷卷在一年多前就已經不停在鼓吹 Koltin 并上線了一個應用，AliExpress 俄羅斯辦公室的 Sergey 等同學也已經在生產用上了 Kotlin，Sergey 個人也在很多地方分享他的經驗。
我們會推動 AliExpress 擁抱 Koltin，從語言層面來提升我們的效率。
阿里資深技術專家雷卷，在他最近的一篇談程序員學習的文章中寫了很多東西，我都是很認同的，其中一段話尤其想點贊：
不要和程序員談自己的編程歷史，很多經驗今天已經不適用啦，可能有一些，但是會給別人帶來甄別成本，別人也懶得來甄別。2-3年不關注技術，基本快和程序員和編程絕緣啦，不是絕對，但是通常不會錯。
FaaS
Function as a Service，又一個新的 Buzz Word?是的，不過我還真的相信這個 Buzz Word，行業里 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 等服務相繼推出，大家都在嘗試把自己的業務往上面搬，這其中的道理在哪?
如果作為云服務提供商，這個道理是很顯而易見。你的對手按照 docker instance 收費，2 core 4g 起，一小時多少錢;如果你能做到按調用次數收費，一小時內運行了 30 次。那這個價格差必然是數量級的，用這一招就可以秒殺對手了。
上面所說的純粹是硬件成本的考量，但我們還需要從效率方面看這個事情。
首先由于 Function 天生是無狀態的，而且是足夠輕量的，那么理論上做到 ms 級別的 auto scaling 是沒有問題的，例如 graalvm 就在這方面很有潛力。
ms 級別的 auto scaling 不僅能夠大幅提升資源利用率，更是提升了運維效率，開發幾乎就不再需要考慮容量的事情的。例如在雙11的時候，我們做大量的壓測，很大程度上是為了保證系統各個部分的水位在預測的安全的線上，如果做到了實時擴縮，那么當流量高峰來的時候再擴容好了。
什么是輕量?
今天很多工程師可能已經忘了輕量的概念是什么，大家就是各種侵入，寫個簡單的應用，打出來的 jar 包，業務代碼的占比往往不到 1/10。
先不說這里可能無謂浪費了多少內存，無謂增加了多少啟動時間。這個 client 那個 share 滿天飛帶來的最麻煩的后果就是，開發經常要做各種升級，而且一升就掛，一查就半天。打著所謂性能旗號的各種重客戶端，就是反服務化的;各種缺乏細心設計的 API 導致的不兼容升級(而且是暴力推動，不升級卡發布)，就是反工程師操守的。
微服務化做得好的，應該積累一大批輕量的接口，使用這些接口甚至都不需要引入什么 share/open/client 的依賴，直接用 HSF 的泛化調用即可，這樣的接口才不對用戶有代碼侵入。
我們已經在 AliExpress 嘗試(并已經上線)基于 Koltin DSL 和 HSF 泛化調用編寫 Function，用戶只需要依賴很簡單的一個 FaaS SDK 就可以編寫業務代碼，基于前面提到的阿基米德服務發現，他可以快速重用現有服務，做一些聚合和過濾的操作，滿足業務需求，這個在貼近無線的業務中非常有用。當然，這個嘗試只是一個開始，但我們已經看到，其實有大量的業務邏輯(在 AliExpress 可能是 5/1 至 1/3)其實自身不依賴于數據，可以做成 Function，而且我們可以做到讓這些業務不依賴任何業務二方庫，甚至借助 Service Mesh 等技術，不依賴于任何中間件 client。這些業務的 owner 不需要關心各種亂七八糟的升級問題，不需要關心容量問題，真正地只關心自己的業務邏輯。
我認為這是 FaaS 該成為的樣子，而我及我的團隊，正不斷努力去實現之。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
