❶ Web前端開發規范之HTML規范
今天小編要跟大家分享的文章是關於Web前端開發規范之HTML規范。Web前端作為開發團隊中不可或缺的一部分，需要按照相關規定進行合理編寫(一部分不良習慣可能給自己和他人造成不必要的麻煩)。不同公司不同團隊具有不同的規范和文檔。下面是根據不同企業和團隊的要求進行全面詳細的整理結果。來和小編一起看一看HTML規范的原則吧！
HTML規范
1、文檔類型聲明及編碼：統一為html5聲明類型。書寫時利用IDE實現層次分明的縮進(默認縮進4空格)。
2、非特殊情況下CSS文件放在body部分標簽後。非特殊情況下大部分JS文件放在標簽尾部(如果需要界面未載入前執行的代碼可以放在head標簽後)避免行內JS和CSS代碼。
3、所有編碼需要遵循html(XML)標准，標簽&屬性&屬性命名必須由小寫字母及下劃線數字組成，且所有標簽必須閉合，包括br()，hr()等。屬性值用雙引號。
4、引入JS庫文件，文件名須包含庫名稱及版本號及是否為壓縮版，比如jquery-1.4.1.min.js。引入插件，文件名格式為庫名稱+插件名稱，比如jQuery.bootstrap.js。
5、書寫頁面過程中，請考慮向後擴展性。class&id參見css書寫規范.
6、需要為html元素添加自定義屬性的時候，首先要考慮下有沒有默認的已有的合適標簽去設置，如果沒有，可以使用須以"data-"為前綴來添加自定義屬性，避免使用"data："等其他命名方式。
7、語義化html，如標題根據重要性用h*(同一頁面只能有一個h1)，段落標記用p，列表用ul，內聯元素中不可嵌套塊級元素。
8、盡可能減少div多層級嵌套。
9、書寫鏈接地址時，必須避免重定向，例如：href="http：//#/"，即須在URL地址後面加上「/」;
10、在頁面中盡量避免使用style屬性，即style=""。
11、必須為含有描述性表單元素(input，textarea)添加label，如姓名：須寫成：姓名：
12、能以背景形式呈現的圖片，盡量寫入css樣式中。
13、重要圖片必須加上alt屬性。給重要的元素和截斷的元素加上title。
14、給區塊代碼及重要功能(比如循環)加上注釋，方便後台添加功能。
15、特殊符號使用：盡可能使用代碼替代：比如<(<)&>(>)&空格()&_(_)等等。
以上就是小編今天為大家分享的關於Web前端開發規范之HTML規范的文章，希望本篇文章能夠對正在從事Web前端工作的小夥伴們有所幫助，想要了解更多Web前端知識記得關注北大青鳥Web培訓官網，最後祝願小夥伴們工作順利，成為一名優秀的Web前端工程師。
❷ Web前端開發規范之文件命名規范
今天小編要跟大家分享的文章是關於Web前端開發規范之文件命名規范。Web前端作為開發團隊中不可或缺的一部分，需要按照相關規定進行合理編寫(一部分不良習慣可能給自己和他人造成不必要的麻煩)。不同公司不同團隊具有不同的規范和文檔。下面是根據不同企業和團隊的要求進行全面詳細的整理結果。來和小編一起看一看文件命名規范的原則吧！
基本原則
符合Web標准(UTF-8，HTML5)，語義化html(HTML5新增要求，減少div和span等無特定語義的標簽使用)，結構表現行為分離(HTML-CSS-JS代碼分離，不同行為代碼高內聚低耦合)，兼容性優良(早期版本瀏覽器兼容，移動端和PC端設備兼容).頁面性能方面(減少請求次數，例如使用精靈圖和sass語法)，代碼要求簡潔明了有序，盡可能的減小伺服器負載，保證最快的解析速度(減小repaint和reflow).
文件命名規范
1、html，css，js，lib，images文件均存放至項目的目錄中。如果使用相關前端框架，根據框架的文件格式進行合理布局。
2、所有文件夾及文件使用英文命名(避免使用中文路徑)。
3、html文件：入口文件使用index.html。如果有對應的設計組設計原稿，需要將對應的設計稿和html文件命名一致並合理存放。
4、css文件命名：後綴.css。通用initial.css，初始化base.css，首頁index.css，其他頁面按照對應的html命名。
5、Js文件命名：英文命名，後綴.js.通用common.js，初始化base.js。其他頁面按照對應的html命名。
以上就是小編今天為大家分享的關於Web前端開發規范之文件命名規范的文章，希望本篇文章能夠對正在從事Web前端工作的小夥伴們有所幫助，想要了解更多Web前端知識記得關注北大青鳥Web培訓官網，最後祝願小夥伴們工作順利，成為一名優秀的Web前端工程師。
❸ 前端開發實踐中有哪些常見規范
Javascript編碼規范
HTML編碼規范
CSS編碼規范
Less編碼規范
E-JSON數據傳輸標准
模塊和載入器規范
包結構規范
項目目錄結構規范
圖表庫標准
❹ 前端開發實踐中有哪些常見規范
Javascript編碼規范
HTML編碼規范
CSS編碼規范
Less編碼規范
E-JSON數據傳輸標准
模塊和載入器規范
包結構規范
項目目錄結構規范
圖表庫標准
❺ 前端開發實踐中有哪些常見的規范
Javascript編碼規范
HTML編碼規范
CSS編碼規范
Less編碼規范
E-JSON數據傳輸標准
模塊和載入器規范
包結構規范
項目目錄結構規范
圖表庫標准
❻ 前端開發是做什麼的工作職責有哪些
前端開發是做PC端開發任務;而Android開發、iOS開發和各種小程序主要針對的是移動端開發工作的。
1、使用Vue/React開發，配合產品完成 Web/Electron項目迭代；
2、收集、分析項目需求並給出技術解決方案，完成高質量的編碼開發、調試和版本維護工作；
3、深入分析和解決前端遇到的各種技術、性能、跨終端兼容等問題，持續優化前端用戶體驗與框架；
4、協助前端開發工程體系建設與落地。
任職資格：
1、35周歲以下（含），211院校本科及以上學歷，計算機相關專業優先，具備3年以上前端開發經驗者優先；
2、掌握至少一種主流框架並深入了解其原理，熟悉前端研發生態圈，包括模塊化、前端編譯和構建工具；
3、熟悉主流瀏覽器的特點，對桌面跨平台有深入了解更佳；
4、有完整參與一個產品的設計、開發到上線過程，對前後端協作模式、產品和項目流程、網路和安全有深入理解，有大型項目前端架構部署和實踐經驗優先；
5、關注前沿技術，具備較強學習能力，在各大技術社區活躍者、有自己開源項目者優先；
6、具備良好服務意識、責任心以及團隊溝通與協作能力。
❼ 什麼是web前端開發標准
對於前端，官方的定義是網站前台部分，運行在PC端，移動端等瀏覽器上展現給用戶瀏覽的網頁。用自己的話來說，前端是網頁給訪問網站的人看的內容和頁面，那前端開發顧名思義就是這些內容和頁面中代碼的實現。
現在的前端開發使得現代網頁更加美觀，交互效果顯著，功能更加強大。所以現在的前端開發，運用到的知識面更加廣泛，難度也更大。前端開發目前市場需求還是很大的，而且相對來講比較容易，很適合學習。需要學習的內容也不少，我有全套web前端視頻課資料可以發給你自學。
學習內容包括：
①計算機基礎以及PS基礎
②前端開發基礎（HTML5開發、JavaScript基礎到高級、jQuery網頁特效、Bootstrap框架）
③移動開發
④前端高級開發（ECMAScript6、Veu.js框架開發、webpack、前端頁面優化、React框架開發、AngularJS 2.0框架開發等）
⑤小程序開發
⑥全棧開發（MySQL資料庫、Python編程語言、Django框架等）
⑦就業拓展（網站SEO與前端安全技術）
互聯網行業目前還是最熱門的行業之一，學習IT技能之後足夠優秀是有機會進入騰訊、阿里、網易等互聯網大廠高薪就業的，發展前景非常好，普通人也可以學習。
想要系統學習，你可以考察對比一下開設有相關專業的熱門學校，好的學校擁有根據當下企業需求自主研發課程的能力，能夠在校期間取得大專或本科學歷，中博軟體學院、南京課工場、南京北大青鳥等開設相關專業的學校都是不錯的，建議實地考察對比一下。
祝你學有所成，望採納。
❽ 前端項目的開發流程
前端開發流程概述
前端開發流程可分為需求分析、開發階段、測試階段、維護階段，下面分別進行敘述。
2.1 需求分析
這個環節中，首先是和客戶進行交流，了解客戶的需求，然後分析項目的可行性，撰寫項目需求文檔。如果項目可行，則起討論具體方案，分模塊分步驟進行規劃，分析項目進度安排、所需成本，進行原型設計（包括頁面布局圖，頁面邏輯流程圖，說明文檔等。通過原型設計，可以讓項目組和客戶都可以對項目有一個直觀感受，同時可以低成本高效率的復現業務場景和各模塊流程）。
可以說需求分析階段是整個前端項目的基礎，基礎不牢，地動山搖。可以試想，如果和客戶溝通不順暢，有的方面客戶沒搞清楚是什麼效果，開發完成後就可能與客戶發生糾紛；如果可行性有問題，有的模塊很難實現或成本超出預算，就很難處理。
2.2 開發階段
這個環節是前端工程師主要參與的部分，按照需求分析階段的規劃按步驟完成任務。
根據產品需求分析文檔和原型圖進行UI設計，對產品的整體美術風格、交互設計、界面結構、操作流程等做出設計。負責項目中各種交互界面、圖標、LOGO、按鈕等相關元素的設計與製作。
根據UI設計進行規劃，提取界面中可以復用的模塊方便重復利用，分析界面是否有實現難度比較困難的地方，進行溝通和功能排期，按功能大小以及難度進行功能時間的評估，和後端溝通好排期時間，保證大家能夠更有效地開發合作，針對功能復雜的地方要先理清思路。
不要盲目開發前端搭建框架。根據設計圖進行前端界面開發，以及遇到的問題及時與產品、UI、後台人員溝通，保持大家信息一致，針對不清楚的地方也要及時溝通，以免做錯功能。
根據後端介面進行欄位填充，以及部分功能開發。針對缺少的欄位或者數據結構進行提出，及時與後端反應，盡量讓大家都能以最小的改動完成後續開發工作。前後端都要按照規范進行開發，針對不規范的地方要給與提出、指正，營造出規范的工作模式，以後維護成本和溝通成本更低以及開發效率更高。如果前端的設計進度遠遠超前後端的介面和數據結構設計，也不必等後端，可以自行開發nodejs伺服器配合postman等介面軟體進行開發。
前後端功能聯調、完成自測。檢查功能完成情況，看是否有遺漏，出現問題及時溝通解決。
2.3 測試階段
發布測試、修改bug、發布上線，自測完成後提交測試，測試根據提交的項目以及需求進行測試，提出bug給相關人員修改，開發人員周期性的配合修改bug，保證今天能夠修復昨天的bug。
發布dev環境，配合測試，修復bug以及需求優化
發布test環境，修復bug以及需求優化
發布it環境，修復bug以及需求優化
發布pre環境，修復bug以及需求優化
pre驗收之後，發布線上環境，產品進行驗收
2.4 維護階段
如果客戶驗收通過，項目就進入了維護階段，程序的維護包括程序上線後後續bug的修復和程序版本的更新。
3 個人經驗總結
3.1 文檔很重要
前端項目的文檔似乎已經作為前端工程化的標准流程之一了，文檔寫的好，可以便於同事快速了解你的代碼功能和需求，便於協作。可以想像，隨之項目復雜度增加，體量越來越龐大，開發團隊人數也越來越多。這種情況下，如果像變魔術一樣隱匿中間流程而直接得出結果，後果可想而知：項目復雜度越增加就越難以管理，開發效率低，合作混亂，結果甚至導致項目死亡。
好的文檔看起來就像一個產品說明書，但作用卻遠遠超過了說明書，不僅僅告訴你如何使用，還應該告訴你項目的設計思路，用了哪些組件，哪些部分不完善，將來有什麼規劃等等。這是一份比較好的說明文檔。
3.2 與客戶及時溝通很重要
3.3 扎實的基本功很重要
盡管當下框架、函數庫、工具包等更新迭代非常快，前端工程師有很多新的知識要學，但原生JS、HTML和CSS依然是重要的基本功，在學習前沿工具的同時不能放棄基本功的訓練。
❾ 前後端介面對接規范（主要前端內容）.md
前後端分離意味著，前後端之間使⽤ JSON 來交流，兩個開發團隊之間使⽤ API 作為契約進⾏交互。從此，後台選⽤的技術棧不影響前台。當我們決定需要前後端分離時，我們仍然還需要⾯對⼀系列的問題：
RESTful API 統一約束客戶端和伺服器之間的介面。簡化和分離系統架構，使每個模塊獨立！
REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種 軟體架構 風格。它是一種針對 網路應用 的設計和開發方式，可以降低開發的復雜性，提高系統的可伸縮性。 REST是設計風格而不是標准。 REST通常基於使用 HTTP ，URI，和 XML （ 標准通用標記語言 下的一個子集）以及 HTML （標准通用標記語言下的一個應用）
統一介面約束定義客戶端和伺服器之間的介面。它簡化了分離的結構，使各部分獨立發展。
REST要求狀態要麼被放入資源狀態中，要麼保存在客戶端上。或者換句話說，伺服器端不能保持除了單次請求之外的，任何與其通信的客戶端的通信狀態。 從客戶端的每個請求要包含伺服器所需要的所有信息。 這樣做的最直接的理由就是可伸縮性—— 如果伺服器需要保持客戶端狀態，那麼大量的客戶端交互會嚴重影響伺服器的內存可用空間（footprint）。
伺服器返回信息必須被標記是否可以緩存，如果緩存，客戶端可能會重用之前的信息發送請求。
客戶端無需關注數據存儲，伺服器端無需關注用戶界面，提高了前後端可移植性。
客戶端不關心直接連接到最終伺服器還是連接到中間伺服器。中間伺服器可以通過啟用負載平衡和提供共享緩存來提高系統可擴展性。分層系統也可以執行安全策略。
伺服器可以通過傳輸邏輯來臨時擴展或定製客戶端的功能。
GET https//domain.com/api/{模塊名}/{?菜單名}/{介面名}/:param
說明：
被用於獲取資源。不允許對伺服器上資源做任何修改操作。
示例：
常用於更新資源。通過請求體攜帶資源發送給伺服器。 注意： 在資源ID由客戶端而不是由伺服器選擇的情況下，也可以使用PUT來創建資源。修改成功返回200，創建成功返回201。 建議使用post進行創建新資源。
常用於創建新資源。創建成功通常返回201。
刪除資源。
status說明
---------------------------------------------------------------------------分割線-----------------------------------------------------------
請求方式：POST
參數:說明
返回值：
示例1
正確的
錯誤的
❿ 前端規范一（命名規范）
前端規范一（命名規范）
1、小駝峰命名法（lowerCamelCase） ：第一個單詞以小寫字母開始，第二個單詞的首字母大寫，例如：firstName、lastName。
2、大駝峰命名法（CamelCase） ：每一個單詞的首字母都採用大寫字母，例如：FirstName、LastName。
3、下劃線命名法（snake_case）：下劃線命名法也叫蛇形法，全由小寫字母和下劃線組成，在兩個單詞之間用下滑線連接。例如：first_name。
4、中劃線命名法（kebab-case）：中劃線命名法也叫串式命名法，各個單詞之間通過下劃線「-」連接。例如：first-name。
強制使用：中劃線命名法
命名規則：1、文件名不得含有空格
2、文件名建議只使用小寫字母，不使用大寫字母
3、文件名包含多個單詞時，單詞之間建議連詞線 ( - ) 分隔
4、有復數結構式，要使用復數
示例：login 、 error-page、 icons
強制使用：全部大寫字母
為了醒目，某些說明文件的文件名，可以使用大寫字母
示例：README
補充說明: README 標准
◎ 項目簡介。
◎ 注意事項。
◎ 線上的示例地址（測試、正式）。
◎ 支持運行的環境。
◎ 必要的依賴准備，以及如何搭建。
◎ 項目的安裝指南。
◎ 相關的文檔鏈接。
◎ 相關人員的聯系方式。
README.md 示例：
強制使用：小駝峰命名法
命名規則：前綴為動詞，見名知意
1、onXxx 監聽事件的回調
2、handleXxx 處理事件
3、getXxx 獲取某個值
4、setXxx 設置某個值
常見場景：
a、事件處理：
(1).事件主動監聽採用 onXxx ,被動處理使用handleXxx
示例：onXxxSubmit: '提交表單'
handleXxxSizeChange: '處理分頁頁數改變'
handleXxxPageChange: '處理分頁每頁大小改變'
onXxxKeydown: '按下鍵'
(2). 其他命名：元素+click、 元素+change、select+范圍
示例：selectAllXxx: '選擇所有'
xxxCellClick: '當某個單元格被點擊時會觸發該事件'
xxxSortChange: '當表格的排序條件發生變化的時候會觸發該事件'
b、增刪改查處理：
增: addXxx 添加子項
createXxx 創建大項
刪: deleteXxx 真刪除
removeXxx 偽刪除
改：updateXxx
查: getXxx 獲取原始數據需要修改
fetchXxx 原始數據
示例：getUserList: '獲取用戶列表', fetchToken: '取得Token', deleteUser: '刪除用戶', removeTag: '移除標簽', updateUserInfo: '更新用戶信息', addUser: '添加用戶', createAccount: '創建賬戶'
c、API介面函數：
get: getXxxApi
post: postXxxApi
patch: patchXxxApi
delect: delectXxxApi
域名：xxxUrl
一般屬性變數 強制使用：小駝峰命名法
1、布爾值
命名規則：前綴為判斷性動詞
hasXxx 判斷是否含有某個值。true：含有此值； false：不含有此值
isXxx 判斷是否為某個值。true：為某個值； false：不為某個值
示例：isShow: '是否顯示', isLoading: '是否處於載入中'， hasToken: '是否包含Token',
2、數組命名
命名規則：使用名詞+List組合
示例: userList: '用戶列表'
3、私有屬性變數
命名規則：前綴為下劃線(_)後面和變數命名一樣。
4、枚舉變數 \textcolor{red}{強制使用：大駝峰命名法}
枚舉的屬性使用全大寫字母，單詞間用下劃線隔開。
示例：let TargetState = { READING: 1, READED: 2, APPLIED: 3, READY: 4 };
5、常量： 強制使用：使用全大寫字母，單詞間用下劃線隔開
強制使用：大駝峰命名法
命名規則： 可參考vue官網風格指南
例如： 1、按照功能來命名
2、應用特定樣式和約定的基礎組件 (也就是展示類的、無邏輯的或無狀態的組件) 應該全部以一個特定的前綴開頭，比如 Base、App 或 V。
3、組件名應該以高級別的 (通常是一般化描述的) 單詞開頭，以描述性的修飾詞結尾。
示例：components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue
強制使用: 中劃線命名法
命名規則：
1.class、id 、標簽、屬性的命名應該盡量精短、明確，必須以字母開頭命名，且全部字母為小寫，單詞之間統一使用中劃線 「-」 連接
2.class必須代表相應模塊或部件的內容或功能，不得以樣式信息進行命名。
3.元素 id 必須保證頁面唯一。
4.禁止創建無樣式信息的 class
示例：
1、盡量不要縮寫、簡寫的單詞。除了 template => tmp、message => msg、image => img、property => prop 這些單詞已經被公認的縮寫
2、可讀性強的命名優先於簡短的命名
3、命名長度最好在 20 個字元以內，避免多長帶來的閱讀不便
4、命名要有具體的含義，避免使用一些泛指和無具體含義的詞
5、不要使用拼音，更不要使用中文
6、正則表達式用 Exp 結尾
7、ref：使用Ref結尾