軟件模塊化設(shè)計(jì)是軟件工程領(lǐng)域的概念。本文結(jié)合筆者 ToB 產(chǎn)品設(shè)計(jì)的經(jīng)驗(yàn)，從產(chǎn)品經(jīng)理的角度談?wù)勈裁词擒浖K化設(shè)計(jì)，以及為何它被奉為產(chǎn)品設(shè)計(jì)的基本原則之一。

01 軟件模塊化設(shè)計(jì)，“偷懶”利器

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

業(yè)務(wù)方頻繁改動(dòng)需求令程序猿們很是頭疼，他們希望以最小的代碼改動(dòng)來(lái)實(shí)現(xiàn)業(yè)務(wù)方相要的效果；同時(shí)，當(dāng)業(yè)務(wù)方提出新需求時(shí)，盡量不去動(dòng)已經(jīng)寫(xiě)好的代碼……

基于以上實(shí)用性、高效率的工作需要，程序猿們創(chuàng)造一個(gè)“軟件模塊化設(shè)計(jì)”的概念：

把一個(gè)很大很復(fù)雜的系統(tǒng)，按照功用性，劃分成若干個(gè)模塊，每個(gè)模塊完成一個(gè)確定的功能；然后在這些模塊之間建立相應(yīng)的聯(lián)系（接口），通過(guò)模塊間的互相協(xié)作，最終實(shí)現(xiàn)業(yè)務(wù)方提出的需求。

舉個(gè)例子，對(duì)不懂技術(shù)的業(yè)務(wù)方來(lái)說(shuō)，上傳文件和上傳圖片是兩個(gè)完全不同的動(dòng)作，但對(duì)程序猿來(lái)說(shuō)，這兩個(gè)動(dòng)作其實(shí)可以抽象成一個(gè)行為（或功能）——“上傳”。這時(shí)，假如一個(gè)系統(tǒng)出現(xiàn)多處需要“上傳”功能的模塊，程序猿只需要把相應(yīng)的代碼復(fù)制過(guò)去，根據(jù)業(yè)務(wù)方需要做簡(jiǎn)單的修改即可，不必再重新編輯。

再比如一個(gè)商業(yè)分析模塊（BI），數(shù)據(jù)來(lái)源是財(cái)務(wù)系統(tǒng)和供應(yīng)鏈系統(tǒng)，那么開(kāi)發(fā)人員在做BI模塊時(shí)，只需要了解需要輸入什么數(shù)據(jù)、輸出什么類(lèi)型的圖表即可，完全不用考慮這些數(shù)據(jù)從哪來(lái)，有什么意義。

以上就是“軟件模塊化設(shè)計(jì)”在軟件開(kāi)發(fā)領(lǐng)域最實(shí)用的兩個(gè)意義，除此之外，還具有使系統(tǒng)結(jié)構(gòu)清晰、代碼簡(jiǎn)潔、良好擴(kuò)展性、便于分離、適應(yīng)業(yè)務(wù)變化等優(yōu)點(diǎn)。

產(chǎn)品經(jīng)理距離“軟件模塊化設(shè)計(jì)”最近的時(shí)候就是畫(huà)原型圖！比如Axure中的“母版”功能、“動(dòng)態(tài)面板”、“框架”、頁(yè)面分級(jí)編組、圖層編組等等，我們可以仔細(xì)想想每次使用這些控件時(shí)，都是出于什么目的：

• 母版：一處改動(dòng)，多處生效；
• 動(dòng)態(tài)面板：封裝控件，便于拖動(dòng)，交互效果互不干涉；
• 框架：對(duì)需要變動(dòng)部分的內(nèi)容進(jìn)行定向修改，不影響其他；
• 頁(yè)面分級(jí)編組：理清模塊、頁(yè)面間的層級(jí)關(guān)系；
• 圖層編組：封裝控件，便于編輯管理。

02 模塊化設(shè)計(jì)對(duì)產(chǎn)品經(jīng)理的幫助

產(chǎn)品經(jīng)理在互聯(lián)網(wǎng)時(shí)代以前，主要?dú)w屬于市場(chǎng)營(yíng)銷(xiāo)部，職能是快速響應(yīng)市場(chǎng)需要，對(duì)產(chǎn)品盈虧負(fù)責(zé)；軟件類(lèi)產(chǎn)品的設(shè)計(jì)工作直接由開(kāi)發(fā)部門(mén)負(fù)責(zé)。

進(jìn)入互聯(lián)網(wǎng)時(shí)代，尤其是移動(dòng)互聯(lián)網(wǎng)，產(chǎn)品版本迭代速度加快，開(kāi)發(fā)部門(mén)越來(lái)越需要一個(gè)專(zhuān)門(mén)負(fù)責(zé)解讀用戶(hù)需求、研究用戶(hù)體驗(yàn)，并將需求整理后傳遞給開(kāi)發(fā)人員的職能角色。產(chǎn)品經(jīng)理自此才逐漸成為互聯(lián)網(wǎng)行業(yè)的一個(gè)重要角色。

產(chǎn)品經(jīng)理與程序猿之間的這些淵源，決定了產(chǎn)品經(jīng)理需要了解一些類(lèi)似軟件架構(gòu)設(shè)計(jì)理念，或者是邏輯嚴(yán)謹(jǐn)?shù)乃伎挤绞?。一方面可以更友好、更?zhǔn)確地跟程序猿傳達(dá)設(shè)計(jì)要點(diǎn)；另一方面也能夠幫助自己處理“具象的、數(shù)量繁多的、無(wú)邏輯的、瑣碎的”用戶(hù)需求。

軟件模塊化設(shè)計(jì)有兩個(gè)很重要的步驟——?dú)w類(lèi)和抽象，完成了這兩步才能確定最終要做哪些模塊、哪些功能。

比如說(shuō)，單選題、多選題、判斷題同屬于客觀題，這叫歸類(lèi)；單選題是“擁有4個(gè)選項(xiàng)，答案唯一的題目”，多選題是“擁有4個(gè)選項(xiàng)，以“且”關(guān)系連接的多答案題目”，判斷題是“擁有2個(gè)固定選項(xiàng)，答案唯一的題目”，這叫抽象。

產(chǎn)品經(jīng)理在跟業(yè)務(wù)方溝通時(shí)，經(jīng)常會(huì)遇到各種各樣的專(zhuān)業(yè)名詞、行業(yè)限定下的特殊場(chǎng)景，這些名詞在業(yè)務(wù)場(chǎng)景中可能代表著不同的含義，但是在軟件開(kāi)發(fā)中卻可以用固定的、已有的簡(jiǎn)單名詞來(lái)表述。

對(duì)需求做歸類(lèi)和抽象，不僅僅是為了跟程序猿溝通，更重要的是幫助產(chǎn)品經(jīng)理認(rèn)識(shí)到需求的實(shí)質(zhì)，也使自己的設(shè)計(jì)工作“不要重復(fù)造輪子”。

對(duì)需求完成歸類(lèi)和抽象后，必然面對(duì)“如何聯(lián)系”這一問(wèn)題——模塊之間有無(wú)前后置關(guān)系，數(shù)據(jù)流向是怎樣的？

比如說(shuō)，經(jīng)過(guò)歸類(lèi)抽象，我們決定開(kāi)發(fā)“題庫(kù)管理”“試卷管理”“教學(xué)管理”三個(gè)產(chǎn)品模塊；這時(shí)就需要思考這三個(gè)模塊之間的關(guān)系：

• 沒(méi)有“題庫(kù)”，“試卷”不成立，但“教學(xué)”成立，所以“試卷”依賴(lài)“題庫(kù)”；
• 沒(méi)有“試卷”，“題庫(kù)”“教學(xué)”均成立，所以“題庫(kù)”“教學(xué)”獨(dú)立；
• 沒(méi)有“教學(xué)”，“題庫(kù)”“試卷”均成立……

經(jīng)過(guò)逐級(jí)演化，最終我們可以得出這三個(gè)模塊之間的關(guān)系圖譜。

經(jīng)過(guò)一系列歸類(lèi)、抽象和關(guān)系確定，我們可以得到一張UML用例圖、一張活動(dòng)圖，甚至狀態(tài)圖、時(shí)序圖和數(shù)據(jù)庫(kù)設(shè)計(jì)；這些流程圖相當(dāng)于一張標(biāo)注過(guò)路線的產(chǎn)品地圖，有了路線圖就可以直接進(jìn)入產(chǎn)品設(shè)計(jì)階段了（UML圖可以使程序猿直接進(jìn)入開(kāi)發(fā)階段，不一定非得等到原型圖出來(lái)）。

當(dāng)業(yè)務(wù)方提出需求變更時(shí)，我們可以對(duì)照這些圖例：哪些需求是原有需求的變種，哪些需求是真正的新增，這些需求是否在預(yù)期的開(kāi)發(fā)路線上，是否能夠在系統(tǒng)中實(shí)現(xiàn)，對(duì)系統(tǒng)的影響有多大……

總之，當(dāng)產(chǎn)品經(jīng)理對(duì)產(chǎn)品有了模塊化的概念化，會(huì)很輕松地應(yīng)對(duì)來(lái)自客戶(hù)的需求新增和變動(dòng)。

• 在軟件工程領(lǐng)域，模塊化設(shè)計(jì)的初衷是：使軟件不至于隨著逐漸變大而變得不可控，最終要達(dá)到可控、可維護(hù)、可擴(kuò)展的目的。
• 產(chǎn)品經(jīng)理學(xué)習(xí)模塊化設(shè)計(jì)的目的也是如此——使獲取到的需求可控、可維護(hù)、可擴(kuò)展，至少可以幫助我們快速評(píng)估出新需求在產(chǎn)品中所在的位置。

03 模塊化設(shè)計(jì)的5個(gè)顯著特征

前文通俗地還原了軟件模塊化設(shè)計(jì)的原貌，最后總結(jié)一下軟件模塊化設(shè)計(jì)的5個(gè)顯著特征：

1. 層次分明

可以簡(jiǎn)單理解為設(shè)計(jì)一個(gè)結(jié)構(gòu)合理的樹(shù)狀菜單。

2. 抽象與細(xì)分

抽象：只考慮要解決的問(wèn)題（用戶(hù)需求），不考慮實(shí)現(xiàn)方法；

細(xì)分：強(qiáng)調(diào)對(duì)需求的逐步分解，分解時(shí)僅較上一部分增加少量的細(xì)節(jié)。

例：

用戶(hù)想要實(shí)現(xiàn)在線報(bào)銷(xiāo)的功能，那我們就給他做一個(gè)“報(bào)銷(xiāo)軟件”，這個(gè)“報(bào)銷(xiāo)軟件”就是抽象出來(lái)的實(shí)體；

接下來(lái)要對(duì)“報(bào)銷(xiāo)軟件”進(jìn)行第一次分解：報(bào)銷(xiāo)信息填寫(xiě)、發(fā)票識(shí)別與驗(yàn)真、審批；

第二次分解“發(fā)票識(shí)別與驗(yàn)真”：發(fā)票信息錄入、發(fā)票真?zhèn)涡则?yàn)證、發(fā)票是否已用驗(yàn)證；

第三次分解“發(fā)票是否已用驗(yàn)證”：歷史已用發(fā)票查詢(xún)、歷史已用發(fā)票編號(hào)對(duì)比……

3. 組成獨(dú)立

在軟件工程領(lǐng)域也被成為“信息隱蔽”，意思是在設(shè)計(jì)和確定模塊時(shí)，使一個(gè)模塊內(nèi)包含信息（流程或數(shù)據(jù)），對(duì)于不需要這些信息的其他模塊來(lái)說(shuō)是不能訪問(wèn)的。

也就是說(shuō)，除了必要的接口，盡量減少模塊間、分系統(tǒng)、子系統(tǒng)間的邏輯依賴(lài)，這樣在后期維護(hù)升級(jí)時(shí)，就可以避免干涉其他不相關(guān)的部分。

例：

“報(bào)銷(xiāo)單”包含單據(jù)編號(hào)、單據(jù)類(lèi)型、單據(jù)金額、提交人、提交日期等信息，但“財(cái)務(wù)分析”模塊只需要用到單據(jù)金額、提交日期兩項(xiàng)數(shù)據(jù)，那么就只允許“財(cái)務(wù)分析”模塊通過(guò)接口調(diào)用的方式訪問(wèn)這兩項(xiàng)數(shù)據(jù)，其他數(shù)據(jù)一概不能訪問(wèn)。

4. 面向數(shù)據(jù)結(jié)構(gòu)（面向接口）

軟件系統(tǒng)一般由邏輯（算法）和信息兩部分構(gòu)成，信息又分為內(nèi)容和數(shù)據(jù)；邏輯是構(gòu)建軟件功能的骨架，內(nèi)容和數(shù)據(jù)是血肉，其中以數(shù)據(jù)尤為重要。

假如要實(shí)現(xiàn)軟件模塊化且模塊之間相互獨(dú)立，必須要先拋棄邏輯（實(shí)現(xiàn)方法），因?yàn)橛羞壿嬀痛磉@兩個(gè)模塊誰(shuí)也離不開(kāi)誰(shuí)，就不能稱(chēng)之為獨(dú)立。

如果這兩個(gè)模塊必須要關(guān)聯(lián)在一起，但又不允許它們?cè)谶壿嬌匣ハ喔缮?，那?strong>最好的辦法就是為它們內(nèi)部包含的數(shù)據(jù)進(jìn)行抽象化，形成標(biāo)準(zhǔn)化接口，以數(shù)據(jù)調(diào)用的形式實(shí)現(xiàn)兩個(gè)模塊間的互相協(xié)作。

5. 高內(nèi)聚，低耦合

這里要解釋一下，其實(shí)“高內(nèi)聚，低耦合”才是軟件開(kāi)發(fā)的內(nèi)在要求，“模塊化設(shè)計(jì)”只是實(shí)現(xiàn)“高內(nèi)聚，低耦合”的其中一種方法。

• “高內(nèi)聚”最精準(zhǔn)的體現(xiàn)是“面向?qū)ο箝_(kāi)發(fā)”，它的意思是從功能角度來(lái)衡量模塊間的聯(lián)系，也就是說(shuō)一個(gè)好的內(nèi)聚模塊應(yīng)當(dāng)只做一件事；
• “低耦合”的精準(zhǔn)體現(xiàn)是“面向接口開(kāi)發(fā)”，意思是從軟件結(jié)構(gòu)角度衡量各個(gè)模塊之間的聯(lián)系，耦合強(qiáng)弱取決于模塊間接口的復(fù)雜程度、進(jìn)入或訪問(wèn)一個(gè)模塊需要調(diào)用的接口數(shù)量和次數(shù)；極端的低耦合是不需要任何接口，但一般很少見(jiàn)。

“高內(nèi)聚，低耦合”是判斷軟件設(shè)計(jì)好壞很重要的一個(gè)標(biāo)準(zhǔn)，關(guān)于如何達(dá)到這一要求，本文不作重點(diǎn)介紹，大家可以自己查查資料簡(jiǎn)單了解一下。

04 兼顧考慮用戶(hù)體驗(yàn)和市場(chǎng)需求

模塊化設(shè)計(jì)并不只是為了提高軟件開(kāi)發(fā)效率、適應(yīng)快速變化，它在一定程度上也代表了最優(yōu)的用戶(hù)體驗(yàn)和市場(chǎng)需要。下面舉幾個(gè)例子：

• UE設(shè)計(jì)中有一個(gè)“就近原則”，就是對(duì)相關(guān)控件進(jìn)行直觀分組，創(chuàng)建一個(gè)更少混亂、更有組織的布局，使用戶(hù)在一個(gè)區(qū)域只進(jìn)行一類(lèi)操作。
• 頁(yè)面設(shè)計(jì)中的樹(shù)狀菜單和“面包屑”元素，代表著分層分級(jí)；
• 每個(gè)頁(yè)面只進(jìn)行固定的、少量的幾個(gè)相關(guān)性較強(qiáng)的功能操作，比每個(gè)頁(yè)面進(jìn)行很多個(gè)操作學(xué)習(xí)成本更低，更容易上手使用；
• B端客戶(hù)的定制化需要相對(duì)比較高，而ToB產(chǎn)品往往都做得又大又全，有的客戶(hù)可能僅僅只需要部分功能模塊，這時(shí)就需要為拆分后的功能模塊進(jìn)行單獨(dú)定價(jià)，最終報(bào)價(jià)按照客戶(hù)選用的模塊進(jìn)行匯總。
• 采用模塊化設(shè)計(jì)的軟件產(chǎn)品，可以結(jié)合客戶(hù)行業(yè)特點(diǎn)或公司產(chǎn)品規(guī)劃，針對(duì)性地對(duì)某個(gè)模塊進(jìn)行優(yōu)化升級(jí)，使之單獨(dú)成為一款產(chǎn)品參與市場(chǎng)競(jìng)爭(zhēng)，并且不會(huì)對(duì)原系統(tǒng)造成影響。

作者：產(chǎn)品路漫漫；微信公眾號(hào)：產(chǎn)品路漫漫

本文由 @產(chǎn)品路漫漫 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議