新鈦云服已為您服務(wù)1474天

一個好的程序員肯定是要能書寫可維護的代碼，而不是一次性的代碼，怎么能讓團隊當中的其他人，甚至過一段時間之后的你，再看自己某個時期寫的代碼，依然能看懂？這就涉及到規(guī)范你的代碼了。

一、規(guī)范代碼的好處

1、從根本上降低開發(fā)成本：

提高代碼整體的可讀性、可維護性、可復用性。

2、保證代碼的一致性：

軟件系統(tǒng)中最重要的因素之一就是編碼的一致性。如果編碼風格一致，也更加易于維護，因為團隊內(nèi)任何人都可以快速理解并修改。

3、提升團隊整體效率：

開發(fā)人員通常需要花費大量的時間來解決代碼質(zhì)量問題，如果都按照規(guī)范編寫，也有助于團隊盡早發(fā)現(xiàn)問題，這將提高整個交付過程的效率。

二、不規(guī)范代碼的弊端

1、增加團隊成員間的協(xié)作負擔：

由于缺乏規(guī)范，導致代碼風格不一，極端情況下，某段代碼只有某個人能修改。

2、團隊間協(xié)作更加困難：

由于開發(fā)人員要適應(yīng)不同的風格，會導致效率低下。

3、回顧困難：

在review期間，可能經(jīng)常為類似的事情做過多的討論。

4、影響降低團隊整體效率：

影響團隊的生產(chǎn)力和質(zhì)量，嚴重的甚至會影響團隊和諧。

三、為什么很多團隊缺乏規(guī)范

1、當開發(fā)人員被要求在短時間內(nèi)完成任務(wù)時，通常會回避質(zhì)量標準。

2、長時間養(yǎng)成的開發(fā)習慣很難在短時間內(nèi)去改變。

3、有的時候雖然達成了一致，但在開發(fā)中依舊我行我素。

四、規(guī)范包含哪些內(nèi)容

我們平時理解的前端開發(fā)規(guī)范，更多層面的是編碼層面的規(guī)范，實際上遠不止這一個。比如技術(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)。要精通和熟練一個框架需要付出的成本是很高。

所以說團隊的開發(fā)效率是基于穩(wěn)定且熟練的技術(shù)棧的。穩(wěn)定的技術(shù)棧規(guī)范有利于團隊協(xié)作和溝通; 另外如果團隊精通這個技術(shù)棧，當出現(xiàn)問題或者需要深入調(diào)優(yōu), 會相對輕松。

前端技術(shù)棧規(guī)范主要包含下面這些類型:

①?編程語言?- Typescript或Javascript

②?UI框架及其配套生態(tài)（路由、狀態(tài)管理、組件庫、國際化、動畫、服務(wù)端渲染、腳手架、CLI工具、組件測試等）

③?樣式。命名規(guī)范、預處理器等

④?動畫引擎

⑤?項目構(gòu)建工具流。webpack、vue-cli

⑥?包管理器。npm、yarn

⑦?開發(fā)工具、工具庫（moment.js）、版本管理（gitlab）等

2、瀏覽器兼容規(guī)范

前端團隊應(yīng)該根據(jù)應(yīng)用所面對的用戶情況、應(yīng)用類型、開發(fā)成本、瀏覽器市場統(tǒng)計數(shù)據(jù)等因素，來制定自己的瀏覽器兼容規(guī)范。不過確定哪種兼容策略，應(yīng)該取決于用戶比重，如果大部分用戶使用的是現(xiàn)代瀏覽器，就應(yīng)該使用優(yōu)雅降級，為現(xiàn)代瀏覽器提供最好的體驗，而舊瀏覽器則退而求之次，保證大概的功能，反之選擇漸進增強，保證低版本瀏覽器的體驗，對于支持新特性的新瀏覽器提供稍好的體驗。

有了瀏覽器兼容規(guī)范，前端開發(fā)和兼容性測試就有理有據(jù)，避免爭議; 同時它也是前端團隊的一種對外聲明，除非特殊要求，不符合瀏覽器兼容規(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)系方式、討論群；

·?許可、貢獻/開發(fā)指南。

② CHANGELOG.md: 放置每個版本的變動內(nèi)容, 通常要描述每個版本變更的內(nèi)容。方便使用者確定應(yīng)該使用哪個版本。

③ package.json: 前端項目必須. 描述當前的版本、可用的命令、包名、依賴、環(huán)境約束、項目配置等信息。

④ .gitignore: 忽略不必要的文件，避免將自動生成的文件提交到版本庫。

⑤ docs/: 項目的細化文檔, 可選。

⑥ 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 導出所有組件

????????- 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ù)進行劃分

????????- 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)和爭議，有利于團隊項目的長遠維護。一致性的代碼規(guī)范可以增強團隊開發(fā)協(xié)作效率、提高代碼質(zhì)量、減輕系統(tǒng)維護的負擔。

以下主要從HTML、JS、CSS、代碼格式化這四個方面談?wù)劸幋a規(guī)范：

①?HTML規(guī)范

使用?HTML5 的文檔聲明類型 :

DOCTYPE標簽是一種標準通用標記語言的文檔類型聲明，它的目的是要告訴標準通用標記語言解析器，它應(yīng)該使用什么樣的文檔類型定義（DTD）來解析文檔。

使用文檔聲明類型的作用是為了防止開啟瀏覽器的怪異模式。

沒有DOCTYPE文檔類型聲明會開啟瀏覽器的怪異模式，瀏覽器會按照自己的解析方式渲染頁面，在不同的瀏覽器下面會有不同的樣式。

如果你的頁面添加了，那么就等同于開啟了標準模式。瀏覽器會按照W3C標準解析渲染頁面。

詳細規(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選擇器中避免使用標簽名、使用子選擇器、盡量使用縮寫屬性等，詳細可參考以下網(wǎng)站：

·?Airbnb CSS / Sass Styleguide：

https://css-tricks.com/bem-101/

·?Code Guide：

https://codeguide.co/#css

④?代碼格式化規(guī)范

由于每個開發(fā)者的IDE不同，即使IDE相同也會因為每個人的配置不一樣導致格式化的結(jié)果不一樣。如何確保團隊內(nèi)開發(fā)人員采用統(tǒng)一的格式化配置呢？

這里給推薦大家使用 prettier，它內(nèi)置了一套格式化的規(guī)則。細可參考以下網(wǎng)站：https://prettier.io/

5、UI設(shè)計規(guī)范

UI 規(guī)范的最大好處就是能夠提質(zhì)提效：

①?在開發(fā)者的角度，與設(shè)計規(guī)范同步形成研發(fā)資產(chǎn)，避免重復造輪子；

②?在測試的角度，能夠避免重復的無意義走查；

③?在UI設(shè)計師的角度，減少設(shè)計成本，提高設(shè)計效率，可以快速承接新需求；

④?在產(chǎn)品角度，提高產(chǎn)品迭代與優(yōu)化效率，降低試錯成本；

⑤?在用戶角度，解決用戶體驗一致性。

如果團隊不打算制定自己的UI設(shè)計規(guī)范，則推薦使用現(xiàn)成的開源組件庫：Ant Design、Element UI、iView、WeUI等

?6、前后端協(xié)作規(guī)范

前端往往不能脫離后端而存在，和后端協(xié)作的時間也是比較長的。

一個常用的前后端協(xié)作流程：

①?需求分析。參與者一般有前后端、測試、以及產(chǎn)品。由產(chǎn)品主持，對需求進行講解，接受開發(fā)和測試的反饋，確保大家對需求有一致的認知。

②?前后端開發(fā)討論。討論應(yīng)用的一些開發(fā)設(shè)計，溝通技術(shù)點、難點、以及分工問題。

③?設(shè)計接口文檔。可以由前后端一起設(shè)計；或者由后端設(shè)計、前端確認是否符合要求。

④?并行開發(fā)。前后端并行開發(fā)，在這個階段，前端可以先實現(xiàn)靜態(tài)頁面; 或者根據(jù)接口文檔對接口進行Mock, 來模擬對接后端接口。

⑤?前后端進行接口聯(lián)調(diào)。

五、前端開發(fā)規(guī)范實例

1、項目情況

多人開發(fā)同一個項目的不同模塊；由于開發(fā)前沒有制定規(guī)范，導致每個人的代碼都是一種單獨的風格；當其他人去修改代碼時需要熟悉不同風格的代碼，浪費了大量時間在閱讀代碼上；而且由于沒有全局的樣式規(guī)范，導致每個人都有一套自己的樣式，在后期如果想要做統(tǒng)一的界面風格時需要每個人都去修改樣式代碼，增加了大量工作量。

2、制定規(guī)范

根據(jù)項目的實際情況，由于項目已經(jīng)開發(fā)到一定程度，已經(jīng)選好了開發(fā)框架，所以可以從編碼和UI設(shè)計等方面進行規(guī)范。

由于項目是一個管理系統(tǒng)，所以對于前端UI來說可以統(tǒng)一頁面結(jié)構(gòu)；制定一個統(tǒng)一風格的模板，開發(fā)的時候可以直接使用模板代碼去做適應(yīng)性的修改；

由于缺乏統(tǒng)一的樣式標準，導致后期統(tǒng)一風格時會花費大量時間，所以進行統(tǒng)一的樣式分離，抽離公共的CSS樣式去引用，方便后期統(tǒng)一修改；

由于一些變量和函數(shù)命名過于簡單比如a、b、c等，規(guī)范多使用一些語義化的單詞去命名，方便理解和閱讀；

由于項目開發(fā)中前后端是同一個人開發(fā)，導致有些可能是后端的工作放到了前端去處理。比如分頁功能，雖然這個是前后端都可以做的，但是如果使用前端去分頁，這樣就要需要一次性返回全部數(shù)據(jù)，數(shù)據(jù)量大的時候接口可能會返回很慢，導致頁面空白時間比較長，所以建議有些邏輯功能要根據(jù)實際情況去決定是前端還是后端處理。

3、最終成果

項目代碼結(jié)構(gòu)基本上有一個統(tǒng)一的風格；各模塊頁面也有了統(tǒng)一的風格；用戶體驗較好；也方便了開發(fā)和維護。

總結(jié)：

一個人走得更快，一群人可以走得更遠。統(tǒng)一規(guī)范的最根本目的是為了保證團隊成員的一致性，從而減少溝通成本，提高開發(fā)效率。學會熱愛標準，但要確保它們不是一成不變的。如果制定的規(guī)范不適合您的團隊，請確保可以適應(yīng)和重寫所需要的任何規(guī)則。它并不是要強制執(zhí)行一種工作方式，而是為了幫助促進團隊之間的互動。

了解新鈦云服

新鈦云服榮膺第四屆FMCG零售消費品行業(yè)CIO年會「年度數(shù)字化服務(wù)最值得信賴品牌獎」

新鈦云服三周歲，公司月營收超600萬元，定下百年新鈦的發(fā)展目標

當IPFS遇見云服務(wù)|新鈦云服與冰河分布式實驗室達成戰(zhàn)略協(xié)議

新鈦云服正式獲批工信部ISP/IDC(含互聯(lián)網(wǎng)資源協(xié)作)牌照

深耕專業(yè)，矗立鰲頭，新鈦云服獲千萬Pre-A輪融資

新鈦云服，打造最專業(yè)的Cloud?MSP+，做企業(yè)業(yè)務(wù)和云之間的橋梁

新鈦云服一周年，完成兩輪融資，服務(wù)五十多家客戶

上海某倉儲物流電子商務(wù)公司混合云解決方案

往期技術(shù)干貨

Kubernetes擴容到7,500節(jié)點的歷程

低代碼開發(fā)，全民開發(fā)，淘汰職業(yè)程序員！

國內(nèi)主流公有云VPC使用對比及總結(jié)

萬字長文：云架構(gòu)設(shè)計原則|附PDF下載

剛剛，OpenStack 第 19 個版本來了，附28項特性詳細解讀！

Ceph OSD故障排除|萬字經(jīng)驗總結(jié)

七個用于Docker和Kubernetes防護的安全工具

運維人的終身成長，從清單管理開始|萬字長文！

OpenStack與ZStack深度對比：架構(gòu)、部署、計算存儲與網(wǎng)絡(luò)、運維監(jiān)控等

什么是云原生？

IT混合云戰(zhàn)略：是什么、為什么，如何構(gòu)建？

點👇分享

戳👇在看

總結(jié)

以上是生活随笔為你收集整理的浅谈前端开发规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。