建站
咨詢
售后
建站咨詢
新聞中心
一、規(guī)范代碼的好處
1.從根本上降低開發(fā)成本：
提高代碼整體的可讀性、可維護(hù)性、可復(fù)用性。
2.保證代碼的一致性：
軟件系統(tǒng)中最重要的因素之一就是編碼的一致性。如果編碼風(fēng)格一致，也更加易于維護(hù)，因為團(tuán)隊內(nèi)任何人都可以快速理解并修改。
3.提升團(tuán)隊整體效率：
開發(fā)人員通常需要花費大量的時間來解決代碼質(zhì)量問題，如果都按照規(guī)范編寫，也有助于團(tuán)隊盡早發(fā)現(xiàn)問題，這將提高整個交付過程的效率。
二、不規(guī)范代碼的弊端
1.增加團(tuán)隊成員間的協(xié)作負(fù)擔(dān)：
由于缺乏規(guī)范，導(dǎo)致代碼風(fēng)格不一，極端情況下，某段代碼只有某個人能修改。
2.團(tuán)隊間協(xié)作更加困難：
由于開發(fā)人員要適應(yīng)不同的風(fēng)格，會導(dǎo)致效率低下。
3.回顧困難：
在review期間，可能經(jīng)常為類似的事情做過多的討論。
4.影響降低團(tuán)隊整體效率：
影響團(tuán)隊的生產(chǎn)力和質(zhì)量，嚴(yán)重的甚至?xí)绊憟F(tuán)隊和諧。
三、為什么很多團(tuán)隊缺乏規(guī)范
1.當(dāng)開發(fā)人員被要求在短時間內(nèi)完成任務(wù)時，通常會回避質(zhì)量標(biāo)準(zhǔn)。
2.長時間養(yǎng)成的開發(fā)習(xí)慣很難在短時間內(nèi)去改變。
3.有的時候雖然達(dá)成了一致，但在開發(fā)中依舊我行我素。
四、規(guī)范包含哪些內(nèi)容
我們平時理解的前端開發(fā)規(guī)范，更多層面的是編碼層面的規(guī)范，實際上遠(yuǎn)不止這一個。比如技術(shù)棧規(guī)范、瀏覽器兼容規(guī)范、項目文件結(jié)構(gòu)規(guī)范、UI設(shè)計規(guī)范、前后端協(xié)作規(guī)范等，以下主要從這六個方面簡單介紹下前端開發(fā)規(guī)范。
1.技術(shù)棧規(guī)范
前端目前主要有三大框架Vue、React和AngularJS。每一個框架背后都是一個架構(gòu)、一個生態(tài)。每個框架背后牽涉著開發(fā)思維、生態(tài)系統(tǒng)、配套工具、最佳實踐、性能調(diào)優(yōu)。要精通和熟練一個框架需要付出的成本是很高。
所以說團(tuán)隊的開發(fā)效率是基于穩(wěn)定且熟練的技術(shù)棧的。穩(wěn)定的技術(shù)棧規(guī)范有利于團(tuán)隊協(xié)作和溝通; 另外如果團(tuán)隊精通這個技術(shù)棧，當(dāng)出現(xiàn)問題或者需要深入調(diào)優(yōu), 會相對輕松。
前端技術(shù)棧規(guī)范主要包含下面這些類型:
① 編程語言 - Typescript或Javascript。
② UI框架及其配套生態(tài)(路由、狀態(tài)管理、組件庫、國際化、動畫、服務(wù)端渲染、腳手架、CLI工具、組件測試等)。
③ 樣式。命名規(guī)范、預(yù)處理器等。
④ 動畫引擎。
⑤ 項目構(gòu)建工具流。webpack、vue-cli。
⑥ 包管理器。npm、yarn。
⑦ 開發(fā)工具、工具庫(moment.js)、版本管理(gitlab)等。
2.瀏覽器兼容規(guī)范
前端團(tuán)隊?wèi)?yīng)該根據(jù)應(yīng)用所面對的用戶情況、應(yīng)用類型、開發(fā)成本、瀏覽器市場統(tǒng)計數(shù)據(jù)等因素，來制定自己的瀏覽器兼容規(guī)范。不過確定哪種兼容策略，應(yīng)該取決于用戶比重，如果大部分用戶使用的是現(xiàn)代瀏覽器，就應(yīng)該使用優(yōu)雅降級，為現(xiàn)代瀏覽器提供最好的體驗，而舊瀏覽器則退而求之次，保證大概的功能，反之選擇漸進(jìn)增強，保證低版本瀏覽器的體驗，對于支持新特性的新瀏覽器提供稍好的體驗。
有了瀏覽器兼容規(guī)范，前端開發(fā)和兼容性測試就有理有據(jù)，避免爭議; 同時它也是前端團(tuán)隊的一種對外聲明，除非特殊要求，不符合瀏覽器兼容規(guī)范的瀏覽器，前端開發(fā)人員可以選擇忽略。
我們也可以根據(jù)瀏覽器市場分布情況、用戶占比、開發(fā)成本等因素對將瀏覽器劃分為多個等級，不同等級表示不同的支持程度：
① 完全兼容: 保證百分百功能正常。
② 部分兼容: 只能保證功能、樣式與需求大致一致。對于一些不影響主體需求和功能的bug，會做降低優(yōu)先級處理或者不處理。
③ 不兼容: 不考慮兼容性。
3.項目文件結(jié)構(gòu)規(guī)范
主要包含項目的命名、項目的文件結(jié)構(gòu)、版本號規(guī)范等。
下面簡單列舉一類項目文件結(jié)構(gòu)：
① README.md: 項目說明。你可以在這里提供關(guān)于項目的關(guān)鍵信息或者相關(guān)信息的入口。一般包含下列信息:
- 簡要描述、項目主要特性;
- 運行環(huán)境/依賴、安裝和構(gòu)建、測試指南;
- 簡單示例代碼;
- 文檔或文檔入口, 其他版本或相關(guān)資源入口;
- 聯(lián)系方式、討論群;
- 許可、貢獻(xiàn)/開發(fā)指南。
② CHANGELOG.md: 放置每個版本的變動內(nèi)容, 通常要描述每個版本變更的內(nèi)容。方便使用者確定應(yīng)該使用哪個版本。
③ package.json: 前端項目必須. 描述當(dāng)前的版本、可用的命令、包名、依賴、環(huán)境約束、項目配置等信息。
④ .gitignore: 忽略不必要的文件，避免將自動生成的文件提交到版本庫。
⑤ docs/: 項目的細(xì)化文檔, 可選。
⑥ examples/: 項目的示例代碼，可選。
⑦ build: 項目工具類腳本放置在這里，非必須。如果使用統(tǒng)一構(gòu)建工具，則沒有這個目錄。
⑧ dist/: 項目構(gòu)建結(jié)果輸出目錄。
⑨ src/: 源代碼目錄。
- src 開發(fā)目錄
- pages 視圖
- module-a 模塊A
- components 私有組件
- ComA.tsx
- ComB.tsx
- index.module.less
- index.tsx
- Content.tsx
- module-b 模塊B
- components 公共組件
- index.ts 導(dǎo)出所有組件
- header
- index.tsx
- index.module.less
- User.tsx
- useGetBaseInfo.hooks.ts
- routers 路由文件
- store redux中的數(shù)據(jù)
- utils 這里是以utils為后綴
- index.ts
- a.utils.ts
- b.utils.ts
- hooks 這里是以hooks為后綴
- index.ts
- a.hooks.ts
- b.hooks.ts
- styles 靜態(tài)資源文件
- service api請求,這里是以api為后綴
- a.api.ts 按照后端微服務(wù)進(jìn)行劃分
- b.api.ts
- constans 常量
⑩ tests/: 單元測試目錄。
? tests: 全局的測試目錄，通常放應(yīng)用的集成測試或E2E測試等。
? .env*: 項目中我們通常會使用環(huán)境變量來影響應(yīng)用在不同運行環(huán)境下的行為?？梢酝ㄟ^dotEnv來從文件中讀取環(huán)境變量. 通常有三個文件:
- env 通用的環(huán)境變量;
- env.development 開發(fā)環(huán)境的環(huán)境變量;
- env.production 生成環(huán)境的環(huán)境變量。
4.編碼規(guī)范
每一個程序員心目中對‘好代碼’都有自己的主見，統(tǒng)一的編碼規(guī)范可以避免不必要的論戰(zhàn)和爭議，有利于團(tuán)隊項目的長遠(yuǎn)維護(hù)。一致性的代碼規(guī)范可以增強團(tuán)隊開發(fā)協(xié)作效率、提高代碼質(zhì)量、減輕系統(tǒng)維護(hù)的負(fù)擔(dān)。
以下主要從HTML、JS、CSS、代碼格式化這四個方面談?wù)劸幋a規(guī)范：
① HTML規(guī)范
使用 HTML5 的文檔聲明類型 :
DOCTYPE標(biāo)簽是一種標(biāo)準(zhǔn)通用標(biāo)記語言的文檔類型聲明，它的目的是要告訴標(biāo)準(zhǔn)通用標(biāo)記語言解析器，它應(yīng)該使用什么樣的文檔類型定義(DTD)來解析文檔。
使用文檔聲明類型的作用是為了防止開啟瀏覽器的怪異模式。
沒有DOCTYPE文檔類型聲明會開啟瀏覽器的怪異模式，瀏覽器會按照自己的解析方式渲染頁面，在不同的瀏覽器下面會有不同的樣式。
如果你的頁面添加了，那么就等同于開啟了標(biāo)準(zhǔn)模式。瀏覽器會按照W3C標(biāo)準(zhǔn)解析渲染頁面。
詳細(xì)規(guī)范可查看：https://codeguide.co/#html
② JS規(guī)范
函數(shù)變量命名、代碼注釋等。JS/TS主流的大致有這幾種:
- Airbnb JavaScript Style Guide：
??https://github.com/airbnb/javascript??
- Google JavaScript Style Guide：
??https://google.github.io/styleguide/jsguide.html]??
- Idiomatic JavaScript Style Guide：
??https://github.com/rwaldron/idiomatic.js??
- JavaScript Standard Style Guide
③ CSS規(guī)范
ID和class的命名、合理使用ID、css選擇器中避免使用標(biāo)簽名、使用子選擇器、盡量使用縮寫屬性等，詳細(xì)可參考以下網(wǎng)站：
- Airbnb CSS / Sass Styleguide：
??https://css-tricks.com/bem-101/??
- Code Guide：
??https://codeguide.co/#css??
④ 代碼格式化規(guī)范
由于每個開發(fā)者的IDE不同，即使IDE相同也會因為每個人的配置不一樣導(dǎo)致格式化的結(jié)果不一樣。如何確保團(tuán)隊內(nèi)開發(fā)人員采用統(tǒng)一的格式化配置呢?
這里給推薦大家使用 prettier，它內(nèi)置了一套格式化的規(guī)則。細(xì)可參考以下網(wǎng)站：https://prettier.io/
5.UI設(shè)計規(guī)范
UI 規(guī)范的最大好處就是能夠提質(zhì)提效：
① 在開發(fā)者的角度，與設(shè)計規(guī)范同步形成研發(fā)資產(chǎn)，避免重復(fù)造輪子;
② 在測試的角度，能夠避免重復(fù)的無意義走查;
③ 在UI設(shè)計師的角度，減少設(shè)計成本，提高設(shè)計效率，可以快速承接新需求;
④ 在產(chǎn)品角度，提高產(chǎn)品迭代與優(yōu)化效率，降低試錯成本;
⑤ 在用戶角度，解決用戶體驗一致性。
如果團(tuán)隊不打算制定自己的UI設(shè)計規(guī)范，則推薦使用現(xiàn)成的開源組件庫：Ant Design、Element UI、iView、WeUI等
6.前后端協(xié)作規(guī)范
前端往往不能脫離后端而存在，和后端協(xié)作的時間也是比較長的。
一個常用的前后端協(xié)作流程：
① 需求分析。參與者一般有前后端、測試、以及產(chǎn)品。由產(chǎn)品主持，對需求進(jìn)行講解，接受開發(fā)和測試的反饋，確保大家對需求有一致的認(rèn)知。
② 前后端開發(fā)討論。討論應(yīng)用的一些開發(fā)設(shè)計，溝通技術(shù)點、難點、以及分工問題。
③ 設(shè)計接口文檔?？梢杂汕昂蠖艘黄鹪O(shè)計;或者由后端設(shè)計、前端確認(rèn)是否符合要求。
④ 并行開發(fā)。前后端并行開發(fā)，在這個階段，前端可以先實現(xiàn)靜態(tài)頁面; 或者根據(jù)接口文檔對接口進(jìn)行Mock, 來模擬對接后端接口。
⑤ 前后端進(jìn)行接口聯(lián)調(diào)。
五、前端開發(fā)規(guī)范實例
1.項目情況
多人開發(fā)同一個項目的不同模塊;由于開發(fā)前沒有制定規(guī)范，導(dǎo)致每個人的代碼都是一種單獨的風(fēng)格;當(dāng)其他人去修改代碼時需要熟悉不同風(fēng)格的代碼，浪費了大量時間在閱讀代碼上;而且由于沒有全局的樣式規(guī)范，導(dǎo)致每個人都有一套自己的樣式，在后期如果想要做統(tǒng)一的界面風(fēng)格時需要每個人都去修改樣式代碼，增加了大量工作量。
2.制定規(guī)范
根據(jù)項目的實際情況，由于項目已經(jīng)開發(fā)到一定程度，已經(jīng)選好了開發(fā)框架，所以可以從編碼和UI設(shè)計等方面進(jìn)行規(guī)范。
由于項目是一個管理系統(tǒng)，所以對于前端UI來說可以統(tǒng)一頁面結(jié)構(gòu);制定一個統(tǒng)一風(fēng)格的模板，開發(fā)的時候可以直接使用模板代碼去做適應(yīng)性的修改;
由于缺乏統(tǒng)一的樣式標(biāo)準(zhǔn)，導(dǎo)致后期統(tǒng)一風(fēng)格時會花費大量時間，所以進(jìn)行統(tǒng)一的樣式分離，抽離公共的CSS樣式去引用，方便后期統(tǒng)一修改;
由于一些變量和函數(shù)命名過于簡單比如a、b、c等，規(guī)范多使用一些語義化的單詞去命名，方便理解和閱讀;
由于項目開發(fā)中前后端是同一個人開發(fā)，導(dǎo)致有些可能是后端的工作放到了前端去處理。比如分頁功能，雖然這個是前后端都可以做的，但是如果使用前端去分頁，這樣就要需要一次性返回全部數(shù)據(jù)，數(shù)據(jù)量大的時候接口可能會返回很慢，導(dǎo)致頁面空白時間比較長，所以建議有些邏輯功能要根據(jù)實際情況去決定是前端還是后端處理。
3.最終成果
項目代碼結(jié)構(gòu)基本上有一個統(tǒng)一的風(fēng)格;各模塊頁面也有了統(tǒng)一的風(fēng)格;用戶體驗較好;也方便了開發(fā)和維護(hù)。
總結(jié)：
一個人走得更快，一群人可以走得更遠(yuǎn)。統(tǒng)一規(guī)范的最根本目的是為了保證團(tuán)隊成員的一致性，從而減少溝通成本，提高開發(fā)效率。學(xué)會熱愛標(biāo)準(zhǔn)，但要確保它們不是一成不變的。如果制定的規(guī)范不適合您的團(tuán)隊，請確?？梢赃m應(yīng)和重寫所需要的任何規(guī)則。它并不是要強制執(zhí)行一種工作方式，而是為了幫助促進(jìn)團(tuán)隊之間的互動。
網(wǎng)頁名稱：淺談前端開發(fā)規(guī)范，你學(xué)會了嗎？
文章分享：http://www.5511xx.com/article/cohihjp.html
