企業(yè)里的研發(fā)部門、技術(shù)團(tuán)隊(duì)其實(shí)更多的是軟件/互聯(lián)網(wǎng)公司的生產(chǎn)部門，好比實(shí)體產(chǎn)業(yè)的生產(chǎn)車間。生產(chǎn)車間可以通過更新車床、設(shè)備來提高生產(chǎn)力，這里的車床、設(shè)備即是“資產(chǎn)”，那么研發(fā)部門的“資產(chǎn)”類比一下就出來了，就是部門級(jí)的技術(shù)標(biāo)準(zhǔn)、工具。 對(duì)于團(tuán)隊(duì)人效來說，統(tǒng)一的技術(shù)庫、技術(shù)組件能夠形成有效的技術(shù)隔離帶，節(jié)省很多二次學(xué)習(xí)成本。

一個(gè)案例

先說一個(gè)經(jīng)典案例：程序員小a長期在A項(xiàng)目進(jìn)行開發(fā)編碼工作，突然同部門下的B項(xiàng)目緊急缺人，小A被調(diào)到B項(xiàng)目進(jìn)行開發(fā)，小a在看過多輪“五花八門”的項(xiàng)目文檔之后，終于打開了idea，結(jié)果發(fā)現(xiàn)pom文件一堆爆紅，排查后發(fā)現(xiàn)是自己本地的配置的A項(xiàng)目組內(nèi)網(wǎng)遠(yuǎn)程倉地址缺少很多B項(xiàng)目代碼的依賴，東問西調(diào)跑到外網(wǎng)進(jìn)行依賴補(bǔ)全，解決了B項(xiàng)目的依賴問題；終于進(jìn)入編碼階段了，結(jié)果在面對(duì)使用Es問題時(shí)，B項(xiàng)目里的client的版本和A項(xiàng)目不一樣，其中關(guān)于Es的嗅探、超時(shí)機(jī)制、DSL編寫方式、API調(diào)用也是B項(xiàng)目單獨(dú)封裝的一套風(fēng)格和接口層，于是小a又費(fèi)上時(shí)間去看返回對(duì)象的結(jié)構(gòu)、封裝邏輯、API的參數(shù)調(diào)用邏輯以此來達(dá)到更好的使用效果……

雖然以上這個(gè)過程大家都見怪不怪，團(tuán)隊(duì)以項(xiàng)目為單位，割裂嚴(yán)重，雖然同一研發(fā)部門，但是換個(gè)項(xiàng)目好比換了個(gè)工作，甚至同一項(xiàng)目下，不同模塊、功能組間代碼五花八門，這太常見了，這樣的常見背后的問題是：

• 缺乏統(tǒng)一的標(biāo)準(zhǔn)（文檔標(biāo)準(zhǔn)），導(dǎo)致溝通成本增加
• 缺少集中的技術(shù)支持（穩(wěn)定且全面的私倉、研發(fā)環(huán)境），研發(fā)準(zhǔn)備成本高
• 無效學(xué)習(xí)（同一技術(shù)點(diǎn)，需要學(xué)習(xí)多種人為造成的外在形式）隱形消耗

雖然功能、產(chǎn)品、項(xiàng)目五花八門，但其實(shí)技術(shù)重疊部分較多，而這些重疊部分又每每在以上三點(diǎn)上消耗，形成無形的成本浪費(fèi)，導(dǎo)致效率、質(zhì)量低下。

“技術(shù)資產(chǎn)”的概念

其實(shí)經(jīng)常思考一個(gè)問題，一個(gè)技術(shù)團(tuán)隊(duì)，或者說一個(gè)企業(yè)的研發(fā)部門，它的核心資產(chǎn)是什么，答案可能有很多，例如團(tuán)隊(duì)人才、團(tuán)隊(duì)信任、團(tuán)隊(duì)默契……等等，但是其實(shí)這些都是比較虛的東西，不可否認(rèn)這些內(nèi)容確實(shí)重要，但是它是一種“軟實(shí)力”，并不是“資產(chǎn)”。所謂“資產(chǎn)”是經(jīng)過沉淀后，可以直接拿來重復(fù)使用，從本質(zhì)上降低生產(chǎn)成本的“實(shí)物”。

企業(yè)里的研發(fā)部門、技術(shù)團(tuán)隊(duì)其實(shí)更多的是軟件/互聯(lián)網(wǎng)公司的生產(chǎn)部門，好比實(shí)體產(chǎn)業(yè)的生產(chǎn)車間。生產(chǎn)車間可以通過更新車床、設(shè)備來提高生產(chǎn)力，這里的車床、設(shè)備即是“資產(chǎn)”，那么研發(fā)部門的“資產(chǎn)”類比一下就出來了，就是部門級(jí)的技術(shù)標(biāo)準(zhǔn)、工具。

“技術(shù)資產(chǎn)”的意義

效率

 

 

其實(shí)大多數(shù)所謂的“技術(shù)領(lǐng)先”、“技術(shù)創(chuàng)新”的本質(zhì)都是縫縫補(bǔ)補(bǔ)，真正高大上的技術(shù)或者技術(shù)研究終究是掌握在少數(shù)人和企業(yè)的手里，能夠快速響應(yīng)和支撐市場才是大多數(shù)企業(yè)研發(fā)的主題。更多的是用“馬斯克”思維，別管low不low，能快速響應(yīng)市場，快速支撐成品才是硬道理。

• 積木式拼接：快速搭建項(xiàng)目開發(fā)基礎(chǔ)
  • 站在效率角度，通過完備的技術(shù)資產(chǎn)快速構(gòu)建技術(shù)方案，以積木拼接原理能夠很快完成主體框架的搭建和復(fù)用，完備的技術(shù)流支撐下，精力和資源更容易聚焦到核心業(yè)務(wù)中，提高競爭力。
• 公共抽離：減少問題的分散
  • 就像編程原理一樣，將常用的、通用的部分抽離出來，統(tǒng)一歸置到一個(gè)位置，在需要相關(guān)能力時(shí)直接調(diào)用，需要調(diào)整時(shí)一處調(diào)整，隨處響應(yīng)，能大幅度地提高維護(hù)效率。

質(zhì)量

技術(shù)資產(chǎn)是經(jīng)過多輪項(xiàng)目和實(shí)戰(zhàn)抽離出來的實(shí)體“經(jīng)驗(yàn)”，確定性和穩(wěn)定性都是經(jīng)過認(rèn)證的。同樣的問題早已經(jīng)在技術(shù)資產(chǎn)層面解決和規(guī)避過了，不會(huì)在新項(xiàng)目中再現(xiàn)。

相比于硬編碼開發(fā)新項(xiàng)目，依賴的是人員的經(jīng)驗(yàn)和技術(shù)素養(yǎng)，基于“積木”式的組裝代碼則依賴更具體、更量化的技術(shù)組件，質(zhì)量也更為可控

成本

站在成本的角度考慮，技術(shù)資產(chǎn)的存在能夠大幅降低人效和溝通等隱形成本。

• 減少“個(gè)人因素”影響，減少無效學(xué)習(xí)時(shí)間
  • 對(duì)于團(tuán)隊(duì)人效來說，統(tǒng)一的技術(shù)庫、技術(shù)組件能夠形成有效的技術(shù)隔離帶，全局整齊劃一，相同的基礎(chǔ)技術(shù)點(diǎn)采用統(tǒng)一的文檔和使用規(guī)范，節(jié)省很多二次學(xué)習(xí)成本
• 規(guī)避信息傳遞過程中的“噪音”干擾，降低溝通成本
  • 基礎(chǔ)技術(shù)的穩(wěn)定同時(shí)也能減少設(shè)計(jì)、信息傳遞時(shí)的溝通成本，避免業(yè)務(wù)人員提業(yè)務(wù)問題而技術(shù)人員回答技術(shù)問題，雞同鴨講的情況。同時(shí)在研發(fā)溝通時(shí)，可以統(tǒng)一技術(shù)話術(shù)與版本術(shù)語，減少因信息術(shù)語不同而反復(fù)確認(rèn)的時(shí)間浪費(fèi)。
• 降低個(gè)人“壁壘”，提高人效
  • 基礎(chǔ)技術(shù)的穩(wěn)定，能保證在進(jìn)行項(xiàng)目交接和人員流動(dòng)時(shí)，最大力度的保持項(xiàng)目代碼的穩(wěn)定性，不會(huì)因某些技術(shù)點(diǎn)的引入而人員強(qiáng)制綁定的效果。一個(gè)部門下熟悉技術(shù)資產(chǎn)的研發(fā)，只需要了解不同業(yè)務(wù)，就可以隨時(shí)無縫切換任意項(xiàng)目，甚至可以身兼多職。

“技術(shù)資產(chǎn)”的建設(shè)

技術(shù)資產(chǎn)站在編碼研發(fā)角度無非兩類，在編碼一級(jí)對(duì)應(yīng)的是二方庫，在架構(gòu)一級(jí)對(duì)應(yīng)的則是技術(shù)底座。

這二者對(duì)應(yīng)我在領(lǐng)域驅(qū)動(dòng)那部分說過的通用域和支撐域，其實(shí)不論是否使用領(lǐng)域驅(qū)動(dòng)，統(tǒng)一的二方庫和底座都是一個(gè)團(tuán)隊(duì)的必需品，一定要有是第一要素；

其次就是建設(shè)粒度，至于建設(shè)到何種粒度，取決于團(tuán)隊(duì)規(guī)模和項(xiàng)目訴求，但是不可好高騖遠(yuǎn)，一個(gè)以做具體業(yè)務(wù)系統(tǒng)為主的企業(yè)或部門卻要去搭建一個(gè)通用的“數(shù)據(jù)中臺(tái)”工具這種就是好高騖遠(yuǎn)，系統(tǒng)級(jí)開發(fā)的，甚至連服務(wù)器群組都不具備的規(guī)模，一個(gè)穩(wěn)定且統(tǒng)一的二方庫，基于SDK包構(gòu)建項(xiàng)目足夠了，不要為了做而做。

最后就是執(zhí)行力度，既然費(fèi)力建設(shè)了，就要“快刀斬亂麻”，一鼓作氣進(jìn)行全量替換重構(gòu)或者逐步重構(gòu)替換，不要以“工期”、“進(jìn)度”、“等新項(xiàng)目再開始用”等理由，讓已經(jīng)完成的技術(shù)資產(chǎn)處于閑置狀態(tài)，因?yàn)榧夹g(shù)資產(chǎn)是需要通過使用來驅(qū)動(dòng)演進(jìn)的。只建設(shè)不使用，也是“為了做而做”。

二方庫建設(shè)

二方庫的概念

關(guān)于二方庫的概念來自于阿里的開發(fā)手冊(cè)，大體的定義是這樣的：

名稱	含義	所屬級(jí)別
一方庫	當(dāng)前項(xiàng)目工程中的各模塊的相互依賴，是本項(xiàng)目中的依賴。比如一個(gè)多module項(xiàng)目中,一個(gè)module依賴于同項(xiàng)目中其他一個(gè)或多個(gè)module	項(xiàng)目級(jí)
二方庫	公司內(nèi)部的依賴庫，一般指公司內(nèi)部的其他項(xiàng)目發(fā)布公共jar包。	公司或部門級(jí)
三方庫	公司之外其他組織的開源庫， 來自第三方的依賴比如apache、google等發(fā)布的jar包。	互聯(lián)網(wǎng)開源庫

根據(jù)定義，二方庫的概念和我之前在領(lǐng)域驅(qū)動(dòng)文章中提到的通用域重合。

 

二方庫的開發(fā)原則與思路

首先，就是要建立完善且穩(wěn)定的內(nèi)網(wǎng)倉庫，用以存放經(jīng)過認(rèn)可的三方庫依賴包和自身開發(fā)的庫包，研發(fā)內(nèi)部均以此倉庫為準(zhǔn)。

以后端Java系為例，二方庫最經(jīng)典的表現(xiàn)形式就是spring-starter，技術(shù)資產(chǎn)的搭建主要是建設(shè)內(nèi)網(wǎng)穩(wěn)定的maven倉庫，maven內(nèi)網(wǎng)倉庫主要包含三部分：

• 原裝的三方庫信息：公網(wǎng)中的通用依賴，作為開發(fā)的最基本素材
• 已有三方庫的二開內(nèi)容：根據(jù)內(nèi)部需要基于三方庫進(jìn)行改造的包，形成自己內(nèi)部的使用規(guī)范和標(biāo)準(zhǔn)
• 源代碼開發(fā)內(nèi)容：自主研發(fā)的組件、包、工具。

原裝三方庫

針對(duì)三方庫這一點(diǎn)，沒有其他的操作，只需要建立完善的公網(wǎng)maven到內(nèi)網(wǎng)maven的通道即可，針對(duì)三方庫，需要做的就是保證更新策略，能夠及時(shí)更新內(nèi)部maven庫中的依賴包，保證在開發(fā)需要用到三方庫時(shí)不需要再費(fèi)力尋找；另外在通道同步時(shí)，要進(jìn)行一定的安全過濾，對(duì)于已經(jīng)發(fā)生的安全漏洞、嚴(yán)重問題的依賴，要建立完善的及時(shí)攔截和更新策略，從項(xiàng)目伊始就降低安全問題的修改成本。

二開內(nèi)容 

二開的內(nèi)容主要是基于三方庫或其他開源項(xiàng)目的二次開發(fā)，內(nèi)容包括：進(jìn)行內(nèi)容整合、進(jìn)行功能擴(kuò)展、進(jìn)行內(nèi)容改造、修復(fù)已知問題；例如可以基于自身部門項(xiàng)目特點(diǎn)，集成常用的依賴，建設(shè)后端項(xiàng)目腳手架。根據(jù)自身的業(yè)務(wù)訴求，對(duì)flowable的流程處理進(jìn)行封裝疊加等等。

需要注意的是，因?yàn)樵诠俜酵鈸诫s了個(gè)人意志的代碼，多多少少就會(huì)增加一些信息復(fù)雜度，所以對(duì)于二開的庫類，需要配套完善的文檔和使用說明，文檔和使用說明是二方庫開發(fā)的一部分。

源代碼開發(fā)

基于企業(yè)或團(tuán)隊(duì)自研的成果，要保證其安全性和私密性，僅允許內(nèi)部使用，是團(tuán)隊(duì)技術(shù)的核心競爭力；這里的源代碼開發(fā)并不一定指是從0到1的開發(fā)成果，某些二開組件，只要是在某些基礎(chǔ)之上進(jìn)行創(chuàng)新型、獨(dú)有的改造也可以歸為此類。

二方庫涉及的范圍一般為：

組件	描述
通用對(duì)象處理工具	例如、文件上傳下載、文件操作、時(shí)間、日期處理、字符串處理、緩存管理工具、線程管理工具、集合、數(shù)組處理工具、協(xié)議通信等Util類工具
統(tǒng)一的安全過濾機(jī)制	統(tǒng)一的AOP切入，針對(duì)各類注入、透傳等內(nèi)容的攔截、參數(shù)校驗(yàn)規(guī)則注解等安全類問題處理機(jī)制
各類三方組件的適配對(duì)接	各類數(shù)據(jù)庫、存儲(chǔ)庫、消息管道的第三方組件的適配starter以及與其相關(guān)的操作適配，例如Mybatis的SQL方言統(tǒng)一兼容等
代碼腳手架	統(tǒng)一的項(xiàng)目parent，統(tǒng)一集中控制項(xiàng)目中的三方依賴
日志監(jiān)控機(jī)制	各類監(jiān)控日志、系統(tǒng)運(yùn)行情況的輸出機(jī)制
……	……

技術(shù)底座建

 

這里叫技術(shù)底座也頗有些“吹噓”嫌疑，其實(shí)也可以理解為是“重型”二方庫，說白了就是現(xiàn)在很多企業(yè)吹的自研XXX平臺(tái)、XXX引擎，是一種可適配多場景、多應(yīng)用、集成項(xiàng)目時(shí)使用的重型技術(shù)組件。

技術(shù)底座建設(shè)原則

底座的定位與基本邏輯

這里技術(shù)底座并非是平臺(tái)或業(yè)務(wù)系統(tǒng)，它的定位本質(zhì)上還是組件，只不過是適用范圍更為寬泛，體系更為完整。

應(yīng)該是可以節(jié)約開發(fā)成本的技術(shù)性平臺(tái)，它的底層邏輯是為更大、更復(fù)雜系統(tǒng)提供能力支撐，使用時(shí)并不能像二方庫一樣開箱即用，面對(duì)不同的使用方或場景，項(xiàng)目代碼是需要進(jìn)行一定的適配和開發(fā)。例如研發(fā)一套前端低代碼平臺(tái)，以提供“拖拉拽”的形式省去重復(fù)的前端代碼編寫，以技術(shù)能力來簡化實(shí)現(xiàn)；又或者開發(fā)一套輕便級(jí)的編排響應(yīng)，配合簡單的元數(shù)據(jù)定義，以此來支撐多數(shù)場景下，系統(tǒng)與第三方數(shù)據(jù)的交換對(duì)接。

開發(fā)原則主要有兩點(diǎn):

• 要面向技術(shù)抽象開發(fā)，而不是面向業(yè)務(wù)開發(fā)
• “站在巨人的肩膀上”

面向技術(shù)抽象開發(fā)

技術(shù)底座應(yīng)該是面向抽象內(nèi)容設(shè)計(jì)，而不是具體的業(yè)務(wù)設(shè)計(jì)。具體到實(shí)現(xiàn)就是，面向數(shù)據(jù)結(jié)構(gòu)和能力邏輯設(shè)計(jì)而不是具體的系統(tǒng)功能設(shè)計(jì)。

技術(shù)底座的實(shí)現(xiàn)是為了在架構(gòu)層面進(jìn)行有效的聚合，能夠作為架構(gòu)層面的拼接“積木”，所以要提供更高層次的抽象，以便有更廣的適用范圍。跟它的定位一致，要以提供能力為目標(biāo)，而不是為迎合某個(gè)項(xiàng)目或產(chǎn)品為目標(biāo)，這一點(diǎn)在設(shè)計(jì)和演進(jìn)中一定要把控。

“站在巨人的肩膀上”

直白的來講就是盡可能基于穩(wěn)定版本的開源組件進(jìn)行二開，“站在巨人的肩膀”上前行。一定要避免研發(fā)的通病——手搓核彈。

首先明確建設(shè)技術(shù)底座的原因是減少技術(shù)差異性和降低開發(fā)成本，所以一定不要不過一切的大量投入產(chǎn)研能力去從零開始，原本為了降低成本的事，反而成了增加成本，是一種本末倒置；其次就是一個(gè)比較現(xiàn)實(shí)的問題，不要過分相信自己的能力，這種通用型的技術(shù)底座，或多或少地都要涉及到IO、編譯原理等等較為深的技術(shù)點(diǎn)，直接使用成熟的開源項(xiàng)目進(jìn)行上層封裝，或者整合相關(guān)的組件是明智的選擇。

技術(shù)底座的必要性

其實(shí)對(duì)大多數(shù)企業(yè)和部門來講，一個(gè)完善的二方庫就足夠了，沒有必要建設(shè)技術(shù)底座。

即便是采用成熟開源項(xiàng)目二開，也是極其消耗資源的投入，而且很容易在開發(fā)過程中走入不可控局面，最終成了一個(gè)“玩具demo”和匯報(bào)PPT的素材。精力資源也投入，項(xiàng)目反而沒有多少獲利，純純是研發(fā)人員自己的狂歡。

決定建設(shè)技術(shù)底座前要考慮如下因素：

• 項(xiàng)目體量和規(guī)模是否值得使用技術(shù)底座
• 能否抽象出多產(chǎn)線、項(xiàng)目的通性內(nèi)容
• 使用技術(shù)底座能否降低成本

如果一個(gè)部門或企業(yè)，項(xiàng)目多為單體的或者特殊領(lǐng)域的定制內(nèi)容，并沒有整建制的框架規(guī)劃，則沒有必要建設(shè)和使用技術(shù)資產(chǎn)；另外多項(xiàng)目組、產(chǎn)品間是否通用訴求較多，例如ETL過程、編排響應(yīng)、繁重的頁面開發(fā)、大規(guī)模的算法模型使用等等；如果建設(shè)和使用技術(shù)底座后，并不能明顯地降低開發(fā)成本，只是開發(fā)流程或者開發(fā)形式上發(fā)生了變化而看起來像降低了開發(fā)成本，則要慎重決定。

“技術(shù)資產(chǎn)”的演進(jìn)歷程

與項(xiàng)目一樣，技術(shù)資產(chǎn)也是迭代前行的，它需要項(xiàng)目的驗(yàn)證和反饋，然后不斷更新和迭代，然后再反過來支持項(xiàng)目的開展。

在建設(shè)上，需要將技術(shù)資產(chǎn)的開發(fā)分為穩(wěn)定池與開發(fā)池，穩(wěn)定池中存放的是能夠放心使用且適配完善的發(fā)布版內(nèi)容；二開發(fā)池則是需要不斷接收不同項(xiàng)目、不同開發(fā)任務(wù)的需求和反饋，進(jìn)行設(shè)計(jì)開發(fā)的“測試版”；

例如，某個(gè)項(xiàng)目需要在各子系統(tǒng)啟動(dòng)后向主系統(tǒng)匯報(bào)運(yùn)行情況，而另一項(xiàng)目需要新增一個(gè)系統(tǒng)運(yùn)行狀態(tài)頁面，此時(shí)就需要結(jié)合多個(gè)系統(tǒng)相似的訴求，設(shè)計(jì)開發(fā)一個(gè)系統(tǒng)監(jiān)控的starter發(fā)布使用，由于項(xiàng)目周期原因等因素，可先一步完成項(xiàng)目，再技術(shù)組件形成后考慮是否迭代替換或不替換，而只在后續(xù)有新項(xiàng)目開啟時(shí)使用此starter； 又或者在使用過程中，發(fā)現(xiàn)某個(gè)組件包的功能存在問題和風(fēng)險(xiǎn)，例如安全問題等，可以針對(duì)該組件包進(jìn)行加固改造，然后發(fā)布新版本并全局聲明替換。