雲開發模式下的研發職能洗牌和工程模型
本文是對11月7日騰訊Techo技術大會上本人分享的議題《雲開發模式下的工程模型和落地實踐》的講稿整理。
軟體開發經歷幾十年的發展到今天，開發者的關注點其實只有兩個：系統架構和軟體架構。下圖中列出的內容有的屬於系統架構層面，比如異地容災、網路專線、網路防護等等；有些屬於軟體架構層面，比如資料庫、高併發、檔案儲存等等。
不論是系統架構還是軟體架構，目的都是保證業務邏輯的正確性和高效性。換句話說，都是圍繞業務邏輯展開。
以這兩個關注點為基礎，逐漸演化出了現今普遍的技術研發團隊的職能分配結構。比如以系統架構為基礎演化出運維工程師，又可細分為面向軟體的運維和麵向硬體的運維；以軟體架構為基礎演化出資料庫工程師、服務端工程師以及前端工程師。
各職能有不同的分工，要求從業者具備其所屬職能的專有領域知識，進而造成各職能之間存在明顯的隔離邊界。而邊界的存在必然會對多職能的協作和交流產生不良影響。
極限程式設計是Kent Beck在1996年提出的一種軟體工程方法，後又演化出三種耳熟能詳的具體落地方案：封閉開發、敏捷開發和結對程式設計。前兩者跟本文的話題關聯不大，所以略過。下圖展示的便是經典的前後端結對開發的場景：
雖然結對程式設計縮短了空間距離令溝通更便捷，但是空間並非是影響溝通的唯一甚至主要因素。由於前後端之間存在明顯的職能邊界，所以現實中的結對程式設計絕大多數達不到理想中的結果。而空間距離的縮短不僅沒有促成高效溝通，反而弄巧成拙為兩人的吵架提供了便利。
而這個問題在雲開發模式下被極大地弱化甚至完全消除。為何會如此，我們先從雲端計算的歷史講起。
從系統到軟體，雲端計算的演進之路
從物理機到雲主機再到PaaS，雲端計算一步步降低了開發者對於系統架構的關注，減少運維投入和經濟成本。Serverless則更進一步，弱化開發者對軟體架構的感知和關注。
那麼FaaS+BaaS的Serverless模型還缺什麼？雲開發如何彌補Serverless的不足？
舉個例子，下圖是使用雲開發提供的雲端儲存能力進行靜態檔案的上傳和下載操作：
與傳統CDN不同的是，雲端儲存上傳檔案後得到的是一個fileID而不是URL，然後在下載的時候首先要用fileID換取URL，在這個過程中會進行必要的許可權驗證，非法使用者不能夠獲得資源的URL。
從以上對比中可以提取出雲端儲存相對於傳統CDN的兩個提升點：一是更安全便捷的許可權控制；二是更語義化的程式語言API。
這也是雲開發在Serverless基礎上解決對端“最後一公里”問題的兩個核心出發點。
關於雲開發對於Serverless的加強請參閱延伸閱讀《雲開發如何解決serverless對端的最後一公里問題》。
雲開發推動研發職能結構的洗牌
自BFF誕生以來一直存在著“BFF層誰來做”的爭議。BFF層本質上是server，要求開發者有服務端開發的領域知識和能力。所以交給傳統的前端工程師來做必然會有一定的學習成本以及服務穩定性方面的隱患，即使直接招聘有此能力的前端也會消耗相對傳統前端更多的僱傭成本。
那麼BFF交給後端開發者不就行了嗎？如此，那跟傳統的研發職能分配有何不同呢？前端仍然寫互動、後端仍然寫邏輯，協作流程上沒有任何改動，意義何在？效率何在？
如此難以抉擇的根本是因為前端工程師不會寫業務邏輯？還是因為前端不熟悉服務端的程式語言？
當然不是。
程式語言是各職能之間最表層也是最容易跨過得一道門檻，業務邏輯則更不是問題。傳統前端之所以寫不好server，本質上是因為缺乏服務端開發的專有領域知識，而這些領域知識是跟程式語言和業務邏輯無關。
所以，雲開發模式下由雲函式承載業務邏輯充當BFF層的代替者，對於開發者的唯二要求便是熟悉程式語言和編寫業務邏輯的能力，而與兩者無關的其他領域知識一概消除。
則必然，前後端分離的邊界下沉到BFF之下，進而傳統的前後端職能分配結構被重新洗牌。
而洗牌之後的工程模型也更新換代。
研發職能的單一化必然帶動迭代效率的提升，從另一方面，前後端由單一職能負責也提供了玩更多花樣的環境，比如同構程式設計。
總結
雖然目前普遍認為Serverless=FaaS+BaaS，但Serverless是一種理念，一種指導思想，並不會侷限於固定的模型。雲開發在Serverless理念的基礎之上，以端SDK+接入層的模式彌補了Serverless對端能力的不足。在此基礎之上，傳統的研發職能結構被進一步洗牌。
延伸閱讀：
- 雲開發如何解決serverless對端的最後一公里問題
- Serverless——前端的3.0時代