web 基礎(chǔ)研發(fā)體系指的是， web 研發(fā)中一線工程師所直接操作的技術(shù)、工具，以及所屬組織架構(gòu)的總和。在過去提升企業(yè)研發(fā)效能的討論中，圍繞的主題基本都是——”通過云計算、云存儲等方式將底層核心技術(shù)封裝成基礎(chǔ)設(shè)施“。而我們在實踐中發(fā)現(xiàn)，在
這樣的多重背景下，除了底層核心技術(shù)外，一線 web 研發(fā)效能的問題也逐漸成為決勝戰(zhàn)場的重要因素。
然而在現(xiàn)實中我們看到，因為一線的研發(fā)工作可替換性強，所以并沒有受到足夠的重視，同時也缺少更統(tǒng)一、更有深度的規(guī)劃和管理。實際上，將一線工程師所直接接觸到的應(yīng)用框架、測試、部署、監(jiān)控等領(lǐng)域作為一個完整的體系來思考，并打造成一體化的基礎(chǔ)設(shè)施，能為企業(yè)的業(yè)務(wù)研發(fā)帶來巨大的效能提升。
在《月相》一章中，我們將介紹Web 基礎(chǔ)研發(fā)體系有哪些構(gòu)成部分，并且將深入到關(guān)鍵性的技術(shù)和問題中?！冻毕芬徽聦⒔榻B如何配合這套研發(fā)體系，在組織結(jié)構(gòu)上做出一些調(diào)整，通過管理手段進一步挖掘團隊潛力，打造更高效的組織。
另外，希望這些內(nèi)容也能為一線工程師提供一些職業(yè)規(guī)劃上的引導(dǎo)。
我們將要討論的研發(fā)體系，涵蓋了”研發(fā)流程“和”系統(tǒng)“兩個維度?？梢杂靡粡埓髨D來描繪：
可以看到，將這些內(nèi)容作為一個整體，符合目前互聯(lián)網(wǎng)公司”核心技術(shù)“ ”web 研發(fā)能力“ 的模式，能快速產(chǎn)出應(yīng)用。其中，”用戶“、”權(quán)限“、”流程“可以說是絕大部分系統(tǒng)的鐵三角，因此我們也劃入到了基礎(chǔ)研發(fā)體系中。
接下來看每個部分。從流程的角度來說，提升效能的關(guān)鍵在于”工具化“和”自動化“，我們就以這兩點來切入。
首先是設(shè)計，設(shè)計與編碼的結(jié)合是目前業(yè)界想象空間最大，但也是最不成熟的領(lǐng)域。對于自動化的實現(xiàn)，目前的嘗試大致可以歸納成兩類：
第一類，與設(shè)計師約定規(guī)則，按規(guī)則轉(zhuǎn)化設(shè)計稿。這種方式的關(guān)鍵在于，“既要規(guī)則簡單易于被設(shè)計師接受，又要保證視覺上的關(guān)系能完整轉(zhuǎn)化成程序中的關(guān)系“。我們舉個例子來說明”視覺上的關(guān)系“和”常見的程序中的關(guān)系“: 網(wǎng)頁上這樣一個場景：
可以很容易地理解為一個 Tab 組件里面嵌著一個按鈕，他們是”嵌套關(guān)系“，在程序中用 html 可能這樣寫:
<Tabs> <Tabs.Pane title='tab1'> <Button/> </Tabs.Pane> <Tabs.Pane title='tab2' /></Tab> 但是在現(xiàn)代的設(shè)計工具中，圖層信息表示的僅僅是視覺上的前后關(guān)系。
這就出現(xiàn)了一種不匹配，設(shè)計師可以通過一萬種方式來表達同樣的視覺效果。因此，要保證正確識別關(guān)系，必須和設(shè)計師約定只能以某種方式來創(chuàng)建圖層。但問題是這種約定本身對設(shè)計師來說沒有實際意義，對他來說只是約束。除了嵌套關(guān)系以外，位置關(guān)系也是同樣的問題——目前設(shè)計工具產(chǎn)出的設(shè)計稿只是某一種具體尺寸的視覺效果，而我們實際產(chǎn)品的尺寸會因設(shè)備不同而不同的，甚至可以隨著瀏覽器窗口的縮放等功能動態(tài)變化：
怎么來表示這種變化對設(shè)計師來說也是額外的約束。樂觀的是，從技術(shù)角度來說，總歸是可實施的。
第二類嘗試，像游戲一樣做專用的設(shè)計工具，則從根本上解決了上述問題。
思路很簡單，既然設(shè)計師能有多種方式來表達，那么我們從工具角度來約束，是不是就不會有問題了？雖然同樣有約束，但是對設(shè)計師來說負擔(dān)要小多了，不需要額外記憶，按照工具的指引使用即可。我們甚至還可以提供一些高級功能防止出現(xiàn)一些人為錯誤，以此來吸引設(shè)計師。這種方式唯一的缺點是有一次性的學(xué)習(xí)成本。
雖然目前的自動化方案，都還只是從“視覺稿”到“程序靜態(tài)視圖”的自動化，并不包括交互邏輯的自動化，但已經(jīng)有了巨大的意義。在前端程序員工作的統(tǒng)計中發(fā)現(xiàn)，他們有一半以上的時間都是在”調(diào)整大小、調(diào)整位置、對像素、對色值“，而且越是好的前端，這個時間比例越大。因為寫邏輯是可以通過提升自身素質(zhì)實現(xiàn)量級縮小的，而寫樣式這個工作本身很難實現(xiàn)量級的時間縮短。
如果在研發(fā)體系中，設(shè)計稿能自動轉(zhuǎn)化成可用的代碼，無疑對傳統(tǒng)的 web 頁面研發(fā)會有巨大的提升。雖然做專用工具看起來應(yīng)該是最終的方向，但在目前的現(xiàn)實環(huán)境中，可能會因為加重設(shè)計師的使用負擔(dān)而被抵制，所以通過在原有設(shè)計工具上做約定的方式來過渡可能更合適。在用約定的方案里，怎樣讓約定即不給設(shè)計師造成太大的負擔(dān)，又能解決上述的規(guī)則轉(zhuǎn)化問題，就成了重點。在實踐中的解法是，通過工具的高級能力來補償設(shè)計師。這部分細節(jié)已在《設(shè)計稿自動生成可用頁面的展望》中詳細描述過，這里不再贅述。
我們將這三個環(huán)節(jié)合在一起來討論，是因為他們存在技術(shù)決策上的上下游關(guān)系。過去在大團隊中規(guī)劃研發(fā)體系，常常會出現(xiàn)一種現(xiàn)象，就是研發(fā)、測試、監(jiān)控都是由不同團隊規(guī)劃的，而每個團隊都想著做平臺。后來慢慢發(fā)現(xiàn)這個思路是有問題的，因為做平臺必然要考慮到不同端的接入，要花成本將自己的服務(wù)抽象得足夠底層，花成本對不同的端做適配。而在這三個環(huán)節(jié)中，研發(fā)中的運行時框架(應(yīng)用框架)是工具化和自動化的核心，只要對運行時框架多進行一點點投入，后面測試、反饋、監(jiān)控的研發(fā)成本就能降到非常低！
舉個前端的例子。在搭建可視化頁面搭建平臺時，我們設(shè)計了一個將“所有組件數(shù)據(jù)都統(tǒng)一到一棵樹”上的方案。
在傳統(tǒng)的 React 中所有組件的 state 和 props 合起來才能表達一個頁面唯一的狀態(tài)，state 和 props 分散在組件中，不易收集。而在這個設(shè)計中，全局的 state tree 即表達了頁面的一個狀態(tài)，如果將每一次變化后的state tree 都存起來，即可通過回放來展現(xiàn)頁面動態(tài)變化的過程。更進一步的是，利用這個特性，我們在 200 行代碼之內(nèi)就實現(xiàn)了“錄制即測試用例”的功能。用戶無需寫任何晦澀的用例代碼，在調(diào)試自己寫的頁面時只要覺得沒問題，就可以將剛才的調(diào)試過程保存成一個用例。
再舉一個接口層的例子。我們運行時框架的接口采用了 GraphQL ，并且告別了手動寫接口的形式，全部利用視圖勾選生成。
這解決了兩個研發(fā)中常見的問題：
這也就極大地減輕了測試環(huán)節(jié)的壓力。之前的思路基本都是通過掃描代碼去發(fā)現(xiàn)接口錯誤，要消耗大量資源，現(xiàn)在看起來沒必要了。
這兩個例子都是從研發(fā)的角度來思考所看到的收益，我們再單獨從測試與監(jiān)控的角度來看。
測試領(lǐng)域有一個熱點，—— UI 自動化。目前的 UI 自動化有兩種方案，圖片對比 與 dom 樹對比。
這兩種方案都有一個共同的缺點，即“無法正確地識別變化的類型”。例如現(xiàn)在有個需求，視圖上的兩個元素需要調(diào)換一下位置，但邏輯并沒有變，希望測試平臺不報警。除非人工干預(yù)，否則這兩種方案都很難判斷出來，因為他們是以”最后渲染結(jié)果“作為判斷依據(jù)的。但是如果我們的測試是針對運行時框架來設(shè)計的話，就很容易實現(xiàn)。以上面研發(fā)時所講的組件樹方案為例，頁面到底有沒有邏輯性的變化只和 state tree 有關(guān)，因為頁面的狀態(tài)是 state tree，而邏輯操作的也是 state tree，所以我們只要認為 state tree 沒變，就可以認為頁面沒有發(fā)生變化，不用觸發(fā)報警。
除了能識別變化外，利用運行時框架的設(shè)計，我們還能實現(xiàn)更先進的功能，例如 B/S 架構(gòu)中還原瀏覽器端出錯現(xiàn)場的問題。在過去 debug 時，我們通常都要與測試交流，按照操作步驟手工還原到現(xiàn)場，如果能由程序自動化一次性達到出錯現(xiàn)場，那無疑能給 debug 速度帶來質(zhì)的提升。要實現(xiàn)這種能力的關(guān)鍵點在于，任何表示頁面狀態(tài)的數(shù)據(jù)，都要能暴露到外部，也能由外部傳入進行重置。一旦有一個決定頁面狀態(tài)的變量在函數(shù)中，不能取出，不能序列化后傳給服務(wù)端，就無法做到。毫無疑問，這種能力也是需要應(yīng)用框架來支持的。例子中 state tree 的設(shè)計，有一部分原因就是出于支持這種能力的考慮。
再來看監(jiān)控領(lǐng)域的熱點，“無埋點”監(jiān)控，和自動化測試有異曲同工之妙?！盁o埋點”指的是無手工在代碼中的埋點，通常是使用可視化的技術(shù)來進行“標記”。
目前業(yè)界的一些方案中，遇到的問題同樣是不能正確地識別變化。例如當(dāng)頁面上的元素改變了位置，埋點能不能不受影響？在可視化搭建平臺這個項目里，我們同樣是在應(yīng)用框架這個層面設(shè)計了解決方案：
我們的頁面使用一種類似于模板的方式來嵌套組件，這個結(jié)構(gòu)我們稱為 component tree，這個結(jié)構(gòu)是靜態(tài)可分析的，所以可以很容易地實現(xiàn)可視化。用戶如果想要控制組件使其產(chǎn)生變化，那么必須給組件取個唯一的名字，在邏輯代碼中使用這個名字對它的數(shù)據(jù)進行操作來實現(xiàn)改變。
有了這個前提，無需任何額外的投入，就已經(jīng)實現(xiàn)了“無埋點”。因為“埋點”本身就是對邏輯功能的統(tǒng)計，所以埋點一定會埋在有邏輯相關(guān)的組件上，因此一定會有唯一的名字，那么無論組件怎么變化，只要沒有被刪除，我們的埋點信息就不會受到影響。同時，如果一個有埋點的組件出現(xiàn)了改名或者刪除，我們還能自動提示報警。而這些功能，同樣是在不到200行的代碼就實現(xiàn)了。
(埋點取名)
綜上，從測試和監(jiān)控兩個角度我們也可以看到，只要運行時框架提供一點點幫助，就能以極小的成本來實施。針對確定的上游研發(fā)框架來進行下游的開發(fā)，不用再考慮對各種框架的兼容問題，也可以讓下游在能力上走得更遠，實現(xiàn)更多先進的功能。
我們在線下交流中發(fā)現(xiàn)，很多團隊對框架的投入只停留在寫小工具和包裝開源框架上。因為看不清方向，不知道如何投入，也不知道投入后有多少收益，所以不敢深入。其實方向和具體應(yīng)該投入哪些技術(shù)，都是有跡可循的。這個蹤跡的源頭我們在 《理想的應(yīng)用框架》中曾提到過的，就是程序的本質(zhì)——數(shù)據(jù)和邏輯。
先具象一點來說數(shù)據(jù)?？蚣艿臄?shù)據(jù)就是框架運行時內(nèi)部保存的對象等數(shù)據(jù)結(jié)構(gòu)，只要回答好兩個問題就能展現(xiàn)出強大的威力：
知道數(shù)據(jù)在哪，是管理數(shù)據(jù)的基本條件。應(yīng)用的任何狀態(tài)，都可以看做是內(nèi)部數(shù)據(jù)的一種表現(xiàn)。因此只有框架掌握了所有數(shù)據(jù)，才有可能實現(xiàn)例如還原現(xiàn)場之類的功能。這對我們的研發(fā)有兩點指導(dǎo)意義：
一是在使用已經(jīng)有控制反轉(zhuǎn)和依賴注入的 web 框架時，應(yīng)該完全遵循框架的約定，將服務(wù)等對象的管理完全由框架。有的框架語法寫起來比較麻煩，可以通過命令行或者IDE工具來自動生成。
二是在我們改造或者創(chuàng)造框架時，應(yīng)該把數(shù)據(jù)的統(tǒng)一管理作為最基本的底線，這是上下游實現(xiàn)自動化的基礎(chǔ)。上一節(jié)中所提到的測試錄制的能力，就是建立在統(tǒng)一數(shù)據(jù)源的基礎(chǔ)上。再舉個更有意思的例子，過去的前端的 ajax 請求基本都是獨立調(diào)用 api，無中心的模式。這種模式可能會出現(xiàn)的問題是：
請求A發(fā)出后，由于網(wǎng)絡(luò)等問題，一直未返回，這時用戶有重新發(fā)送一次請求 A1。結(jié)果 A1 迅速返回在回調(diào)函數(shù)中提示成功。然后請求 A 超時返回，在回調(diào)中提示失敗，導(dǎo)致最后用戶看到的是失敗的信息。
當(dāng)引入 saga 之后，所有異步的操作都統(tǒng)一收歸到通信管道中，就能進行跨請求的管理了。單個異步請求的取消、多個異步請求到底是獨立、還是競爭、還是只保持最后一個，就都能很容易地實現(xiàn)了。基于中心化的請求管理，還能進行可視化：
(kuker)
繼續(xù)講到第二個問題，數(shù)據(jù)的生命周期是怎樣的？生命周期通常是由外部事件來觸發(fā)，或者自己運行到某一階段自動觸發(fā)的。對深度開發(fā)來說，有兩個基礎(chǔ)能力必須由框架來提供。即框架要支持：
手動驅(qū)動生命周期對自動化測試之類的功能來說很重要，特別是在做一些基礎(chǔ)性的測試時，有了這個能力就不用再完全模擬外部的觸發(fā)條件。而內(nèi)部數(shù)據(jù)的復(fù)制和置換則能為錄制、還原現(xiàn)場、協(xié)同等高級功能提供基礎(chǔ)。我們現(xiàn)在就在嘗試基于這種能力，實現(xiàn)“用戶可以將自己的出錯場景一鍵發(fā)送給開發(fā)人員來復(fù)現(xiàn)”的功能。值得注意的是，有的語言中復(fù)制對象是非常昂貴的操作，這時可能就需要考慮，是否使用 immutable 的數(shù)據(jù)格式會更好？還是依靠一些約定和標記提供自身提供廉價的復(fù)制能力？限于篇幅，在此就不再展開。對框架中的數(shù)據(jù)問題感興趣的讀者可以去搜索 Single Source of Truth 和 Shared Mutable State 之類的話題，業(yè)界已經(jīng)有非常多的精彩討論。
聊完數(shù)據(jù)，終于來到最有意思的邏輯部分。框架從某種意義上來說，就是提供了一種邏輯表達的方式。要在邏輯表達上提升效能，有兩個發(fā)展階段：
我們看到大部分的框架都處于第一個階段，不管是服務(wù)器端的 MVC 還是前端的 MVVM 。但也有少量第二階段的嘗試。例如 Flow Based Programming，試圖完全用數(shù)據(jù)流向的角度來詮釋業(yè)務(wù)中的邏輯。它的代碼可以天然被分析成圖，甚至能在運行時進行觀察：
(noflo)
還有《理想的應(yīng)用框架》中提到的基于事件來表示業(yè)務(wù)邏輯，也是一種 DSL。但這些嘗試離最終的目標仍然有差距，最終理想的狀態(tài)應(yīng)該是能實現(xiàn)業(yè)務(wù)流程圖、時序圖、決策樹等業(yè)務(wù)領(lǐng)域常用的表達方式與代碼的互轉(zhuǎn)。雖然有差距，而且看起來要走的路還很長，但是針對一些已經(jīng)比較穩(wěn)定的場景，已經(jīng)有一些好的經(jīng)驗。CMS 框架 Drupal 就是一個很好的例子。它定義好了數(shù)據(jù)發(fā)布的整個流程和相應(yīng)的鉤子系統(tǒng)，讓開發(fā)者用模塊的方式在鉤子里去修改或者增加自己的功能。曾經(jīng)一度實現(xiàn)了一個非常繁榮的社區(qū)。更值得肯定的是，社區(qū)中很多模塊都是可視化的，最終用戶不需要寫任何代碼，按照模塊的可視化指引就能完成相應(yīng)的功能。這實際上就等同于 DSL 與代碼的互轉(zhuǎn)了。
不管哪一個階段的關(guān)鍵技術(shù)，都離不開分析語義的能力。直白一點來說，就是“知道哪段代碼是干什么”的能力。
在第一階段的框架中，最影響效能的因素并不是”要寫代碼的多少“，而是寫按框架概念寫出來的代碼是否易于理解、易于維護。這一點在越是大型、越是多人參與的項目中，越是明顯。而代碼的“語義”是否清晰在某種程度上直接決定了我們是否能通過技術(shù)手段來提升可維護性。例如，在使用依賴注入的系統(tǒng)中，如果所有代碼的注入聲明都清晰地表明了注入的到底是什么的話，那我們就很容通過語言層面的支持或者簡單字符串匹配得到依賴關(guān)系圖。反之，如果注入的信息模糊，既可能是函數(shù)也可能是 model，沒有任何明顯約束的話，那就可能得通過語法樹，找到注入的入口才能分析出來，這樣實現(xiàn)的成本就成倍增加了。
(Rekit Studio 依賴分析圖)
相比于依賴分析，更重要的是“調(diào)用關(guān)系分析”，它對于幫助理解流程，特別是排查問題特別有用。舉個簡單的例子，在數(shù)據(jù)驅(qū)動的前端框架中，因為視圖完全是數(shù)據(jù)的展現(xiàn)，發(fā)現(xiàn)視圖不對了，如果能動態(tài)展示出修改了數(shù)據(jù)的業(yè)務(wù)堆棧(不是函數(shù)堆棧)，就非常有用。不需要再一步一步斷點。
當(dāng)然實現(xiàn)起來也更難。難點有兩個：一是依賴分析一般是運行前的，是靜態(tài)的，而調(diào)用關(guān)系一般是運行時的，是動態(tài)的；二是依賴通常是聲明出來，容易讀出來，而調(diào)用通常是在主動式的語句中，會遇到條件判斷、循環(huán)、甚至通過變量在不同函數(shù)、類作用域中傳遞，比較難分析。這種難，其實也就是語義不清。在框架的設(shè)計或者我們自己的改造中，可以通過三點來盡量提供明確的語義：
前兩點很好理解，被動聲明式的代碼結(jié)構(gòu)更容易被分析。雖然在實踐的時候需要大量經(jīng)驗，來保障設(shè)計出來的聲明格式即能覆蓋所有場景又要容易編寫，但是它帶來的收益也是最可觀的。GraphQL 就是一個最好的例子，在服務(wù)器端用聲明的結(jié)構(gòu)將數(shù)據(jù)結(jié)構(gòu)和關(guān)系表達出來，在客戶端用聲明的結(jié)構(gòu)將要獲取的數(shù)據(jù)結(jié)構(gòu)表達出來，后端就可以使用統(tǒng)一的引擎來生成調(diào)用，省去的大量寫接口的時間。第二點，盡量片段化是指我們在引導(dǎo)用戶寫代碼的時候，應(yīng)該把生命周期等等概念拆得盡可能小，使語義更細致。寫起來繁瑣的問題可以通過工具或者語法糖去解決。
第三點最重要，消除副作用指的是任何時候運行用戶的代碼片段應(yīng)該都不會對外部環(huán)境產(chǎn)生影響。而消除對外部作用域中變量的依賴指的是對要用的數(shù)據(jù)、服務(wù)盡量都用參數(shù)的形式傳入。這樣做的好處有兩個，對于一些復(fù)雜的，難以分析的調(diào)用的關(guān)系，可以將要觀測的對象包裝一下再傳入，這樣就能動態(tài)得到調(diào)用關(guān)系。在整體運行前，因為無副作用，也可以很容易地通過試運行這些片段來得到一些信息。雖然現(xiàn)在的語法樹工具已經(jīng)比較流行，但真的要完全通過語法分析來得到足夠的語義仍然有很大的工作量。而上述的這三點，可以看做是快速、廉價的實現(xiàn)方式，并且實踐中效果非常不錯。
最后值得一提的是，上面所講到的數(shù)據(jù)和邏輯中的原則與技術(shù)并不是相互獨立的。在《前端服務(wù)化——頁面搭建工具的死與生》和《通天塔之石——企業(yè)級前端組件庫方案》這兩篇文章中看到，我們所使用的很多技術(shù)，其實是混合支撐著數(shù)據(jù)修改追溯、組件屬性可視化等功能。他們中間有的也有著依賴關(guān)系。但相比于“數(shù)據(jù)和邏輯”這兩個源頭，這些并不重要。只要掌握了這兩個源頭面對的問題，其他都是能推導(dǎo)出來的。
對開源框架如何使用也是同樣的道理。對于嚴肅的企業(yè)生產(chǎn)來說，應(yīng)該找到業(yè)務(wù)所面臨場景的源頭，吸收解決問題的先進的想法，但自己實現(xiàn)，就像編程語言各自實現(xiàn)語言特性一樣。而不應(yīng)該只是停留在包裝開源框架這個層次。開源框架為了適應(yīng)盡量廣的場景，有更大的群眾基礎(chǔ)，給出的一定是普適性的方案，這種普適性在業(yè)務(wù)發(fā)展到一定程度，有了足夠多的獨特性之后就會變成巨大的包袱反噬研發(fā)效能。等到了這個時候再考慮自己研發(fā)，其遷移、適配、研發(fā)成本以及帶來的風(fēng)險可能會變得非常大。而我們從前文看到，掌握了框架研發(fā)的幾個核心，從小的場景就開始投入，成本并不高。最重要的是長久積累形成體系后，所帶來的“流程上自動化“、”降低下游實現(xiàn)成本”等能力能持續(xù)地幫助企業(yè)提升研發(fā)效能。
從流程的角度來看，提升效能的主要是靠自動化。而從系統(tǒng)的角度來說，則主要是靠能力的復(fù)用?！庇脩簟啊ⅰ绷鞒獭?、”權(quán)限“幾乎是任何業(yè)務(wù)系統(tǒng)中都存在的，因此將這三者也納入到了基礎(chǔ)研發(fā)體系的范圍。在這里我們并不打算深入到每個系統(tǒng)所面臨的具體問題中，只講兩點：
一、產(chǎn)品化或者子系統(tǒng)化，不要過早平臺化，對將來系統(tǒng)整體打包有益。過去的互聯(lián)網(wǎng)公司習(xí)慣將這些公用系統(tǒng)平臺化，各個業(yè)務(wù)系統(tǒng)來接入。但這幾年互聯(lián)網(wǎng)業(yè)務(wù)進入的都是新領(lǐng)域，面臨的市場、用戶常常是需要隔離的。這個時候系統(tǒng)整體復(fù)制的能力就變得非常重要，所以一開始就將這三者以子系統(tǒng)或者子產(chǎn)品的方式來對待，能為之后的發(fā)展提供更多的靈活性。
二、三者不是并列關(guān)系，不用糾結(jié)于能力解耦，制定核心系統(tǒng)接入規(guī)范才是最重要的。權(quán)限系統(tǒng)無論是 RBAC 還是 DAC 都離不開用戶系統(tǒng)的支持。流程則是既依賴于權(quán)限也依賴于用戶。如果把運行時框架看做是主板，這三者應(yīng)該是主板上的補充部分，一起為核心系統(tǒng)的接入提供針腳。同樣是為了系統(tǒng)整體打包的能力，應(yīng)該盡早制定核心系統(tǒng)接入的規(guī)范。
在《月相》一章我們探討了 web 基礎(chǔ)研發(fā)體系的構(gòu)成及部分重難點。相比于具體技術(shù)本身，這套方案對組織成長和重塑的意義更大。在這一章中我們會先從大團隊中兩個有啟發(fā)性的問題出發(fā)，逐步深入到如何打造一個更高效的研發(fā)組織方案中。雖然問題出現(xiàn)是在大團隊的，但對小團隊仍有兩點借鑒意義：
首先注意，我們討論的仍是 web 層的問題。這個現(xiàn)象在有多個不同業(yè)務(wù)的大公司中最常見。出現(xiàn)這種現(xiàn)象的原因有兩個，一是公司到了萬人規(guī)模，實際上就相當(dāng)于上百個百人規(guī)模的小公司，必然想法很多，出現(xiàn)重復(fù)的自然也多。
另一個更重要是，在 web 這個領(lǐng)域，特別是前端，基礎(chǔ)設(shè)施變化太快。
無論是瀏覽器底層所支持的 api，還是 javascript 語言本身變化都非常快。底層一變化，研發(fā)的各個環(huán)節(jié)必然出現(xiàn)基于新技術(shù)的空缺，很多框架和平臺就是隨著這些空缺出現(xiàn)的?，F(xiàn)象本身存在即合理，但如果有更好的統(tǒng)一管理，是能從如下兩個方面提取出巨大的效能的。
一、如果將研發(fā)流程中的各個環(huán)節(jié)中獨立的平臺統(tǒng)一，可以極大地加速業(yè)務(wù)開發(fā)。直接決定業(yè)務(wù)發(fā)展速度的是進行業(yè)務(wù)開發(fā)的工程師。他們最希望的就是只有一個平臺將研發(fā)的所有流程都搞定，并且盡量自動化。平臺一多，對業(yè)務(wù)開發(fā)工程師來說，學(xué)習(xí)、溝通、協(xié)作的成本就會陡增。這個成本有多大？在我們通過線下了解發(fā)現(xiàn)，這個成本很多時候甚至?xí)^業(yè)務(wù)開發(fā)本身。
二、加大對趨勢和方向的研究，預(yù)防無序的框架和平臺的投入，這樣能盡量防止走偏和無效勞動，也是一種提升。越是大的團隊，這一點越明顯?！盎A(chǔ)設(shè)施變化”這樣一個滾滾巨輪這些年壓碎了多少框架和平臺，其中很多產(chǎn)生的效益都不足以覆蓋其研發(fā)成本。更壞的是，出于個人利益等原因，有的平臺過時了也不肯下線，阻擋了整個團隊隨基礎(chǔ)設(shè)施一起進步的機遇，消耗的是更多的未來的人力。
我們在《月相》中提出的研發(fā)體系就是實現(xiàn)這兩個提升的具體手段。
首先，有一個完整的體系來將研發(fā)流程當(dāng)成一個整體對待，并且通過統(tǒng)一的平臺來實現(xiàn)，能更好地實現(xiàn)流程的自動化。降低一線工程師溝通、學(xué)習(xí)成本。
其次，對運行時框架的投入，本身就包含著對趨勢和新技術(shù)的研究，可以緩解被基礎(chǔ)設(shè)施帶著跑的問題。并且我們看到運行時框架研究到了一定程度，能夠極大的減少后續(xù)測試、監(jiān)控實現(xiàn)的成本，也降低了基礎(chǔ)設(shè)施變化所產(chǎn)生的多米諾效應(yīng)。這里對管理帶來的反思是，我們應(yīng)該謹慎“平臺化”的思考。特別是下游環(huán)節(jié)，因為“平臺化”的思維，必然要考慮對各種不同的端進行適配，必然要制定各種規(guī)范，這些都是人力成本。如《月相》中所示，上游理清楚并且統(tǒng)一后，下游是能有針對性地、很低成本地實現(xiàn)的，根本不需要“平臺級”的成本投入。當(dāng)然，在這里所說的只是減少技術(shù)上的投入，環(huán)節(jié)本身還是非常重要的。
平臺林立從某一方面來說也表示著團隊內(nèi)部有著大量的無序的力量，這種力量在團隊出現(xiàn)不同環(huán)節(jié)的分工時就產(chǎn)生了，盡早地建立研發(fā)體系就能盡早地將這些力量用起來，創(chuàng)造真正的價值。
很多大公司的 web 研發(fā)團隊都被當(dāng)成資源池來用，哪個業(yè)務(wù)需要就投入到哪里?，F(xiàn)象的直接原因有兩個：一是從管理的角度來說，web 層的研發(fā)工作相對來說可替換性強，具備形成資源池的可能。二是 web 研發(fā)處于業(yè)務(wù)決策鏈底層，人員相對來說最緊張，因此通過資源池的方式能動態(tài)地支持業(yè)務(wù)開發(fā)，是最簡單的解決方案。但這個方案其實是相當(dāng)?shù)托У摹Ｎ覀儚膶こ處焸€人的關(guān)注來切入這個話題。
首先從主觀的角度出發(fā)，一個有激情，對職業(yè)未來充滿憧憬的工程師與苦大仇深的工程師在效率上是有成倍差別的。除了其本身的性格外，造就這兩種態(tài)度有很大一部分是職業(yè)上升渠道的問題。首先，和任何能被當(dāng)成資源池來用的工作一樣，因為可替換性強，所以不容易被重視。其次，目前的上升渠道不夠。web 研發(fā)工程師的上升渠道要么是縱向的，當(dāng)業(yè)務(wù)發(fā)展得足夠好，重要性提高，成為系統(tǒng)負責(zé)人。要么是橫向的，隨著團隊擴大，管理需要，成為管理者。這兩者一個基于業(yè)務(wù)一個基于人力，和技術(shù)相關(guān)不大。所以有才華的工程師自然會想要造框架、造平臺，努力成為公司技術(shù)中重要的一部分。但沒有正確的引導(dǎo)，就會成為上面所說”無序的力量“，發(fā)展得不對反而會變成公司的消耗。而當(dāng)他發(fā)現(xiàn)自己付出的努力得不到回報的時，就有可能變成苦大仇深的工程師。
最終影響的不只是工程師自身，公司也會要在管理成本上為其買單。我們在與一些資深 hr 交流時，他們進一步說明了這個問題。在公司工作了四、五年的員工，是已經(jīng)融入了公司，理解公司文化也了解公司問題的人，算是中流砥柱。如果得不到好的上升，可能會有兩種情況：其中有想法有行動力的，多半會選擇離開。既會對組織穩(wěn)定性會造成影響，也會讓公司付出的培養(yǎng)成本付諸東流，對公司來說可算是很大的損失；另一種更不好的則是既不離開，也不像以前一樣努力。他們在團隊內(nèi)有一定的話語權(quán)，卻喪失了進去的激情，不再發(fā)揮積極的作用。當(dāng)公司需要快速擴張、快速發(fā)生變革的時候，他們就會成為隱性的管理成本。
而解決方案，其實很簡單。大公司內(nèi)部通常都有”框架組“、”平臺組“類似的部門，但基本都停留在”可用“階段就完成任務(wù)了。這遠遠不夠，如果將建立 web 基礎(chǔ)研發(fā)體系作為目標，以產(chǎn)品化為衡量標準，加強重視和投入。 web 工程師的上升渠道就會得以擴張，公司內(nèi)無序的力量就會進入到正確的領(lǐng)域。創(chuàng)造的價值又能進一步為研發(fā)提供能量，形成一個正循環(huán)，逐步緩解人力緊張的態(tài)勢，資源池現(xiàn)象也就自然會消失。這很像我們身體受傷時，外部腫脹只是炎癥的表現(xiàn)，消炎了，腫脹自然也就好了。重點是找到關(guān)鍵進行消炎，而不是圍著外部現(xiàn)象思考。
建立體系還能帶來的好處是，通過提升 web 研發(fā)的效率，降低業(yè)務(wù)研發(fā)所需的人數(shù)，能幫助大公司重新回到小步快跑的節(jié)奏。張小龍有一篇演講《警惕KPI和復(fù)雜流程》，講到了小團隊的重要性，隨著互聯(lián)網(wǎng)公司的競爭越來越激烈，這種重要性會變得越來越高。我們從一些互聯(lián)網(wǎng)的新巨頭上，其實已經(jīng)看見了“核心技術(shù) 基礎(chǔ)web研發(fā)能力”來快速出產(chǎn)品，占領(lǐng)市場的趨勢。對小公司來說，統(tǒng)一的 web 基礎(chǔ)研發(fā)體系，是幫助實現(xiàn)超車的重要一環(huán)。對大公司來說，則是進一步挖掘效能，防止掉隊的必修課了。
這篇文章筆者前后重寫了三次，因為面對 web 一線工程師這樣一個龐大的群體，效能提升已經(jīng)不僅僅是技術(shù)或管理某一方面的事情，而是要綜合各個方面來尋求個人和公司發(fā)展的共贏。 web 一線研發(fā)是很多工程師進入這個領(lǐng)域最開始做的事情，但是筆者看到了很多有才華的人困在了低效、重復(fù)的工作里面，努力了也因為方向不對而徒勞。這對個人和公司都是損失。在技術(shù)上找到方向，在管理上予以支持，多方發(fā)力，其實能提升的效能遠超十倍。當(dāng)然，一篇文章不足以實現(xiàn)任何改變，這篇文章最主要的目還是拋磚引玉，也希望對這個方向有想法，志同道合的朋友聯(lián)系我，一起交流，一起推動。
郵箱: ariesate@outlook.com。
問：研發(fā)體系的統(tǒng)一規(guī)劃不是破壞了競爭和創(chuàng)新嗎？
答：統(tǒng)一規(guī)劃并不是指不要競爭，不要創(chuàng)新。而是防止開倒車的情況出現(xiàn)，是給競爭和創(chuàng)新指定一個方向。例如我們在文中理清上下游關(guān)系，目的是指導(dǎo)研發(fā)力量應(yīng)該往哪里投入，在投入的過程中仍然可以采取競爭的形式。
問：框架研發(fā)提升效能的趨勢？
答：分兩個方向。一是框架本身，會朝著“增強對用戶代碼的理解和控制力”這個方向前進。用戶按框架寫的代碼，能不能通過工具分析出具體的語義？人工的低級錯誤能不能自動檢測出來并自動修正？能不能轉(zhuǎn)化成某種人類習(xí)慣的表達方式，比如圖？當(dāng)控制力達到一定程度后，這些能力都實現(xiàn)后，再往下應(yīng)該就是代碼的自動生成。
另一個值得一提的是框架能力與業(yè)務(wù)特有屬性會一起沉淀到 IDE 上，會出現(xiàn)面向?qū)Ｓ锌蚣艿?IDE，面向單個具體工程的 IDE。分析圖，自動掃描工具都由 IDE 作為載體，就像很多游戲的專用編輯器一樣。只有沉淀到 IDE 上才是最便捷、最有針對性的。對這個方向感興趣的讀者可以跟我郵件討論，目前我們已經(jīng)有一些初步的想法。
問：文章中講到的問題都是大公司的，對小團隊來說，什么時候應(yīng)該開始建立自己的基礎(chǔ)研發(fā)體系？
答：研發(fā)體系的建立可以分為規(guī)劃和實施兩個階段。規(guī)劃的話，從一開始就應(yīng)該有所規(guī)劃。在前期人力不夠的情況下，不用強行追求打造自己的框架和工具，可以用開源的。但應(yīng)該始終把開源的東西拿到自己的體系中，清楚地知道它在自己體系中的角色，也清晰地知道自己用了它的什么特性，未來還需要補充什么。什么時候開始實施其實有一個象征性的標準，也是我們前面在無序的力量中提到的——出現(xiàn)了不同環(huán)節(jié)的分工時。有的團隊業(yè)務(wù)擴張?zhí)欤肆σ恢辈粔?，那么建議按五分之一到三分之一的比例來抽出人力打造基礎(chǔ)設(shè)施。磨刀不誤砍柴工，何況投資得到的回報是電鋸呢。
聯(lián)系客服
