如何提升團隊的研發效率？阿里工程師這麼做
阿里妹導讀：隨著業務走向國際化、意想不到的挑戰接踵而來——團隊迎來一位位金髮碧眼工程師，業務支援與優雅程式碼相互摩擦，溝通協作、研發模式、文化氛圍，如何適應這些新的變化？今天，我們邀請Aliexpress高階技術專家許曉斌，分享他的解決之道。
背景
大約在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 該成為的樣子，而我及我的團隊，正不斷努力去實現之。
寫在最後：歡迎各位加入阿里國際技術團隊，感興趣的同學可通過郵件：[email protected]聯絡我們。
每天一篇技術文章，
看不過癮？
關注“阿里巴巴機器智慧”，
發現更多AI乾貨。
↑ 翹首以盼等你關注
你可能還喜歡
點選下方圖片即可閱讀
關注「阿里技術」
把握前沿技術脈搏