如何找到適合自己的研發模式?
研發效能領域洞察系列
站在螞蟻金服的視角,自主研發的中介軟體、資料庫、研發平臺等金融科技引領著企業數字化的技術趨勢。其中,以螞蟻研發效能為代表,催生了很多賦能行業的方法論和工程實踐,特別整合推出 研發效能領域洞察 系列文章。今天的內容將圍繞“研發模式”展開探討,引入了業界很多典型的案例,讓我們一起從不同的方向挖掘匹配自身需要的研發模式。
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.研發模式決定研發組織、流程&方法、工程&工具
理解了研發模式,交付各環節的效能目標就很容易明確,那麼圍繞著目標,再結合現狀,就能得出解決方案。我們制定解決方案通常有三個維度:
-
交付模式: 軟體生產過程抽象的看就是需求的流轉過程,設計人員把需求從概念翻譯成文件,工程師把文件翻譯成程式碼最終生成軟體包,運維人員再把軟體包部署在環境上變為可執行的程序,執行起來的程序為客戶提供功能。交付模式需要設計的是首先是每個環節的輸入是什麼、輸出是什麼以及如何有效驗證。其次要結合架構看交付的粒度如何拆分,讓每個交付件之間鬆耦合,儘可能做到獨立交付。最後,還要結合具體場景來設計,比如新老需求並行開發怎麼辦,線上多版本維度怎麼辦等等。
-
組織模式: 開發團隊圍繞著交付模式如何分工、協作最有效率。
-
流程&方法、工程&工具: “君子性非異也,善假於物”,交付模式和組織模式明確之後,就需要看有哪些方法或工具可以支撐這個模式高效運轉。結合你的組織和技術能力,通過可以在流程&方法、工程&工具中找到解決方案。
這些維度是有明顯排序的。根據經驗來看,架構解耦度低,交付模式設計得再好也很難解決問題;交付模式或組織模式設計的有問題,流程&方法、工程&工具對整體效率的影響微乎其微,相對的,管理成本會很高;最後,在理論上,流程&方法的最佳實踐是經驗和方法流程化、流程工具化,但結合實際來看,從來沒有完美的系統,工具的不足要靠流程補,流程的不足要靠人來補。
03
Why:為什麼要先看研發模式
看到這裡你可能會有一些疑惑,為什麼不直接發現問題、解決問題,而是要先做這麼大量的分析呢?其實這也是有原因的,通常,做效能解決方案的人是某個細分領域的專家,比如架構、設計、編碼、測試、項管、團隊管理等等,而軟體研發過程本身是一項系統工程,它的問題繁瑣、複雜,問題的癥結常常不在你所熟知的領域中,如果不能站在一定的高度系統思考,就很容易陷入死衚衕。下面結合身邊的案例看看常見的三個現象:
1.專業偏見,用擅長的領域解決一切
美國作家馬克·吐溫有句名言:“如果你身上唯一的工具是一把錘子,那麼你會把所有的問題都看成釘子”。著名投資家查理·芒格將這種現象稱之為“拿錘子的人”。 人們經過年復一年的專業培訓,一旦瞭解並熟悉了某一專業領域的思維模式之後,他們就會到處嘗試將所有遇到的問題,都用自己的專業思維模式解決。
案例 CASE
一個 Android 手機作業系統團隊,啟動了一個開發效率提升的專案,在問卷調查階段,開發人員普遍反饋了了“構建慢”的問題,這個問題的調研和跟進很自然安排給了一個擅長編譯的工程專家。他立刻開始開啟編譯工程和配置,很快就發現了好幾個問題,包括全量構建、多次打包等等,於是他用了 1 個月,把 30 分鐘優化到了 15 分鐘。奇怪的是功能上線後,開發人員並沒有什麼感知。後來調研才發現,反饋這個問題的同學基本都是核心態的底層軟體開發,他們所謂的“構建”,指的是程式碼從提交、編譯、出包、再傳到手機上。這裡面的痛點其實是把包傳到手機上,由於公司網路安全的原因,要跨越 3 朵雲,期間涉及 3 次工具操作,需要他時不時的跟進傳輸情況,累計要等 45 分鐘。編譯的 30 分鐘,對他來說可以去做編碼、做 Review,相比之下這 45 分鐘的跟進才是最大的效率損失。
2.過度擬合,深入細節不見大方向
統計學中有一個現象叫“過度擬合”(over-fitting),這個概念也經常在機器學習領域用到,它指的是建立的學習模型在訓練樣本中表現得過於優越,導致驗證資料集以及測試資料集中表現不佳。 簡單說,就是死摳細節、追求完美,反而偏離了現實,忽略了更重要的問題。
案例 CASE
一個規模很大的 APP 團隊做自動化測試,負責人基於自己在其他產品的成功經驗,希望把自動化率提升到 85% 以上。APP 的服務端相對比較容易,需求變化慢、有標準化介面、有明確的質量標準,因此群策群力很快就完成了提升。相對的,APP 的客戶端就困難很多,比開關機等各種異常場景、手機螢幕的差異、使用者體驗沒標準,這個負責人用了很多技術手段來提升自動化率,比如引入介面測試工具、購買機械手等等,最後積累了幾萬個基於使用者場景的用例。但是很快發現這些用例的維護成本太高,手機和 Pad 的螢幕尺寸在變、系統風格在變、使用者的體驗也在變,最終,每日能跑的也只有幾百條基礎用例。實際上,探索過來發現,其實還有另外一條路,就是隻用自動化保證基本的功能和效能,其他的都讓使用者來測,高手在民間,通過吸引和培養幾千甚至幾萬粉絲,頻繁的開展眾測來平衡成本和質量。
3.合成謬誤,適用個體的不一定適用全體
“合成謬誤(fallacy of composition)”是一個經濟學概念,由薩繆爾森提出,它指的是對區域性說來是對的東西,不能說明它對總體而言也必然是對的。最簡單的例子,在一個劇場裡面,有人看不清楚舞臺上面的表演,站起來他就能夠看得清楚。一個人站起來他能夠看得更清楚,兩個人站起來兩個人能夠看得更清楚,所有的人都站起來,沒有人能夠看得更清楚。在系統工程領域這個現象也很常見,有的方案雖然看上去完美、邏輯自洽,可以解決 1、2 個人的問題,但是若想同時解決一百個人的問題,可能就需要完全不同的另一套方案。
案例 CASE
主幹模式的釋出就是一個典型的例子,每個人都期望小布快跑,少一點防護、早一點合入,萬一出了問題再快速回退就行了,這種思想很美好,而且實際上,10-20 個人的團隊裡可以玩的很高效。但是我原來參與過一個 2000 人一條主幹開發的系統,在這個系統裡,一次問題的引入,就會有幾百人被迫等待,那麼這種情況下就應該綜合考慮更完備的解決方案,而非單純的套用所謂的“業內最佳模式”。
04
螞蟻金服的研發模式
講到這裡,你可能會很好奇,螞蟻的研發模式是什麼樣的呢?它是怎麼被系統設計出來的呢?由於篇幅有限,下面做一個極簡的介紹。
1.業務特點:“快”和“穩”的平衡
螞蟻的業務兼備金融行業和網際網路行業屬性。金融的核心訴求是“穩”,因為一旦出現資金問題就會失去使用者信任,所以每次的釋出必須是高質量。而網際網路的核心訴求又是“快”,1個新特性可能需要1周甚至更早要上線,1個嚴重問題甚至要在幾小時內完成修改、釋出。按照常識來判斷,我們知道,“快”和“穩”這兩個指標的同時達到最大化幾乎是不可能的,就像開車一樣,你想快,猛踩油門,風險就會提升。因此,要解決這個問題就需要系統性的設計,尤其是在軟體架構和研發模式上。
2.軟體架構:“小、獨、輕、鬆”
平衡 “快”和“穩”的關鍵首先是軟體架構,想象一下,一輛裝了60個人的公交車想加速,只能猛踩油門,車上的人都要承擔更大的風險,而如果是60輛小汽車,那麼狀況則完全不同。螞蟻的架構體系就是這樣一套 分散式架構解決方案,包含了 微服務、限流/熔斷、分散式鏈路追蹤、分散式高可用訊息佇列、分散式資料庫等諸多技術。從開發檢視的角度看,它的每一次交付都具有 “小、獨、輕、鬆” 的特點,即:
-
小: 每次釋出的交付件足夠小
-
獨: 可獨立開發、測試、釋出
-
輕: 能輕量級部署、升級
-
鬆: 和其他業務鬆耦合
有了這樣的架構保障,螞蟻的業務在風險最低的前提下,就有了獨立開發、快速上線的基礎。
3.研發模式:Cloud Native下的研發模式
螞蟻金服的研發模式如果套用一個業界比較火的概念,可以說,我們是“Cloud Native”下的研發模式。“Cloud Native”,是 Matt Stine 提出的一個概念,它其實是一個思想的集合,包括 DevOps、持續交付、微服務、敏捷基礎設施、康威定律等等。有趣的是,螞蟻並不是看到了這個概念才去實踐的,而是在上述的業務特點和訴求下,運用了相應的技術,匹配了適合的研發模式,自然而然演進而成,這可能也正是“Native”這個詞的精妙之處,具有“原生”、“天生”這樣的含義。
05
結語
“研發模式”作為軟體開發中的重要一環,隨著技術和實踐的豐富也日漸趨同,但匹配自身場景、找到適合自己的研發模式才能實現真正的落地。螞蟻金服在日趨成熟的研發模式之上,也探索了很多優秀實踐,比如單元化部署、AntWorkFlow、研發容器、 智慧 IDE、 DevMind 等等,後續有機會再和大家一一交流、分享。
如果還想要了解更多,這裡有更多研發效能內容推薦:
從程式碼層面開始,對 Code Review 這個基礎而重要的環節進行剖析:
長按識別二維碼關注我們
P.S.
螞蟻金服研發效能團隊招募進行中, 解決方案架構師、技術運營、資料研發專家、技術專家、技術支援專家、 產品專家、測試平臺高階開發工程師、程式碼分析技術專家 等眾多崗位持續開放,讓我們共同開赴DevMind/ DevOps /DevServices三大戰場,助力內部及外部夥伴研發效能的持續提升:rocket::rocket::rocket:
如果你對任何崗位感興趣,請留下聯絡方式,或者發簡歷到: [email protected]
▼ 點選“閱讀原文”獲取更多職位詳情