我所了解的前端工程化

背景與沖突

回顧前端的發展歷史,大約在 10 年前,前端工程師的日常工作是切圖,把前端三劍客: HTML、 CSS 、JavaScript 學完后基本能快速的上手,且數據依賴于后端等,在當時甚至是現在部分人的印象里,前端開發是一個工作較簡單、難度較低的職位,換種說法就是,前端開發職位關注度很低。而 2009 年Nodejs 的橫空出世,前端的關注度越來越高,前端的價值已經可以與后端并肩甚至超越,可以說開始搶占后端市場了,對于前端而言,是一個崛起的時刻,同時與之而來也帶來了一些問題,前端的規模越來越大,職責范疇越來越大,工程也逐漸復雜化,上升到了工程學的問題,那么如何高效的進行團隊協作,如何提高團隊的開發效率,如何降低項目的維護成本等等?因此,前端工程化的思想應運而生,前端開發開始需要工程化、組件化、模塊化、規范化、自動化來更好幫助我們更好的協作完成一個工程,提高項目質量,提高可維護性。

什么是前端工程化

根據業務的特點,將前端標準化、組件化、模塊化、規范化、自動化,包括了開發流程,技術選型,代發規范,測試、構建發布,監控、性能優化、重構等,用于提升前端工程師的開發效率和代碼質量,降低項目維護成本等一系列問題。

換句話說,一切以提高開發效率、降低項目維護成本、保證質量為目的的手段都可稱之為工程化,以及一切重復的工作都應該被自動化。

如何實現前端工程化

任何一個軟件工程大致分為 :開發-測試-部署。

在前端工程中,每一環節又涵蓋了很多的細節,如:如何統一編碼規范;如何使用模塊化、組件化,如何解決重復的機械化工作;如何統一代碼風格,保證質量;前后端如何更好的協作,前端不再依賴后端項目等等,即從前端工程的每一個環節中,我們都能針對具體的工作細節去做對應的工程化工作,那如何在各個環節去實現工程化,大致可以從4 個維度去思考:文件上的模塊化、組件上的組件化,讓組件得以復用,行為標準上的規范化,重復性的機械化工作的自動化。

前端模塊化

高內聚,低耦合:判斷代碼好壞的重要指標。
高內聚:指一個函數盡量只做一件事
低耦合:指兩個模塊之間的關聯程度低

模塊化是定義在文件上。

對代碼和資源的劃分,將一個系統按照一定的規則規范分解封裝為更小的文模塊(文件)并組合一起,向外暴露一些方法與外部其他模塊通信,模塊之間作用域相互隔離互不干擾,一個模塊即一個功能,可被多次復用,不僅能解決命名沖突從而減少命名空間污染,更好的分離,按需加載,實現更高的復用性和高可維護性。

模塊化思想體現了分而治之的思想(把一個復雜的問題分成兩個或更多的相同或相似的子問題,直到最后子問題可以簡單的直接求解,原問題的解即子問題的解的合并)。
比如一個實現 x 功能的js代碼,其他功能的實現也用到這個 JS 功能代碼,可以把這個功能看做為一個模塊使用了一定的規范進行模塊化的實現。

JS 中模塊化方案有很多,在不同時間的模塊化方案的產物里,目前對于編碼來說主流的方案只有兩種:從 ES6 起官方規范自帶的方案 ES module,以及Node.js 使用的方案CommonJS。而二者差別主要區別于,語法上前者使用 import 和 export.default 來加載和暴露,后者使用的是require 和modules.exports。

前端組件化

組件化是定義在設計上,對 UI 的拆分,可分為業務組件,和公共組件;顧名思義,業務組件即與業務有關的組件,如系統有多處修改用戶信息的彈框(舉例而已,一個系統修改用戶信息的入口體驗一般在用戶管理),我們可將這個彈框封裝為一個業務組件供使用時按需引入復用;公共組件即是與業務無關且可直接使用的組件,如一般按鈕,確定按鈕、取消按鈕等。組件化即是將多處實現同樣的功能的UI 進行封裝為可按需加載的可復用的組件。

組件化也是體現了“分而治之”的思想,如一個頁面可由導航、側邊欄,底部等多個組件組成,每個組件又可拆解為多個組件組成

目前主流組件化框架很多,有 Vue、React、Angular。

前端規范化

規范化是定義在一種行為標準上。
團隊多人協作時需要明確統一的標準來約束大家的一些行為,因為不同的人都有不同的編碼習慣、文檔習慣、提交日志習慣等,統一的規范可以促進團隊之間的協作、降低項目維護成本等。項目初期制定的規范的質量,影響后期團隊里開發者之間的協作、項目質量、以及項目維護的成本等。

常見的規范有:
目錄結構的規范、
組件規范、
編碼規范,包括HTML規范、CSS 規范、JS 規范、圖片規范、命名規范等
文檔規范、
Git協作規范,包括分支、commit 描述等。
前后端接口規范等,包括規范原則,如響應數據格式、響應格式,、響應Code等等、

至今已經有很多工具可以幫助實現規范化,如一些主流的 Lint 工具 , ESLint 工具來規范編碼風格,具體可詳細參考官方文檔

前端自動化

自動化定義在一些重復性的行為上。
一切重復的機械化工作都應該被自動化,讓機器完成任何簡單重復的工作

也有很多的自動化工具幫助我們實現自動化,如:
自動化構建、自動化部署、自動化測試等等。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,505評論 6 533
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,556評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,463評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,009評論 1 312
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,778評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,218評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,281評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,436評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,969評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,795評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,993評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,537評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,229評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,659評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,917評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,687評論 3 392
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,990評論 2 374