前言

不止一次接手過(guò)復(fù)雜業(yè)務(wù)功能模塊，開(kāi)端總是深陷其中難以自拔，無(wú)數(shù)個(gè)深夜撫摸著頭皮在內(nèi)心暗暗咒罵。

相信你也有過(guò)類似的經(jīng)歷，面對(duì)復(fù)雜的業(yè)務(wù)邏輯，看代碼倆小時(shí)，寫代碼五分鐘，沒(méi)有點(diǎn)膽識(shí)和謀略都不敢下手。

最近總結(jié)復(fù)盤了一下，以備后用，如果有喜歡的同事想坑他一把，可以按照此方法實(shí)踐(不保證100%成功)，個(gè)人拙見(jiàn)，如有不當(dāng)望指正。

目錄

1. data屬性數(shù)量過(guò)多
2. 組件入?yún)?shù)量過(guò)多
3. mixins和業(yè)務(wù)代碼耦合
4. 不要封裝純函數(shù)
5. 數(shù)據(jù)結(jié)構(gòu)盡量復(fù)雜
6. 不寫注釋或?qū)憻o(wú)法理解的注釋
7. 將前端邏輯變重
8. 不封裝mixins與組件

正文

1、data屬性數(shù)量過(guò)多

要多用data屬性，放置一些用不到的key，讓屬性看起來(lái)更豐富，增加理解成本。

最好一打開(kāi)頁(yè)面前100行都是data屬性，讓維護(hù)或者參與該組件開(kāi)發(fā)的人員望而生畏，瞬間對(duì)組件肅然起敬。

這符合代碼的壞味道所描述的：

良藥與毒藥的區(qū)別在于劑量。有少量的全局?jǐn)?shù)據(jù)或許無(wú)妨，但數(shù)量越多，處理的難度就會(huì)指數(shù)上升。

如圖所示，效果更佳：

2、組件入?yún)?shù)量過(guò)多

data屬性的問(wèn)題是在一個(gè)組件內(nèi)，看多了加上注釋可能就理解，而組件增加過(guò)多的props入?yún)⑶『媚鼙苊膺@個(gè)問(wèn)題，過(guò)多的入?yún)⒖梢宰尷斫庾兊酶щy，要先理解父組件內(nèi)綁定的值是什么，再理解子組件內(nèi)的入?yún)⒂米鍪裁?/strong>。

當(dāng)然了，還有高階一點(diǎn)的用法，就是讓父組件的值和子組件的props名稱不一致，這樣做就更有趣了，難度陡增。

3、mixins與業(yè)務(wù)代碼耦合

合理封裝mixins能讓代碼變得更容易復(fù)用和理解，這不是我們想要的，讓mixins與業(yè)務(wù)組件的代碼耦合在一起，可以達(dá)到事倍功半的效果。

常規(guī)的做法是業(yè)務(wù)組件調(diào)用mixins的方法和變量，我們反其道而行之，讓mixins調(diào)用組件中的方法和變量，然后讓mixins多出引用，雖然看起來(lái)像mixins，但是并沒(méi)有mixins的功能，讓后期有心想抽離封裝的人也無(wú)從下手。

小Tips：常見(jiàn)的mixins方法會(huì)加上特殊前綴與組件方法區(qū)分，我們可以不使用這個(gè)規(guī)范，讓mixins方法更難被發(fā)現(xiàn)。

4、不要封裝純函數(shù)

如果有一個(gè)很重要的業(yè)務(wù)組件可讀性很差，勢(shì)必要小步快跑的迭代重構(gòu)，這種情況也不用怕，我們一個(gè)微小的習(xí)慣就可以讓這件事情變得困難重重，那就是不要封裝純函數(shù)方法。

純函數(shù)的好處是不引用其他變量，可以輕易的挪動(dòng)和替換； 讓每個(gè)方法盡量引用data屬性，當(dāng)他人想遷移或替換你的方法時(shí)，就要先理解引用的屬性和全局變量，再進(jìn)一步，可以在方法里再引入mixnins里的變量和方法，這個(gè)小習(xí)慣就會(huì)讓他們望而卻步。

5、數(shù)據(jù)結(jié)構(gòu)盡量復(fù)雜

讓數(shù)據(jù)結(jié)構(gòu)變復(fù)雜絕對(duì)是一個(gè)必殺技，數(shù)據(jù)結(jié)構(gòu)隨隨便便循環(huán)嵌套幾層，自己都能繞暈。

再加上一些騷操作，遞歸遍歷加一些判斷和刪減，寫上讓人難以琢磨的注釋，哪怕是高級(jí)工程師或是資深工程師都需要狠狠的磕上一段時(shí)間才能摸清真正的業(yè)務(wù)邏輯是什么。

這種方式還有另外一個(gè)優(yōu)點(diǎn)，就是自己可能也會(huì)被繞暈，一起陷入有趣的邏輯梳理游戲。

6、不寫注釋或?qū)憻o(wú)法理解的注釋

如果其他方式都復(fù)雜且耗時(shí)，那這種方法簡(jiǎn)直是高效的存在，只需要胡亂的寫一些讓別人看不懂或容易誤解的注釋，就可輕松把接手代碼的同事KO掉。

這個(gè)技能也看個(gè)人發(fā)揮的水平了，你也可以在注釋中恐嚇、勸阻參與開(kāi)發(fā)人員改動(dòng)功能代碼，煽動(dòng)開(kāi)發(fā)人員放棄修改，讓其內(nèi)心崩潰。

7、讓前端邏輯變重

良好的分層設(shè)計(jì)能夠讓系統(tǒng)變得簡(jiǎn)潔和健壯；為了凸顯前端的重要性，應(yīng)該將邏輯一股腦的承接到前端，讓前端邏輯變重，尤其是寫一些特殊的編碼配置和奇葩規(guī)則。

不要和產(chǎn)品、后端講述這件事情的不合理性，統(tǒng)統(tǒng)塞到前端，當(dāng)需求被重新討論時(shí)，他們會(huì)把特殊邏輯忘的一干二凈，而你可以根據(jù)代碼翻出一大堆，這樣你就顯得尤為重要了。

8、不封裝mixins與組件

如果要讓功能變得復(fù)雜，就不要拆分UI組件和業(yè)務(wù)組件，更不要按照業(yè)務(wù)抽離可復(fù)用的mixins方法，讓組件盡量大，輕則一兩千行，重則五六千行，不設(shè)上限，統(tǒng)統(tǒng)塞到一個(gè)組件里。

結(jié)尾

結(jié)合自己的踩坑經(jīng)歷寫了這邊偏筆記，調(diào)侃之處，純屬娛樂(lè)。你有沒(méi)有遇上過(guò)類似的場(chǎng)景，你的感受如何？又是如何解決的呢？敢不敢點(diǎn)個(gè)贊，一起評(píng)論區(qū)討論。