淺談前端開發規范，你學會了嗎？
一個好的程序員肯定是要能書寫可維護的代碼，而不是一次性的代碼，怎么能讓團隊當中的其他人，甚至過一段時間之后的你，再看自己某個時期寫的代碼，依然能看懂?這就涉及到規范你的代碼了。
一、規范代碼的好處
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/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規范
ID和class的命名、合理使用ID、css選擇器中避免使用標簽名、使用子選擇器、盡量使用縮寫屬性等，詳細可參考以下網站：
- Airbnb CSS / Sass Styleguide：
??https://css-tricks.com/bem-101/??
- Code Guide：
④ 代碼格式化規范
由于每個開發者的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.最終成果
項目代碼結構基本上有一個統一的風格;各模塊頁面也有了統一的風格;用戶體驗較好;也方便了開發和維護。
總結：
一個人走得更快，一群人可以走得更遠。統一規范的最根本目的是為了保證團隊成員的一致性，從而減少溝通成本，提高開發效率。學會熱愛標準，但要確保它們不是一成不變的。如果制定的規范不適合您的團隊，請確保可以適應和重寫所需要的任何規則。它并不是要強制執行一種工作方式，而是為了幫助促進團隊之間的互動。
