前端架构之路(3) - 前端开发规范
前端開發規范
1. 為什么需要 “前端開發規范”
規范不是強制性的,對代碼的編寫和程序的運行不會有致命的問題,但是沒有規范會有一系列的問題,比如:
- 缺乏規范,第一個問題就是團隊編碼風格不一,增加了成員之間代碼的閱讀成本,加大了團隊協作成本和維護成本;
- 隨著團隊人員的變化(多人開發一個應用,或者應用更換開發人員),如果缺乏規范,項目可能會變得一團糟,甚至失控;
- 即便是個人開發,規范也是需要的,當把項目轉給其他人的時候,如果有規范的話,會大大降低閱讀成本。
- …
所以,建立一套適合團隊的開發規范是很受用的。
2. 開發規范分類
這里不涉及工作流程規范,因為每個團隊的工作流程都不一樣,這是跟公司相關的,與開發沒有太大關系。一般來說,有以下幾類規范:
- 編碼規范
- 項目結構規范
- 框架、工具規范
- 其他約定
2.1 編碼規范
html: 主要有縮進,標簽,加載順序等等。可以參考:
- Code Guide
css:主要有縮進,換行,引號,注釋等等。可以參考:
- idiomatic-css
js:主要有縮進,換行,變量名稱,括號,文檔注釋等等。可以參考:
- airbnb js style
- google js style
- idiomatic js style
- standard js style
其實,我一般參考的是 Code Guide
2.2 項目結構規范
項目結構規范包括文件、目錄命名規范,模塊化分組規范,組件化規范等等,這些規范有些是構建工具要求的,有些是團隊自己定的。
以下是一些示例:
命名規范:參考 Code Guide
- 全部采用小寫方式, 以下劃線分隔。例:my_project_name
- 完整英文命名的用復數形式,縮寫用單數形式。例:scripts, js, styles, css, images, img
模塊化分組規范:以 lila 構建工具為例
- /project/src/home/: home 頁的工作空間(以下所有文件或目錄都在這個目錄下)
- index.html: html 入口文件
- index.js: js 入口文件
- index.(css|less|scss): 樣式入口文件
- js/: js 文件目錄
- js/ajax/: 對 ajax 封裝的目錄
- js/util/: 工具類函數的目錄
- js/pages/: spa 應用頁面目錄
- js/data/: 靜態數據目錄
- js/tpl/: 模板目錄
- js/(event|view)/: 事件監聽文件目錄
- …
- data/: 本地 json 數據模擬
- (css|less|scss)/: 樣式文件目錄
- images/: 圖片文件目錄
- components/: 組件目錄(如果基于 react, vue 等組件化框架)
- …
- 組件化規范:這里的組件化并不是指在代碼、框架層面的組件化,而是在架構和規范層面的組件化
- /project/src/component/hello/: hello 組件的工作空間(以下所有文件或目錄都在這個目錄下)
- README.md: 組件的說明,包括功能介紹、api 文檔、一些用例等等
- index.js: 組件的入口文件,調用組件將使用如下的方式(如果有樣式文件,則要在 js 中加載)
- commonjs: const hello = require('component/hello')
- es6: import hello from 'component/hello'
- demo/:用例目錄
- …
2.3 框架、工具規范
框架和 UI 庫
- 在技術上,每個團隊都有框架選型,都遵循一定的規范協作。基本上從團隊搭建之初便需要定下今后團隊的技術選型,并且最好不要更改選定好的框架和 UI 庫,因為不同的框架、不同的 UI 庫一般相互之間是不兼容的;同時用多個框架或 UI 庫也是要盡量避免的;
- 框架選型:經典的 jquery + bootstrap,比較現代化的 react + ant-design|material-ui|Semantic-UI (因為我主要是以 react 為組件庫做開發,所以對 vue 的技術選型不是很了解,>_<)
構建工具
構建工具的使用使開發變得極為便利和高效,工具在提升工作效率的同時,也同時提供了約束團隊編碼規范、項目結構規范等的可能性。
- eslint:一個語法規則和代碼風格的檢查工具,可以用來保證寫出語法正確、風格統一的代碼。
- stylelint:一個強大和現代的 CSS 審查工具,有助于開發者推行統一的代碼規范,避免樣式錯誤。
- csslint:與 stylelint 類似
約束項目結構規范需要團隊討論來定,但基本上需要滿足以下幾個需求:
- 便利性:能夠快速的定位文件位置,對編輯器友好
- 解耦性:不同頁面之間,不同組件之間是相互解耦的,不會更改一個組件或頁面而影響到其他組件或頁面
- 擴展性:能夠很方便的擴展組件和頁面,而不會帶來副作用
- 閱讀性:具有很好的閱讀性,對組件、頁面以及內部結構能夠一目了然
以 lila 構建工具為例,它的 工作空間 概念便很好的滿足上述所有需求:
比如,home 頁的工作空間(/project/src/home/),這個頁面(或者組件)所有文件都在這個目錄下,包括 js、css、html片段、圖片、json模擬數據等等。
- 開發的時候,都只在這個目錄下工作,避免多級目錄的不斷切換(當工程很大的時候,這是個大問題)
- 當新添加一個頁面或組件的時候,直接復制一個原有的頁面或組件,這是極為方便的
- 解耦當然就不用說了,內部結構也是很清晰的
2.4 其他約定
如:
- 每個 js 文件不應該超過 400 行,超過就應該分塊
- 每個 css 文件不應該超過 200 行,超過就應該分塊
- …
3. 后續
上一篇:本地化接口模擬、前后端并行開發
下一篇:前端開發文檔
更多博客,查看 https://github.com/senntyou/blogs
作者:深予之 (@senntyou)
版權聲明:自由轉載-非商用-非衍生-保持署名(創意共享3.0許可證)
總結
以上是生活随笔為你收集整理的前端架构之路(3) - 前端开发规范的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【电路中电容,电感对电路纹波以及启动电流
- 下一篇: 骨传导耳机是什么意思,骨传导耳机原理