軟件模塊化設計是軟件工程領域的概念。本文結合筆者 ToB 產品設計的經驗，從產品經理的角度談談什么是軟件模塊化設計，以及為何它被奉為產品設計的基本原則之一。

01 軟件模塊化設計，“偷懶”利器

為了提升寫作效率，幾乎任何一款編輯器都少不了“復制”“粘貼”這兩個功能，對于需要編輯冗長代碼的軟件開發人員更是如此。但程序猿們并不滿足于此，他們創建了一種開源社區，從而可以“復制”其他人共享的代碼，他們把這種共享的理念叫做“不要重復造輪子”。

業務方頻繁改動需求令程序猿們很是頭疼，他們希望以最小的代碼改動來實現業務方相要的效果；同時，當業務方提出新需求時，盡量不去動已經寫好的代碼……

基于以上實用性、高效率的工作需要，程序猿們創造一個“軟件模塊化設計”的概念：

把一個很大很復雜的系統，按照功用性，劃分成若干個模塊，每個模塊完成一個確定的功能；然后在這些模塊之間建立相應的聯系（接口），通過模塊間的互相協作，最終實現業務方提出的需求。

舉個例子，對不懂技術的業務方來說，上傳文件和上傳圖片是兩個完全不同的動作，但對程序猿來說，這兩個動作其實可以抽象成一個行為（或功能）——“上傳”。這時，假如一個系統出現多處需要“上傳”功能的模塊，程序猿只需要把相應的代碼復制過去，根據業務方需要做簡單的修改即可，不必再重新編輯。

再比如一個商業分析模塊（BI），數據來源是財務系統和供應鏈系統，那么開發人員在做BI模塊時，只需要了解需要輸入什么數據、輸出什么類型的圖表即可，完全不用考慮這些數據從哪來，有什么意義。

以上就是“軟件模塊化設計”在軟件開發領域最實用的兩個意義，除此之外，還具有使系統結構清晰、代碼簡潔、良好擴展性、便于分離、適應業務變化等優點。

產品經理距離“軟件模塊化設計”最近的時候就是畫原型圖！比如Axure中的“母版”功能、“動態面板”、“框架”、頁面分級編組、圖層編組等等，我們可以仔細想想每次使用這些控件時，都是出于什么目的：

• 母版：一處改動，多處生效；
• 動態面板：封裝控件，便于拖動，交互效果互不干涉；
• 框架：對需要變動部分的內容進行定向修改，不影響其他；
• 頁面分級編組：理清模塊、頁面間的層級關系；
• 圖層編組：封裝控件，便于編輯管理。

02 模塊化設計對產品經理的幫助

產品經理在互聯網時代以前，主要歸屬于市場營銷部，職能是快速響應市場需要，對產品盈虧負責；軟件類產品的設計工作直接由開發部門負責。

進入互聯網時代，尤其是移動互聯網，產品版本迭代速度加快，開發部門越來越需要一個專門負責解讀用戶需求、研究用戶體驗，并將需求整理后傳遞給開發人員的職能角色。產品經理自此才逐漸成為互聯網行業的一個重要角色。

產品經理與程序猿之間的這些淵源，決定了產品經理需要了解一些類似軟件架構設計理念，或者是邏輯嚴謹的思考方式。一方面可以更友好、更準確地跟程序猿傳達設計要點；另一方面也能夠幫助自己處理“具象的、數量繁多的、無邏輯的、瑣碎的”用戶需求。

軟件模塊化設計有兩個很重要的步驟——歸類和抽象，完成了這兩步才能確定最終要做哪些模塊、哪些功能。

比如說，單選題、多選題、判斷題同屬于客觀題，這叫歸類；單選題是“擁有4個選項，答案唯一的題目”，多選題是“擁有4個選項，以“且”關系連接的多答案題目”，判斷題是“擁有2個固定選項，答案唯一的題目”，這叫抽象。

產品經理在跟業務方溝通時，經常會遇到各種各樣的專業名詞、行業限定下的特殊場景，這些名詞在業務場景中可能代表著不同的含義，但是在軟件開發中卻可以用固定的、已有的簡單名詞來表述。

對需求做歸類和抽象，不僅僅是為了跟程序猿溝通，更重要的是幫助產品經理認識到需求的實質，也使自己的設計工作“不要重復造輪子”。

對需求完成歸類和抽象后，必然面對“如何聯系”這一問題——模塊之間有無前后置關系，數據流向是怎樣的？

比如說，經過歸類抽象，我們決定開發“題庫管理”“試卷管理”“教學管理”三個產品模塊；這時就需要思考這三個模塊之間的關系：

• 沒有“題庫”，“試卷”不成立，但“教學”成立，所以“試卷”依賴“題庫”；
• 沒有“試卷”，“題庫”“教學”均成立，所以“題庫”“教學”獨立；
• 沒有“教學”，“題庫”“試卷”均成立……

經過逐級演化，最終我們可以得出這三個模塊之間的關系圖譜。

經過一系列歸類、抽象和關系確定，我們可以得到一張UML用例圖、一張活動圖，甚至狀態圖、時序圖和數據庫設計；這些流程圖相當于一張標注過路線的產品地圖，有了路線圖就可以直接進入產品設計階段了（UML圖可以使程序猿直接進入開發階段，不一定非得等到原型圖出來）。

當業務方提出需求變更時，我們可以對照這些圖例：哪些需求是原有需求的變種，哪些需求是真正的新增，這些需求是否在預期的開發路線上，是否能夠在系統中實現，對系統的影響有多大……

總之，當產品經理對產品有了模塊化的概念化，會很輕松地應對來自客戶的需求新增和變動。

• 在軟件工程領域，模塊化設計的初衷是：使軟件不至于隨著逐漸變大而變得不可控，最終要達到可控、可維護、可擴展的目的。
• 產品經理學習模塊化設計的目的也是如此——使獲取到的需求可控、可維護、可擴展，至少可以幫助我們快速評估出新需求在產品中所在的位置。

03 模塊化設計的5個顯著特征

前文通俗地還原了軟件模塊化設計的原貌，最后總結一下軟件模塊化設計的5個顯著特征：

1. 層次分明

可以簡單理解為設計一個結構合理的樹狀菜單。

2. 抽象與細分

抽象：只考慮要解決的問題（用戶需求），不考慮實現方法；

細分：強調對需求的逐步分解，分解時僅較上一部分增加少量的細節。

例：

用戶想要實現在線報銷的功能，那我們就給他做一個“報銷軟件”，這個“報銷軟件”就是抽象出來的實體；

接下來要對“報銷軟件”進行第一次分解：報銷信息填寫、發票識別與驗真、審批；

第二次分解“發票識別與驗真”：發票信息錄入、發票真偽性驗證、發票是否已用驗證；

第三次分解“發票是否已用驗證”：歷史已用發票查詢、歷史已用發票編號對比……

3. 組成獨立

在軟件工程領域也被成為“信息隱蔽”，意思是在設計和確定模塊時，使一個模塊內包含信息（流程或數據），對于不需要這些信息的其他模塊來說是不能訪問的。

也就是說，除了必要的接口，盡量減少模塊間、分系統、子系統間的邏輯依賴，這樣在后期維護升級時，就可以避免干涉其他不相關的部分。

例：

“報銷單”包含單據編號、單據類型、單據金額、提交人、提交日期等信息，但“財務分析”模塊只需要用到單據金額、提交日期兩項數據，那么就只允許“財務分析”模塊通過接口調用的方式訪問這兩項數據，其他數據一概不能訪問。

4. 面向數據結構（面向接口）

軟件系統一般由邏輯（算法）和信息兩部分構成，信息又分為內容和數據；邏輯是構建軟件功能的骨架，內容和數據是血肉，其中以數據尤為重要。

假如要實現軟件模塊化且模塊之間相互獨立，必須要先拋棄邏輯（實現方法），因為有邏輯就代表這兩個模塊誰也離不開誰，就不能稱之為獨立。

如果這兩個模塊必須要關聯在一起，但又不允許它們在邏輯上互相干涉，那么最好的辦法就是為它們內部包含的數據進行抽象化，形成標準化接口，以數據調用的形式實現兩個模塊間的互相協作。

5. 高內聚，低耦合

這里要解釋一下，其實“高內聚，低耦合”才是軟件開發的內在要求，“模塊化設計”只是實現“高內聚，低耦合”的其中一種方法。

• “高內聚”最精準的體現是“面向對象開發”，它的意思是從功能角度來衡量模塊間的聯系，也就是說一個好的內聚模塊應當只做一件事；
• “低耦合”的精準體現是“面向接口開發”，意思是從軟件結構角度衡量各個模塊之間的聯系，耦合強弱取決于模塊間接口的復雜程度、進入或訪問一個模塊需要調用的接口數量和次數；極端的低耦合是不需要任何接口，但一般很少見。

“高內聚，低耦合”是判斷軟件設計好壞很重要的一個標準，關于如何達到這一要求，本文不作重點介紹，大家可以自己查查資料簡單了解一下。

04 兼顧考慮用戶體驗和市場需求

模塊化設計并不只是為了提高軟件開發效率、適應快速變化，它在一定程度上也代表了最優的用戶體驗和市場需要。下面舉幾個例子：

• UE設計中有一個“就近原則”，就是對相關控件進行直觀分組，創建一個更少混亂、更有組織的布局，使用戶在一個區域只進行一類操作。
• 頁面設計中的樹狀菜單和“面包屑”元素，代表著分層分級；
• 每個頁面只進行固定的、少量的幾個相關性較強的功能操作，比每個頁面進行很多個操作學習成本更低，更容易上手使用；
• B端客戶的定制化需要相對比較高，而ToB產品往往都做得又大又全，有的客戶可能僅僅只需要部分功能模塊，這時就需要為拆分后的功能模塊進行單獨定價，最終報價按照客戶選用的模塊進行匯總。
• 采用模塊化設計的軟件產品，可以結合客戶行業特點或公司產品規劃，針對性地對某個模塊進行優化升級，使之單獨成為一款產品參與市場競爭，并且不會對原系統造成影響。

作者：產品路漫漫；微信公眾號：產品路漫漫

本文由 @產品路漫漫 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議