一個好的程序員肯定是要能書寫可維護的代碼，而不是一次性的代碼，怎麼能讓團隊當中的其他人，甚至過一段時間之後的你，再看自己某個時期寫的代碼，依然能看懂？這就涉及到規範你的代碼了。
一、規範代碼的好處
1、從根本上降低開發成本：
提高代碼整體的可讀性、可維護性、可複用性。
2、保證代碼的一致性：
軟件系統中最重要的因素之一就是編碼的一致性。如果編碼風格一致，也更加易於維護，因爲團隊內任何人都可以快速理解並修改。
3、提升團隊整體效率：
開發人員通常需要花費大量的時間來解決代碼質量問題，如果都按照規範編寫，也有助於團隊儘早發現問題，這將提高整個交付過程的效率。
二、不規範代碼的弊端
1、增加團隊成員間的協作負擔：
由於缺乏規範，導致代碼風格不一，極端情況下，某段代碼只有某個人能修改。
2、團隊間協作更加困難：
由於開發人員要適應不同的風格，會導致效率低下。
3、回顧困難：
在review期間，可能經常爲類似的事情做過多的討論。
4、影響降低團隊整體效率：
影響團隊的生產力和質量，嚴重的甚至會影響團隊和諧。
三、爲什麼很多團隊缺乏規範
1、當開發人員被要求在短時間內完成任務時，通常會迴避質量標準。
2、長時間養成的開發習慣很難在短時間內去改變。
3、有的時候雖然達成了一致，但在開發中依舊我行我素。
四、規範包含哪些內容
我們平時理解的前端開發規範，更多層面的是編碼層面的規範，實際上遠不止這一個。比如技術棧規範、瀏覽器兼容規範、項目文件結構規範、UI設計規範、前後端協作規範等，以下主要從這六個方面簡單介紹下前端開發規範。
1、技術棧規範
前端目前主要有三大框架Vue、React和AngularJS。每一個框架背後都是一個架構、一個生態。每個框架背後牽涉着開發思維、生態系統、配套工具、最佳實踐、性能調優。要精通和熟練一個框架需要付出的成本是很高。
所以說團隊的開發效率是基於穩定且熟練的技術棧的。穩定的技術棧規範有利於團隊協作和溝通; 另外如果團隊精通這個技術棧，當出現問題或者需要深入調優, 會相對輕鬆。
前端技術棧規範主要包含下面這些類型:
① 編程語言 - Typescript或Javascript
② UI框架及其配套生態（路由、狀態管理、組件庫、國際化、動畫、服務端渲染、腳手架、CLI工具、組件測試等）
③ 樣式。命名規範、預處理器等
④ 動畫引擎
⑤ 項目構建工具流。webpack、vue-cli
⑥ 包管理器。npm、yarn
⑦ 開發工具、工具庫（moment.js）、版本管理（gitlab）等
2、瀏覽器兼容規範
前端團隊應該根據應用所面對的用戶情況、應用類型、開發成本、瀏覽器市場統計數據等因素，來制定自己的瀏覽器兼容規範。不過確定哪種兼容策略，應該取決於用戶比重，如果大部分用戶使用的是現代瀏覽器，就應該使用優雅降級，爲現代瀏覽器提供最好的體驗，而舊瀏覽器則退而求之次，保證大概的功能，反之選擇漸進增強，保證低版本瀏覽器的體驗，對於支持新特性的新瀏覽器提供稍好的體驗。
有了瀏覽器兼容規範，前端開發和兼容性測試就有理有據，避免爭議; 同時它也是前端團隊的一種對外聲明，除非特殊要求，不符合瀏覽器兼容規範的瀏覽器，前端開發人員可以選擇忽略。
我們也可以根據瀏覽器市場分佈情況、用戶佔比、開發成本等因素對將瀏覽器劃分爲多個等級，不同等級表示不同的支持程度：
① 完全兼容: 保證百分百功能正常
② 部分兼容: 只能保證功能、樣式與需求大致一致。對於一些不影響主體需求和功能的bug，會做降低優先級處理或者不處理
③ 不兼容: 不考慮兼容性
3、項目文件結構規範
主要包含項目的命名、項目的文件結構、版本號規範等。
下面簡單列舉一類項目文件結構：
① README.md: 項目說明。你可以在這裏提供關於項目的關鍵信息或者相關信息的入口。一般包含下列信息:
· 簡要描述、項目主要特性；
· 運行環境/依賴、安裝和構建、測試指南；
· 簡單示例代碼；
· 文檔或文檔入口, 其他版本或相關資源入口；
· 聯繫方式、討論羣；
· 許可、貢獻/開發指南。
② CHANGELOG.md: 放置每個版本的變動內容, 通常要描述每個版本變更的內容。方便使用者確定應該使用哪個版本。
③ package.json: 前端項目必須. 描述當前的版本、可用的命令、包名、依賴、環境約束、項目配置等信息。
④ .gitignore: 忽略不必要的文件，避免將自動生成的文件提交到版本庫。
⑤ docs/: 項目的細化文檔, 可選。
⑥ examples/: 項目的示例代碼，可選。
⑦ build: 項目工具類腳本放置在這裏，非必須。如果使用統一構建工具，則沒有這個目錄。
⑧ dist/: 項目構建結果輸出目錄。
⑨ src/: 源代碼目錄。
引用
src 開發目錄
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中的數據
utils 這裏是以utils爲後綴
- index.ts
- a.utils.ts
- b.utils.ts
hooks 這裏是以hooks爲後綴
- index.ts
- a.hooks.ts
- b.hooks.ts
- styles 靜態資源文件
service api請求,這裏是以api爲後綴
- a.api.ts 按照後端微服務進行劃分
- b.api.ts
- constans 常量
⑩ tests/: 單元測試目錄。
⑪ tests: 全局的測試目錄，通常放應用的集成測試或E2E測試等。
⑫ .env*: 項目中我們通常會使用環境變量來影響應用在不同運行環境下的行爲。可以通過dotEnv來從文件中讀取環境變量. 通常有三個文件:
· env 通用的環境變量；
· env.development 開發環境的環境變量;
· env.production 生成環境的環境變量。
4、編碼規範
每一個程序員心目中對‘好代碼’都有自己的主見，統一的編碼規範可以避免不必要的論戰和爭議，有利於團隊項目的長遠維護。一致性的代碼規範可以增強團隊開發協作效率、提高代碼質量、減輕系統維護的負擔。
以下主要從HTML、JS、CSS、代碼格式化這四個方面談談編碼規範：
① HTML規範
使用 HTML5 的文檔聲明類型 :
DOCTYPE標籤是一種標準通用標記語言的文檔類型聲明，它的目的是要告訴標準通用標記語言解析器，它應該使用什麼樣的文檔類型定義（DTD）來解析文檔。
使用文檔聲明類型的作用是爲了防止開啓瀏覽器的怪異模式。
沒有DOCTYPE文檔類型聲明會開啓瀏覽器的怪異模式，瀏覽器會按照自己的解析方式渲染頁面，在不同的瀏覽器下面會有不同的樣式。
如果你的頁面添加了，那麼就等同於開啓了標準模式。瀏覽器會按照W3C標準解析渲染頁面。
詳細規範可查看： https://codeguide.co/#html
② JS規範
函數變量命名、代碼註釋等。JS/TS主流的大致有這幾種:
· Airbnb JavaScript Style Guide：
https://github.com/airbnb/jav...
· Google JavaScript Style Guide： https://google.github.io/styl...]
· Idiomatic JavaScript Style Guide：
https://github.com/rwaldron/i...
· JavaScript Standard Style Guide
③ CSS規範
ID和class的命名、合理使用ID、css選擇器中避免使用標籤名、使用子選擇器、儘量使用縮寫屬性等，詳細可參考以下網站：
· Airbnb CSS / Sass Styleguide：
https://css-tricks.com/bem-101/
· Code Guide：
https://codeguide.co/#css
④ 代碼格式化規範
由於每個開發者的IDE不同，即使IDE相同也會因爲每個人的配置不一樣導致格式化的結果不一樣。如何確保團隊內開發人員採用統一的格式化配置呢？
這裏給推薦大家使用 prettier，它內置了一套格式化的規則。細可參考以下網站：https://prettier.io/
5、UI設計規範
UI 規範的最大好處就是能夠提質提效：
① 在開發者的角度，與設計規範同步形成研發資產，避免重複造輪子；
② 在測試的角度，能夠避免重複的無意義走查；
③ 在UI設計師的角度，減少設計成本，提高設計效率，可以快速承接新需求；
④ 在產品角度，提高產品迭代與優化效率，降低試錯成本；
⑤ 在用戶角度，解決用戶體驗一致性。
如果團隊不打算制定自己的UI設計規範，則推薦使用現成的開源組件庫：Ant Design、Element UI、iView、WeUI等
6、前後端協作規範
前端往往不能脫離後端而存在，和後端協作的時間也是比較長的。
一個常用的前後端協作流程：
① 需求分析。參與者一般有前後端、測試、以及產品。由產品主持，對需求進行講解，接受開發和測試的反饋，確保大家對需求有一致的認知。
② 前後端開發討論。討論應用的一些開發設計，溝通技術點、難點、以及分工問題。
③ 設計接口文檔。可以由前後端一起設計；或者由後端設計、前端確認是否符合要求。
④ 並行開發。前後端並行開發，在這個階段，前端可以先實現靜態頁面; 或者根據接口文檔對接口進行Mock, 來模擬對接後端接口。
⑤ 前後端進行接口聯調。
五、前端開發規範實例
1、項目情況
多人開發同一個項目的不同模塊；由於開發前沒有制定規範，導致每個人的代碼都是一種單獨的風格；當其他人去修改代碼時需要熟悉不同風格的代碼，浪費了大量時間在閱讀代碼上；而且由於沒有全局的樣式規範，導致每個人都有一套自己的樣式，在後期如果想要做統一的界面風格時需要每個人都去修改樣式代碼，增加了大量工作量。
2、制定規範
根據項目的實際情況，由於項目已經開發到一定程度，已經選好了開發框架，所以可以從編碼和UI設計等方面進行規範。
由於項目是一個管理系統，所以對於前端UI來說可以統一頁面結構；制定一個統一風格的模板，開發的時候可以直接使用模板代碼去做適應性的修改；
由於缺乏統一的樣式標準，導致後期統一風格時會花費大量時間，所以進行統一的樣式分離，抽離公共的CSS樣式去引用，方便後期統一修改；
由於一些變量和函數命名過於簡單比如a、b、c等，規範多使用一些語義化的單詞去命名，方便理解和閱讀；
由於項目開發中前後端是同一個人開發，導致有些可能是後端的工作放到了前端去處理。比如分頁功能，雖然這個是前後端都可以做的，但是如果使用前端去分頁，這樣就要需要一次性返回全部數據，數據量大的時候接口可能會返回很慢，導致頁面空白時間比較長，所以建議有些邏輯功能要根據實際情況去決定是前端還是後端處理。
3、最終成果
項目代碼結構基本上有一個統一的風格；各模塊頁面也有了統一的風格；用戶體驗較好；也方便了開發和維護。
總結：
一個人走得更快，一羣人可以走得更遠。統一規範的最根本目的是爲了保證團隊成員的一致性，從而減少溝通成本，提高開發效率。學會熱愛標準，但要確保它們不是一成不變的。如果制定的規範不適合您的團隊，請確保可以適應和重寫所需要的任何規則。它並不是要強制執行一種工作方式，而是爲了幫助促進團隊之間的互動。
以上就是本次分享的所有內容，想要了解更多歡迎前往公衆號：web前端開發社區，每日干貨分享
