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

為什么要模塊化？

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

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

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

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

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

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

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

實(shí)際項(xiàng)目開發(fā)中，用模塊的時候，項(xiàng)目的進(jìn)度真的加快了么？時間真的節(jié)省了么？

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

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

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

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

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

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

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

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

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

或者換一種說法：

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

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

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

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

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

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

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

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

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

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

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

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

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

責(zé)任編輯：xj

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

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