前言

最近幾年前端發(fā)展的非?？?，SPA的繁榮讓前端的工程化也越來越重。在很多場景下，前端的復雜度和難度也早已經(jīng)超過了后端。但快速的發(fā)展下，前端也逐漸暴露出了許多問題。眾所周知，前端從業(yè)人員很少談程序的設計原則或設計思想。設計模式也頂多是在八股面試時千篇一律的問答“觀察者模式”和“發(fā)布訂閱者模式”?！皟?nèi)聚”和“解耦”這樣的詞語也很少從前端嘴里蹦出。這就難免導致前端代碼寫成一座大屎山。而這還是在基于類MVVM框架開發(fā)模式的前提下，前端代碼天然具有了組件級別的抽象，如果是刀耕火種的MVC時代，更是難以想象。

同事負責的一個前端項目頻頻爆出bug，已經(jīng)到了修1個bug產(chǎn)生3個bug的程度，甚至很多bug無法定位。問了同事原因，回答項目比較復雜。竊以為項目復雜不是寫成屎山的理由（舉一個極端的例子，你的項目再難再復雜也不會超過Chrome瀏覽器，那如果Chrome瀏覽器項目可以被維護的非常得體，難度更低的項目一定也能找到好的技術方案和架構來應對。）。出于好奇大致瀏覽了這個項目的代碼，發(fā)現(xiàn)這就是一座典型的前端大屎山。除了作者本人應該沒有任何人可以或愿意接住該項目，未來的命運就只能是招個新人從0開始重構，甚至一行代碼都沒法參考（我經(jīng)歷過這事?。?。

純粹從編寫軟件的角度，其實目前有很多成熟的代碼規(guī)范可以參考，甚至規(guī)范到變量命名等等。但這里我們暫且只討論前端這個領域的屎山堆積技巧。

精華教程

• 拒絕Ts

堅決不用Ts，甚至將Ts寫的項目重構成Js代碼。去年我被空降了一個leader（多年前就是阿里P7級別）。在看了一眼我維護的富文本編輯器項目之后，告訴我需要重構該項目，重構目標是拋棄Ts，用Js重寫。我在糾結了好幾天之后，做出了一個艱難的決定。。。

• 拒絕hooks

所有組件都用Class組件，拒絕函數(shù)組件，拒絕hooks。

• 全面擁抱狀態(tài)管理器

所有狀態(tài)都通過類似Redux或Mobx等狀態(tài)管理器去管理。

• 不做模塊抽象和復用

每個功能都從0開始實現(xiàn)，不抽象任何公共組件，不把高頻出現(xiàn)的邏輯抽象成hooks，不抽象出工具函數(shù)，堅決不復用任何邏輯。

• 把JSX結構掰開揉碎

直接在JSX上寫長函數(shù)和復雜參數(shù)，至少需要達到一眼看上去稀碎，完全無法在腦中構建出頁面的樣子。

• 編寫長長長長長的組件

一整個頁面只編寫1個組件去維護，單個組件代碼行數(shù)輕松寫到1000行以上。

• 父子組件多傳參，盡可能多層傳遞

父組件給子組件傳非常多參數(shù)，然后子組件繼續(xù)又將這些參數(shù)層層往下傳遞。

• 單文件開發(fā)

將狀態(tài)、數(shù)據(jù)、類型、工具函數(shù)、網(wǎng)絡請求和組件等等全部放入一個文件中。

• 打破文件組織結構與組件結構關系

雖然組件天然是一個多叉樹結構，但相應的文件全部平鋪到1層。

• 不封裝網(wǎng)絡請求函數(shù)

每次請求都創(chuàng)建新的Axios實例，網(wǎng)絡請求錯誤不統(tǒng)一攔截，全部單獨catch。

• 樣式混用和強行覆蓋

內(nèi)聯(lián)樣式與css文件樣式混用和覆蓋。類名隨便起，不要透露結構信息，相同的css代碼在各個類上直接復制黏貼一份。遇到?jīng)_突的樣式強行再覆蓋一層。

• 到處修改UI組件庫內(nèi)部樣式

為了達到設計要求，通過導出類名強行覆蓋UI組件庫的內(nèi)部css樣式，多用!important魔法。

• 多用Js代替CSS實現(xiàn)效果

偽類偽元素等堅決不用，動畫過渡等效果也必須通過Js實現(xiàn)。

• 到處使用微前端

盡可能的把頁面拆成一個個單一功能的微前端應用。

• 不要argue需求

對于產(chǎn)品或設計給到的需求全盤接受，盡力實現(xiàn)交互復雜混亂繁冗的功能，獲得技術成就感，做一只不挑食的小白兔。

• 評論區(qū)補充xdm看家絕技，聞者落淚