雲開發模式下的研發職能洗牌和工程模型

本文是對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時代