對很多人來，嵌入式軟件開發(fā)過程中模塊化（Modularization）是一個海市蜃樓、是一個書面詞匯、是一個過氣的時尚——模塊化似乎從未真正的實現(xiàn)過。吹牛時人們常不屑的說：沒吃過豬肉，但還沒看過豬跑么？事實上，如果討論的對象是嵌入式軟件，很多人可能真的沒有看過豬跑。在話題變得更像都市傳說的之前，我想問一個問題：

為什么要模塊化？

有經(jīng)驗的人會說：

為了代碼復(fù)用（Code Reuse）

進一步——“為什么模塊化可以實現(xiàn)代碼復(fù)用呢？”很多人會說：

你這不是抬杠嗎？明擺著的，代碼做成了模塊，那么別的項目就可以直接使用了，模塊里的這部分代碼就得到了復(fù)用。

更進一步——“代碼復(fù)用又是為了什么呢？”聽到這里項目經(jīng)理們深吸了最后一口煙屁股，順手丟到腳邊、踩滅、起身準(zhǔn)備離開：

代碼復(fù)用可以節(jié)省開發(fā)時間，加快項目研發(fā)速度。

為了把嘴邊的那句“你們慢慢聊，我還有事”噎回去，我們再問一個問題：

實際項目開發(fā)中，用模塊的時候，項目的進度真的加快了么？時間真的節(jié)省了么？

項目經(jīng)理們不動了，抬起到半空中的屁股慢慢的坐了下來。這次，他們的語氣是認(rèn)真的：

不，使用模塊通常并不一定能加快項目進度。老實說，用別人的模塊，程序員常常要認(rèn)真理解模塊的功能和代碼才能在調(diào)試的時候確認(rèn)問題的范圍。你知道，很多時候看懂他人代碼所用的時間比自己重新設(shè)計一個更長。

周圍不少程序員都投來贊同的眼光，有的甚至很認(rèn)真的點了點頭。實際上，這里我們已經(jīng)發(fā)現(xiàn)，在實踐中，拋開用于模塊化的技術(shù)不談，使用模塊實現(xiàn)代碼復(fù)用本身往往并不能加快一個團隊的開發(fā)速度——那么我們要模塊化做什么？

下結(jié)論還為時尚早。從項目經(jīng)理們的描述可以看出：

代碼復(fù)用的目的或者說動機是節(jié)省開發(fā)時間

實際執(zhí)行中，程序員因為種種原因，在使用模塊時總是要花費大量時間讀懂了代碼才能“放心地”去使用它。

程序（軟件）是“程序員嘗試去固化的自己的思維”；而模塊（硬件）則是“業(yè)已固化的邏輯”，讀懂一段程序，實際上就是要通過死的代碼邏輯去反推模塊構(gòu)作者的思維，這是一個逆向過程，這是一個人與人之間用代碼進行間接交流的過程，當(dāng)邏輯本身較為復(fù)雜時，顯然比將自己的思維直接翻譯成程序（重新開發(fā)一個）更為困難。

通過上面的分析，很容易看出，模塊化就是為了通過復(fù)用代碼來加快開發(fā)速度，而正是程序員閱讀要復(fù)用的代碼讓這一努力付之東流。由此，我們可以非常直接的得出結(jié)論：

使用模塊時，必須阻止程序員閱讀要復(fù)用的代碼

或者換一種說法：

使用模塊時，必須專注于模塊的使用，而必須有意忽視模塊的實現(xiàn)邏輯，必須要在心理上信任模塊。簡而言之，必須把模塊視作黑盒子！

很容易發(fā)現(xiàn)，上面的結(jié)論是站在項目經(jīng)理的視角得出的，因為項目經(jīng)理關(guān)注的是項目本身，是各類資源的合理利用，是項目的進度——項目經(jīng)理唯一不需要也不應(yīng)該關(guān)注的是具體的技術(shù)實現(xiàn)細(xì)節(jié)。那么從第一線程序員的視角來看這個問題：

為什么程序員要閱讀模塊的代碼實現(xiàn)呢？

筆者問過不同從業(yè)時間/經(jīng)驗的程序員，從過來的的角度來看，無非是以下幾個原因：

學(xué)習(xí)目的——想知道別人是怎么實現(xiàn)的。很多程序員認(rèn)為通過閱讀別人的代碼能夠快速的學(xué)習(xí)他人的經(jīng)驗從而提升自己。 然而，從項目管理的角度來看這個問題，程序員利用業(yè)余時間閱讀他人的代碼來提升自己無可厚非，或者說是值得提倡的，但犧牲寶貴的項目時間來閱讀模塊的實現(xiàn)代碼而不是專注于模塊的使用（使用模塊快速的實現(xiàn)項目所需的功能），這對項目本身是弊遠(yuǎn)大于利的——閱讀代碼帶來的是程序員的能力提升，這是對團隊來說的遠(yuǎn)期利好，但這一利好對項目本身的時效性卻微乎其微——俗話說遠(yuǎn)水不解近渴就是這個意思。

實際上，項目經(jīng)理通常要根據(jù)程序員的已有能力來分配任務(wù)，而不會寄希望于程序員通過閱讀模塊代碼獲得提升以后再來回報眼前這個火燒眉毛的項目——如果真有項目經(jīng)理這么做了，那只能說，進度慢了完全不是程序員閱讀模塊代碼的錯，而是他最直接的用人問題——我也只能相信，也許他真的無人可用了。 所以結(jié)論就是：嚴(yán)禁工作時間以學(xué)習(xí)為目的閱讀模塊源代碼。

調(diào)試目的——也許并非所有的程序員都對自己的代碼質(zhì)量天然的自信，但幾乎所有的程序員都對別人寫的代碼（模塊）天然的不放心——就像孔乙己一樣，必須親眼看了酒保從黃酒壇子里舀出酒來而沒有摻水才放心——所以程序出了問題，必然要懷疑模塊，而且甚至有很多不負(fù)責(zé)任的程序員天然的會首先懷疑模塊——不是自己寫的，怎么能放心——所以調(diào)試的時候必然：

要有源代碼，否則就不會調(diào)試了

必然要閱讀模塊的代碼，否則就不知道究竟這個源代碼是不是對的

必然要讀懂模塊的代碼，否則怎么能體“自己的程序出錯完全是模塊的代碼寫的不好”。

對于這種情況，就我個人來說，只有一條準(zhǔn)則——不提供源代碼！只提供庫文件——相信我，通常面對匯編代碼熟手無策的程序員會在調(diào)試的時候自動忽視模塊的實現(xiàn)細(xì)節(jié)，專注于模塊接口的輸入輸出行為——給什么輸入，期望什么輸出，實際獲得什么輸出——一目了然，簡單直接。如果真的期望輸出和觀察到的實際輸出不同，問題也就找到了：要么是文檔沒有讀好，對輸入輸出的理解有誤；要么是輸入就有錯；要么就是模塊有問題。這絕對比讀懂源代碼以后再來調(diào)試要快得多！——除非這個別人寫的模塊需要你來維護……所以說，調(diào)試的時候 根！本！不！需！要！讀！模！塊！的！源！代！碼！ 根！本！不！需！要！讀！模！塊！的！源！代！碼！ 根！本！不！需！要！讀！模！塊！的！源！代！碼！以調(diào)試作為閱讀模塊的源代碼的理由，根本就站不住腳！

仿制目的——這個目的沒啥好說，別人把源代碼給你就是個錯誤。請大家自覺抵制無視他人知識產(chǎn)權(quán)的行為。從技術(shù)上來說，因為要實現(xiàn)自己的版本而需要閱讀他人的實現(xiàn)，理解他人的思維，這是一種白盒子行為，因而并不屬于正常使用模塊的范疇，屬于普通的開發(fā)范疇。

既然在模塊的使用過程中，無論是學(xué)習(xí)目的還是調(diào)試目的都不需要閱模塊的源代碼，那么可以明確的得出結(jié)論：程序員在使用模塊的過程中完全不需要，也不應(yīng)該浪費項目的時間來閱讀源代碼。一個團隊只有做到了這一點，才能借助代碼復(fù)用加快項目開發(fā)的速度。 當(dāng)一個團隊的項目經(jīng)理理解了“閱讀模塊代碼”對項目的巨大危害，并以制度的形式對程序員的這一行為予以了制止——移除了模塊化實踐的絆腳石；那么技術(shù)經(jīng)理應(yīng)該如何理解、設(shè)計和實踐適合于當(dāng)前團隊和項目需求的模塊化架構(gòu)呢？

責(zé)任編輯：xj

原文標(biāo)題：嵌入式為什么要編程模塊化和代碼復(fù)用？很多人都沒真正理解！

文章出處：【微信公眾號：嵌入式ARM】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。