如何找到適合自己的研發模式？

研發效能領域洞察系列

站在螞蟻金服的視角，自主研發的中介軟體、資料庫、研發平臺等金融科技引領著企業數字化的技術趨勢。其中，以螞蟻研發效能為代表，催生了很多賦能行業的方法論和工程實踐，特別整合推出 研發效能領域洞察 系列文章。今天的內容將圍繞“研發模式”展開探討，引入了業界很多典型的案例，讓我們一起從不同的方向挖掘匹配自身需要的研發模式。

01

What：什麼是研發模式？

所謂“模式”，其實就是一套被反覆使用、多數人知曉的經驗總結 ， 它介於理論和實踐之間，由紛繁複雜的實踐抽象、提煉而成。

比如組織模式，就是對組織效率的總結。如果你要組織 2 個人，自然會用到“羽毛球雙打模式”，不需要明確的分工，用信任就可以粘合；如果你要組織 11 個人，就要參考“足球隊模式”，做一些 442、451 的陣型和分工。

再比如軟體設計模型，就是對軟體系統反覆出現的問題的解決方案的總結。如果你希望底層模組不感知上層，而上層模組可以在底層變化時收到通知，自然會用到觀察者模式（Observer）；如果你的系統希望和其他系統對接，雙方又都不希望變更協議，那麼自然會用到代理模式（Proxy）。

軟體開發領域也一樣，針對研發過程中的各類相似問題，總是能提煉出一些共性的解決方案，這就是研發模式。

當然，你可能會想到業內的很多詞，比如敏捷、Scrum、SAFe、持續交付、DevOps 等等，它們確實提供了很多理念、方法、實踐，但是它們不代表研發模式。根據我們自己的觀察，很多大型 IT 公司都有一套 適合自己的研發模式體系 ，它的本質其實就是一組被命名好的解決方案合集，一般都是參考業界一些理念並結合自身實踐總結而成， 適合自己的才是最好的。

02

How：怎麼找到研發模式？

一般來說，想找到適合你自己的研發模型，需要結合自身的業務特點、軟體架構以及組織能力來分析。這個推導過程其實隱含了 3 個基礎假設或者說基礎前提，結合案例總結如下：

1. 業務特點決定軟體架構

這個觀點其實不用細講，因為在軟體行業裡它已經被普遍認可。業務特點的分析，首先要看業務型別，簡單可分為嵌入式、APP客戶端、IT產品、雲產品、雲服務，然後再看當前業務的發展階段，比如初創期、上升期、成熟期、轉型期。這兩個一疊加，通常就變得複雜了，會有很多中間狀態，比如老產品迭代升級、新產品構建、嵌入式產品轉雲化、雲產品轉雲服務等等。只要業務在變，對軟體交付形態、響應速度的要求就會變，那架構就必然會跟著變，這裡面除了要看清業務訴求以外，更重要的是透過現象看業務本質。

案例  CASE

2015 - 2016 年，軟體行業裡“雲”這個概念開始流行起來，很多產品都說要跟得上趨勢，要把自己“雲化”。有一家公司的一個網路安全團隊，原來做的是嵌入式系統的，系統最終整合在硬體上賣給企業。這個團隊的 Leader 有這樣的需求：新一代架構準備做成基於微服務的雲化軟體，需要一套類似 DevOps 的解決方案。在分析過程中發現，他其實做的只是一款具有動態擴容能力的分散式軟體，部署在多個伺服器上，最後還是連著伺服器一起賣給企業，交付週期仍然是半年，也不需要自己的研發團隊來運維。歸根結底，業務特點沒有變化，和原來賣產品沒有本質的區別，他真正需要先思考的是業務發展的方向和可能面臨的問題，而非架構的演進。

2.軟體架構決定研發模式 

我們平常看一個人要從多角度看，比如物理上看身高、長相、體態；功能上看做人、做事；性格上看內向、外向。看一個軟體系統也是一樣，評估它的優劣也要從多角度看，通常我們喜歡用“架構檢視”這個工具。 

1995 年，Philippe Kruchten 在《IEEE Software》上發表了題為《The 4+1 View Model of Architecture》的論文，引起了業界的極大關注，並最終被 RUP 採納。 四個主要的檢視分別是： 

• 邏輯檢視（LogicalView），描述了系統的功能需求，從為使用者提供服務的角度考慮系統功能。 

• 過程檢視（ProcessView） ，又稱“程序檢視”或“處理檢視”，描述系統的執行狀態和特點，從執行角度考慮一些非功能性的需求，如效能、可靠性、可用性等等。 

• 物理檢視（PhysicalView） ，描述系統的硬體配置，把軟體對映到硬體上，從物理角度解決系統的拓撲結構、系統安裝、通訊等問題。 

• 開發檢視（DevelopmentView） ，描述了在開發環境中軟體的靜態組織結構，從軟體開發角度，看系統如何被更快構建出來、程式碼如何組織、開發人員如何開發和分工。 

每個檢視設計的完備性會直接影響到對應的軟體質量屬性，具體對應關係見下圖：

根據歷史經驗，這些檢視中最容易被架構師們忽略往往是 “開發檢視” ，因為這似乎並不影響系統的功能、效能、執行狀態、部署成本。而 開發檢視是否被詳細設計、有沒有良好落地，直接影響著軟體研發效率。

案例  CASE

2008 年，一家公司的首席架構師設計了一款某產品的新一代 OS 系統。這個系統是全面元件化的，元件間採用訊息通訊，具有多程序部署、擴容能力，同時在底層提供了模擬資料庫機制，可以對複雜的業務邏輯實現進行建模，並存儲在XML中。回頭看來，這在當時是一個十分領先的架構設計，裡面用的所有的理念全部前沿且正確。但是後來 8 年間，問題逐步浮出水面，雖然這個系統的功能、效能表現良好，可在 16 個版本的演進過程中，像是會吃人一樣消耗掉了大量的研發人力，投入和產品不成正比。使用這個系統的產品也頻繁反饋，說這個團隊雖然有 1000 多人，但是功能上線慢、新需求無法承接、問題定位效率也低。公司組織了專家團隊診斷後才發現，幾個關鍵問題恰恰都出在開發檢視上，首先，模型缺少視覺化的 IDE，積累的幾百萬行 XML 難以分解和維護，不僅消耗人力，也導致了版本構建時間越來越長；其次，缺少元件間的有效測試工具，開發人員只能用模擬器做黑盒測試；另外還缺少定位問題的鏈路診斷工具，每次只能手動獲取和分析日誌；最後還有一點最關鍵的是學習成本非常高，一個開發想完成一個使用者可見的功能，至少需要懂 Liunx 系統、掌握 2 種程式語言，學會 3 種資料建模方式，理解 15 種系統獨特機制，普遍的學習週期都在 3-6 個月。針對這些一系列類似問題，公司花費了 2 年多的時間做專項治理。

綜上所述，所謂的“研發模式”設計，其實就是開發檢視的細化設計，因為常常不被重視，所以總是能找到很多 GAP。

3.研發模式決定研發組織、流程&方法、工程&工具

理解了研發模式，交付各環節的效能目標就很容易明確，那麼圍繞著目標，再結合現狀，就能得出解決方案。我們制定解決方案通常有三個維度：

• 交付模式： 軟體生產過程抽象的看就是需求的流轉過程，設計人員把需求從概念翻譯成文件，工程師把文件翻譯成程式碼最終生成軟體包，運維人員再把軟體包部署在環境上變為可執行的程序，執行起來的程序為客戶提供功能。交付模式需要設計的是首先是每個環節的輸入是什麼、輸出是什麼以及如何有效驗證。其次要結合架構看交付的粒度如何拆分，讓每個交付件之間鬆耦合，儘可能做到獨立交付。最後，還要結合具體場景來設計，比如新老需求並行開發怎麼辦，線上多版本維度怎麼辦等等。

• 組織模式： 開發團隊圍繞著交付模式如何分工、協作最有效率。

• 流程&方法、工程&工具： “君子性非異也，善假於物”，交付模式和組織模式明確之後，就需要看有哪些方法或工具可以支撐這個模式高效運轉。結合你的組織和技術能力，通過可以在流程&方法、工程&工具中找到解決方案。

這些維度是有明顯排序的。根據經驗來看，架構解耦度低，交付模式設計得再好也很難解決問題；交付模式或組織模式設計的有問題，流程&方法、工程&工具對整體效率的影響微乎其微，相對的，管理成本會很高；最後，在理論上，流程&方法的最佳實踐是經驗和方法流程化、流程工具化，但結合實際來看，從來沒有完美的系統，工具的不足要靠流程補，流程的不足要靠人來補。 

3.合成謬誤，適用個體的不一定適用全體

“合成謬誤（fallacy of composition）”是一個經濟學概念，由薩繆爾森提出，它指的是對區域性說來是對的東西，不能說明它對總體而言也必然是對的。最簡單的例子，在一個劇場裡面，有人看不清楚舞臺上面的表演，站起來他就能夠看得清楚。一個人站起來他能夠看得更清楚，兩個人站起來兩個人能夠看得更清楚，所有的人都站起來，沒有人能夠看得更清楚。在系統工程領域這個現象也很常見，有的方案雖然看上去完美、邏輯自洽，可以解決 1、2 個人的問題，但是若想同時解決一百個人的問題，可能就需要完全不同的另一套方案。

案例  CASE

主幹模式的釋出就是一個典型的例子，每個人都期望小布快跑，少一點防護、早一點合入，萬一出了問題再快速回退就行了，這種思想很美好，而且實際上，10-20 個人的團隊裡可以玩的很高效。但是我原來參與過一個 2000 人一條主幹開發的系統，在這個系統裡，一次問題的引入，就會有幾百人被迫等待，那麼這種情況下就應該綜合考慮更完備的解決方案，而非單純的套用所謂的“業內最佳模式”。

講到這裡，你可能會很好奇，螞蟻的研發模式是什麼樣的呢？它是怎麼被系統設計出來的呢？由於篇幅有限，下面做一個極簡的介紹。

1.業務特點：“快”和“穩”的平衡

螞蟻的業務兼備金融行業和網際網路行業屬性。金融的核心訴求是“穩”，因為一旦出現資金問題就會失去使用者信任，所以每次的釋出必須是高質量。而網際網路的核心訴求又是“快”，1個新特性可能需要1周甚至更早要上線，1個嚴重問題甚至要在幾小時內完成修改、釋出。按照常識來判斷，我們知道，“快”和“穩”這兩個指標的同時達到最大化幾乎是不可能的，就像開車一樣，你想快，猛踩油門，風險就會提升。因此，要解決這個問題就需要系統性的設計，尤其是在軟體架構和研發模式上。

2.軟體架構：“小、獨、輕、鬆”

平衡 “快”和“穩”的關鍵首先是軟體架構，想象一下，一輛裝了60個人的公交車想加速，只能猛踩油門，車上的人都要承擔更大的風險，而如果是60輛小汽車，那麼狀況則完全不同。螞蟻的架構體系就是這樣一套 分散式架構解決方案，包含了 微服務、限流/熔斷、分散式鏈路追蹤、分散式高可用訊息佇列、分散式資料庫等諸多技術。從開發檢視的角度看，它的每一次交付都具有 “小、獨、輕、鬆” 的特點，即：

• 小： 每次釋出的交付件足夠小

• 獨： 可獨立開發、測試、釋出

• 輕： 能輕量級部署、升級

• 鬆： 和其他業務鬆耦合

有了這樣的架構保障，螞蟻的業務在風險最低的前提下，就有了獨立開發、快速上線的基礎。

3.研發模式：Cloud Native下的研發模式

螞蟻金服的研發模式如果套用一個業界比較火的概念，可以說，我們是“Cloud Native”下的研發模式。“Cloud Native”，是 Matt Stine 提出的一個概念，它其實是一個思想的集合，包括 DevOps、持續交付、微服務、敏捷基礎設施、康威定律等等。有趣的是，螞蟻並不是看到了這個概念才去實踐的，而是在上述的業務特點和訴求下，運用了相應的技術，匹配了適合的研發模式，自然而然演進而成，這可能也正是“Native”這個詞的精妙之處，具有“原生”、“天生”這樣的含義。

長按識別二維碼關注我們

P.S.

螞蟻金服研發效能團隊招募進行中， 解決方案架構師、技術運營、資料研發專家、技術專家、技術支援專家、 產品專家、測試平臺高階開發工程師、程式碼分析技術專家 等眾多崗位持續開放，讓我們共同開赴DevMind/ DevOps /DevServices三大戰場，助力內部及外部夥伴研發效能的持續提升:rocket::rocket::rocket:

如果你對任何崗位感興趣，請留下聯絡方式，或者發簡歷到： [email protected]

▼  點選“閱讀原文”獲取更多職位詳情