CBB（Common Building Block）即共同性構建模塊，指那些可以在不同產品、系統之間共用的零部件、模塊、技術及其他相關的設計成果，軟件、硬件系統都有自己的CBB。在產品中我們鼓勵共享和重用CBB，這里面好處很多，比如對于采購、制造這些領域，CBB可以降低采購成本，降低庫存和出現物料呆死的風險，也更利于大批量制造。

我們重點討論一下硬件CBB，硬件基礎模塊是硬件系統中一組實現特定功能、性能及規格的實體硬件單元，對外以硬件接口的方式呈現，而接口包含了硬件模塊所提供的功能和應用它時所需的要素。硬件基礎模塊是構成硬件產品和硬件系統的單元，是基于硬件系統架構逐步抽象出來、定義開發的，硬件CBB包括可共享硬件器件、可共享硬件組件/模塊、可共享單板、可共享整機、可共享硬件系統等。

對于硬件研發團隊硬件CBB的價值很大，對CBB的堅定投資是有高回報的。首先，硬件技術、硬件模塊若被大量共享，能夠極大降低研發成本，提升研發效率；在硬件共享的基礎上，增加新技術、新特性，新產品的開發將一直“站在巨人的肩膀”，利于對市場做出快速反應。同時，工程師在一個CBB模塊上持續發現、解決問題，提升CBB質量，打磨出高質量的CBB，這也是產品質量保障的有效手段，共享成熟度高的貨架產品，能夠大大增加了產品穩定性和可靠性。另外，堅持共享，可以減少開發團隊低水平重復投入，釋放人力資源做更有價值的工作。

很多做硬件產品的大公司都把硬件CCB作為系統構建的核心資產，堅持通過CBB的開發和維護提高整體設計效率和設計質量，縮短開發周期。在大公司里有些高價值的CBB甚至可以跨產品、跨產品線共用，支持不同的應用系統，具備靈活方便的二次開發能力；與產品或應用系統間界面清晰，能實現平行開發；硬件CBB模塊功能規格、性能指標清晰，可測試、可維護，還有完善的資料手冊。大公司把CBB的構建定義為平臺戰略的關鍵支點，是公司重要的組織資產。

硬件工程師要特別要關注那些高價值硬件CBB的開發和維護。比如，你開發的無線路由器產品都會應用2.4G或5G的棒狀天線，那么就要關注天線的性能指標、降成本空間、應用問題等；如果你是開發服務器產品的，可能70%的產品都會重用一款X86 CPU，那CPU CBB的硬件設計就是至關重要的，CBB交付后，你還要持續跟蹤供應商，刷新器件問題列表，合入新的優化點。這些高價值CBB的持續投入能夠讓借用這個CBB的多款產品都收益。

“好的CBB是管理出來的”，CBB管理過程不是一個獨立的流程，而是嵌入在產品流程化的開發活動中。CBB管理可以分為4個階段：定義規劃、設計開發、使用監控、維護優化四個階段，詳解一下這四個階段的主要工作。

階段一：規劃定義階段

在總體設計階段，就要規劃CBB，針對不同種類的產品，CBB規劃的側重點就不一樣。如復雜框式硬件，產品的生命周期很長，對于電源、風扇、拉手條等關鍵組件都必須要CBB化；各單板上對于背板的接口、各個單板子節點的監控也要定義為CBB，保證規則和設計要求的一致。盒式海量發貨的單板很多都是系列化的設計，在一個系列中核心模塊是共用的，比如CPU模塊、業務接口模塊等，為了保證一個系列類所有單板都遵循統一規則，并且整個產品系列成本最優，這些核心共用模塊都要規劃為CBB。終端類產品的CBB更有學問了，這類產品的定制化訴求強烈，單個款型對成本都極度敏感，因此如果定義CBB，必須要和產品設計耦合度極低，避免對其它模塊設計有影響，因為冗余設計導致成本增加。

階段二、設計開發階段

規劃好后，我們要進行CBB的設計。首先要確定好硬件CBB的設計人員，由于CBB是一個通用模塊，工程師設計CBB時要跳出單板，看到系列化的產品和這個產品的演進路徑，心里有全景圖，才可能做出一個有生命力的CBB。定了設計人員，就要認真分析CBB的各種接口，做好抽象的工作，這個設計很考驗硬件工程師，接口定義不全就很難通用化，定義的過于復雜，冗余太多，又會在CBB上沉淀過多的成本，應用起來復雜度很好。比如，CPU這類核心處理模塊定義CBB難度就很高，內存和Flash怎么定義？電源模塊是放到CBB內，還是CBB外？集成方式是扣板還是在直接放在主板上？等等這些問題都需要仔細考慮。定義完接口后就要做模塊的原理圖和PCB，想到你的模塊會被大量借用，你就會感到自己責任重大了。最后，還要提醒一下，CBB一定要通過文檔傳遞你的接口定義和關鍵的設計要求，方便借用者使用。

階段三、使用監控階段

好的CBB不是一蹴而就了，CBB交付后會在一塊或者幾塊單板上先使用，這時候你就要開始監控使用時遇到的問題，不管是在設計階段還在產品上市發貨后。硬件工程師要監控這些CBB模塊在整機或者系統被借用時，使用是否方便，接口的定義對主板的設計限制是否太多了。模塊在發貨后適應不同單板和系統在不同場景應用有什么質量問題，比如是不是借用到室外產品后防護規格就不滿足要求了。收集這些問題后，進行記錄和整理，這個是進行CBB優化的依據。

階段四、維護優化階段

問題都收集全了，下一步就是進行優化了，切記每一個改動都要特別小心，要做好記錄，改動點的驗證要覆蓋到這個CBB不同的場景上。這里還要強調一下，硬件CBB的修改是否影響軟件系統要特別注意，我們在CBB設計階段都會把硬件對軟件的要求寫清楚，和軟件工程師做好澄清，但是在硬件CBB維護優化時，有時會疏漏針對所有借用CBB的單板或整機同步修改點，請軟件工程師分析是否要優化軟件，導致了硬件模塊優化升級了，軟件適配沒更上，產品一上線問題就暴露了。

這十多年中，我從一個初入硬件行業的小白逐步成長為一個老練的硬件工程師，我一直在和CBB打交道。

剛進入硬件團隊的時候被師傅安排去維護幾個成熟的CBB，根據收集到的問題進行優化。那時候有兩點體會，一是有些同事水平很高，設計出的CBB考慮非常全面，特別是對于場景適應性的考慮很細致，借用到單板或整機上問題很少，我維護起來很方便；二是CBB優化后的驗證是個技術活，修改點要覆蓋全，這逼著我去熟悉不同的單板。

后來，我有機會做核心CBB的設計師，那時候覺得很有榮譽感，當時我做了一個ARM CPU的CBB，做接口設計時天天都和軟件架構師泡在一起，學習業務模型，軟件規格升級要求等知識，覺得自己進步很快。還有一個讓我印象深刻的事是，當時我的主管要求我硬件CBB設計一定要文檔化，文檔要包括的主要內容有：CBB整體介紹，包括功能描述和重要性能指標描述，限制條設計及應用關注點；CBB電路設計，包括原理圖和接口設計說明，關鍵接口設計要求等；CBB PCB設計指導，對于CBB電源、時鐘、散熱的設計要求都要重點說明；CBB對于軟件的設計說明，對于一些需要配置的接口要特別寫清楚。

等我成為硬件項目經理的時，我更加能體會到CBB的價值和問題，規劃好的CBB，對于設計效率，供應柔性，制造通用性幫助都很大。然而，我也體會到定義CBB也是一種“妥協”的結果，由于在資源、時間、成本等方面的限制，不同團隊的核心目標可能會和CBB建設的目標發生沖突。這時候就需要項目經理站出來，去平衡各方利益，堅持對團隊長期利益最優原則，說服大家使用CBB。

同時，我還希望大家多去思考并警惕過度CBB化給產品和團隊帶來的“負作用”。首先在產品設計中，由硬件CBB搭積木一樣組合一個單板讓硬件設計缺乏了很多美感，強行使用CBB導致有些設計很變扭，不得不進行妥協，硬件成本做不到極致。其次，CBB質量出問題會有蝴蝶效應，特別是核心CBB出問題對于產品就是災難，一個單點錯導致系列化的產品都出錯。2009年起豐田公司旗下的多款車型因加速踏板故障存在自動加速問題,導致多起傷亡，這個剎車門事件就是CBB應用的一個負面典型案例。最后，回到CBB對于硬件工程師的“負作用”，過多依賴CBB師硬件工程師失去了對產品每個關鍵模塊設計細節的控制力，由設計師變成了裝配工人，有空心化的風險，很難培養出18般武藝樣樣精通的高手。綜上，不論對于大公司，還是中小公司，硬件CBB都不是萬能的，我們在通過CBB獲益的同時也要預防CBB給我們帶來的問題。

審核編輯：劉清