前端进阶之路: 前端架构设计(2)-流程核心
可能很多人和我一樣, 首次聽到"前端架構(gòu)"這個(gè)詞, 第一反應(yīng)是: "前端還有架構(gòu)這一說呢?" 在后端開發(fā)領(lǐng)域, 系統(tǒng)規(guī)劃和可擴(kuò)展性非常關(guān)鍵, 因此架構(gòu)師備受重視, 早在開發(fā)工作啟動之前, 他們就被邀請加入到項(xiàng)目中, 而且他們會跟客戶討論即將建成的平臺的架構(gòu)要求, 使用還什么技術(shù)棧? 內(nèi)容類型是什么? 這些內(nèi)容如何被創(chuàng)建?軟件架構(gòu)師的職責(zé)就是要保證項(xiàng)目中每一步都在總體架構(gòu)的指導(dǎo)下進(jìn)行, 而不會隨機(jī)決定.
現(xiàn)在的前端領(lǐng)域, 隨著JS框架, UI框架和各種庫的豐富, 前端架構(gòu)也變得十分的重要. 如果一個(gè)大型項(xiàng)目沒有合理的前端架構(gòu)設(shè)計(jì), 那么前端代碼可能因?yàn)椴煌拈_發(fā)人員隨意的引入各種庫和UI框架, 導(dǎo)致代碼量變得異常臃腫, 最終結(jié)果可能是代碼變得無法維護(hù), 頁面性能低下,不得已只能推翻重構(gòu). 所以我們需要在項(xiàng)目開始前, 同樣的需要對前端代碼進(jìn)行架構(gòu), 一旦前端架構(gòu)師設(shè)計(jì)出所有前端開發(fā)人員都要遵循的檢驗(yàn)機(jī)制, 建立起系統(tǒng)設(shè)計(jì)的規(guī)范, 那么項(xiàng)目就擁有了可以衡量代碼質(zhì)量的標(biāo)準(zhǔn), 前端開發(fā)人員也能享受到更高效的工作流. 所以, 前端架構(gòu)的定義可以用以下一句話來總結(jié):
前端架構(gòu)是一系列工具和流程的集合, 旨在提升前端代碼的質(zhì)量, 并實(shí)現(xiàn)高效, 可持續(xù)的工作流.本系列的前端架構(gòu)文章, 將分別圍繞前端架構(gòu)的四個(gè)核心展開, 分別是代碼, 流程, 測試, 文檔.
前端架構(gòu)的四個(gè)核心
(一) 代碼
歸根到底, 所有的網(wǎng)站都是由一堆文本文件和資源文件組成的. 當(dāng)我們面對制作網(wǎng)站所產(chǎn)生的大量代碼時(shí), 就會發(fā)現(xiàn)為代碼和資源設(shè)定一個(gè)期望是多么重要. 在代碼部分, 我們會專注于如果實(shí)現(xiàn)系統(tǒng)架構(gòu)中的HTML, CSS, JavaScript.
(二) 流程
現(xiàn)在早已過了FTP上傳文件的時(shí)代, 那么現(xiàn)在重要的是思考怎么用工具和流程構(gòu)建一個(gè)高效且避免出錯的工作流. 工作流變得越來越復(fù)雜, 那些用于它們的工具也同樣如此. 這些工具在提高生產(chǎn)力, 加快效率和保持代碼一致性上帶來了驚人的效果, 但也伴隨著過度工程化和抽象化的風(fēng)險(xiǎn). 所以, 現(xiàn)有的工作流是需要改變的.
(三) 測試
要構(gòu)建一個(gè)可擴(kuò)展和可持續(xù)優(yōu)化的系統(tǒng), 必須保證新代碼和老代碼能夠很好的兼容. 我們的代碼不會獨(dú)立存在, 它們都是大型系統(tǒng)中的一部分. 創(chuàng)建覆蓋面廣泛的測試方案, 能確保老代碼還能正常運(yùn)作.
(四) 文檔
一般而言, 如果不是團(tuán)隊(duì)中的重要成員要離開, 我們幾乎都不會意識到文檔的重要性. 等到那個(gè)時(shí)候, 大家將不得不停下手頭的工作, 優(yōu)先編寫所有的文檔. 作為前端機(jī)構(gòu)師, 你要善于在項(xiàng)目開發(fā)的同時(shí)編寫良好的文檔.
流程核心
現(xiàn)在的前端工作流程已經(jīng)發(fā)生了很大的改變, 最開始的Web開發(fā)階段, 一般的工作流程是根據(jù)郵件交流來理解客戶的需求, 然后通過FTP登錄他們的服務(wù)器, 對網(wǎng)站代碼做必要的修改. 這種做法是非常不成熟的. 如果誤解了郵件的內(nèi)容, 改錯了代碼, 會發(fā)生什么呢? 如果修改了一部分css代碼, 導(dǎo)致破壞了很多頁面的布局呢? 如果我改掉一個(gè)JavaScript的bug, 但又引發(fā)兩個(gè)bug呢?
經(jīng)過多年的項(xiàng)目開發(fā), 現(xiàn)在已有了一整套成熟的開發(fā)流程, 一般公司的開發(fā)流程為以下幾個(gè)步驟:
下面將分別從每個(gè)步驟討論其它們在現(xiàn)代化開發(fā)流程中的必要性:
(一)需求
提出需求是進(jìn)行開發(fā)的初始工作, PM提出了明確的需求后. FE(前端開發(fā)人員)才能進(jìn)行開發(fā). 當(dāng)然, 互聯(lián)網(wǎng)行業(yè)中對于提出需求是否需要開發(fā)人員參與討論是有不同的爭議的, 有的人認(rèn)為讓開發(fā)人員參與需求階段, 可能會因?yàn)殚_發(fā)人員的技術(shù)認(rèn)知水平和慣性思維等因素, 限制PM提出一個(gè)有創(chuàng)意的需求. 也有的人認(rèn)為應(yīng)當(dāng)讓開發(fā)人員參與需求討論, 因?yàn)榭赡芤驗(yàn)镻M完全不懂技術(shù), 導(dǎo)致提出根本無法實(shí)現(xiàn)的需求.
毫無疑問, PM比起開發(fā)人員更加懂得需求, 因?yàn)樗麄儠诟嬷_發(fā)人員需求之前完成需求收集, 需求描述, 需求全景圖, 需求分析, 用戶故事等一系列專業(yè)化的工作 . 但我贊同開發(fā)人員同時(shí)也在需求上能有一定的話語權(quán), PM在需求表達(dá)階段讓UI, FE, BE(后端開發(fā)人員)參與討論, 不僅能讓開發(fā)人員更好的理解需求, 也可能讓PM發(fā)現(xiàn)一些忽視的點(diǎn), 從而更好的提出一個(gè)完整的方案.
(二)原型
原型圖是現(xiàn)代開發(fā)流程中不可或缺的一環(huán), 它對于項(xiàng)目中的每個(gè)角色都有著重要的意義:
- PM進(jìn)行需求驗(yàn)證的方式: PM在使用Axure畫原型圖的過程也是自己構(gòu)思產(chǎn)品的過程, 經(jīng)過原型圖能夠使得PM更加的理解產(chǎn)品.
- 給需求方確認(rèn)需求的工具: PM理解的需求可能和需求方的需求是有出入的, 設(shè)計(jì)出原型圖作給需求方來驗(yàn)證需求的正確性是十分必要的.
- UI設(shè)計(jì)出設(shè)計(jì)圖的依舊: 原型幾乎有了整個(gè)界面的雛形, 拿到原型圖后, UI能夠更好的根據(jù)原型圖和PM討論其設(shè)計(jì)樣式, 更快的交付出設(shè)計(jì)圖給FE, 極大的降低了溝通成本.
- 開發(fā)人員開發(fā)的依據(jù): 初級的前端可能只會拿著設(shè)計(jì)圖進(jìn)行切圖, 很可能切完圖之后, 發(fā)現(xiàn)功能完全添加不進(jìn)去的情況. 有經(jīng)驗(yàn)的前端都會同時(shí)拿著設(shè)計(jì)圖和原型圖進(jìn)行開發(fā). 通過設(shè)計(jì)圖在寫html和css的同時(shí)通過原型圖去寫js的業(yè)務(wù)邏輯部分. 同時(shí), 原型圖也是后端開發(fā)人員提供業(yè)務(wù)接口的依據(jù).
- 測試人員測試的依據(jù): 作為一個(gè)現(xiàn)測試人員，可以從原型快速了解產(chǎn)品的核心功能，和頁面大致展現(xiàn)形式，方便測試人員提早了解需求，評估需求，制定測試計(jì)劃，分配測試任務(wù)，然后各自開始編寫測試用例
可以說, (一)(二)步驟是前端開發(fā)人員進(jìn)行開發(fā)的前提, 原型其實(shí)也是為項(xiàng)目中各角色更好的理解需求而服務(wù)的. 下面, 我以一個(gè)例子, 來解釋一下什么叫做真正的理解需求.
需求場景假設(shè)
加入現(xiàn)在有個(gè)論壇的項(xiàng)目, 產(chǎn)品經(jīng)理小C提了個(gè)需求"給論壇增加評論功能". 作為前端工程師的小A接到需求后, 該如何高質(zhì)量的完成這個(gè)需求?- 項(xiàng)目名稱: 興趣論壇
- 項(xiàng)目主要成員: 前端工程師小A, 后臺工程師小B, 產(chǎn)品經(jīng)理小C
- 產(chǎn)品需求: 給論壇增加評論功能.
此時(shí), 小A接到需求后, 腦海里可能浮現(xiàn)的是下面這張圖:
需求明確和需求確認(rèn)
可能一些同學(xué)聽到需求后, 就著手開始進(jìn)行開發(fā)了. 不就一個(gè)簡單的評論功能嗎? 一個(gè)<textarea>, 加個(gè)<button>, 在引入jQuery進(jìn)行ajax提交和DOM的操作就搞定了. 作為一名有經(jīng)驗(yàn)的前端開發(fā)人員,要明白的是實(shí)際的項(xiàng)目并不是像寫demo那么隨意, 我們寫出來的代碼是要部署到線上環(huán)境給用戶使用的. 所以, 面對"給論壇增加評論功能"這樣的不明確的需求,是還需要進(jìn)行需求明確和需求確認(rèn)的.
1. 需求明確
想想我們平時(shí)在論壇或者微博里面見到的評論功能, 就真的是上圖所顯示的這么一個(gè)簡單<textarea>和<button>就能夠搞定的嗎? 是不是評論可能還有以下的功能:
- 是否需要支持富文本輸入?
- 是否需要支持微博, 微信朋友圈, qq空間的評論分享
- 發(fā)表評論后, 評論如何展示?
也許經(jīng)過一番需求明確, 最終的需求會是下圖所示. 所以遇到需求不明確的情況, 一定要明確具體需求, 避免后期無意義的返工和延期.
2. 需求確認(rèn)
需求已經(jīng)明確了, 需要支持富文本輸入, 需要暫時(shí)評論, 這就足夠了嗎? 其實(shí)不夠, 作為一個(gè)有經(jīng)驗(yàn)的前端開發(fā)人員, 還有很多的細(xì)節(jié)需要確認(rèn), 比如:
- 評論最大支持輸入多少個(gè)字? (非常重要, 關(guān)乎后臺存儲方案的設(shè)計(jì))
- 一個(gè)中文字符算1個(gè)字, 還是2個(gè)英文字母算一個(gè)字? (產(chǎn)品語言, 技術(shù)語言之間的溝通轉(zhuǎn)換)
- 輸入內(nèi)容過長, 如何進(jìn)行錯誤提示?(交互細(xì)節(jié))
- 輸入內(nèi)容過長時(shí), 是否運(yùn)行提交評論? 如允許, 是對評論內(nèi)容進(jìn)行截?cái)嗪筇峤?(容錯機(jī)制)
- 用戶未輸入內(nèi)容的情況下, 評論框內(nèi)默認(rèn)提示文案是什么?(交互細(xì)節(jié))
- .......
一個(gè)評論功能可能需要明確的需求有很多, 這里就不在更多的贅述了, 從這個(gè)例子可以看出, 如果不是十分懂技術(shù)的PM, 是很難提出一個(gè)明確的需求的. 所以作為開發(fā)人員的我們, 在明確了需求之后還需要進(jìn)行需求確認(rèn), 而且可能是反復(fù)的進(jìn)行需求確認(rèn).
(三)開發(fā)
1. 本地部署
如果公司沒有一套標(biāo)準(zhǔn)的本地部署流程的話, 那么它會成為你敲代碼前花費(fèi)較多時(shí)間的一個(gè)部分, 可能包括拉取多個(gè)代碼庫, 配置服務(wù)器設(shè)置, 修改本機(jī)host或設(shè)置VPN. 不管流程是什么, 請一定要確保在README.md文件中說明每一步所對應(yīng)的操作, 確保新的工程師能夠很快的通過git clone xxx代碼之后, 就能夠?qū)⒋a在本地運(yùn)行起來. 千萬不要低估README.md文件的重要性, 一個(gè)清晰的README.md文件可以讓一個(gè)新入職的工程師在Git的遠(yuǎn)程倉庫上拉代碼之后幾分鐘就能運(yùn)行起來. 當(dāng)然, 對于一個(gè)依賴較多且配置項(xiàng)繁瑣的項(xiàng)目, 如果缺少一個(gè)清晰的README. md文件, 花費(fèi)幾天的時(shí)間才在本地環(huán)境跑起來也是不足為奇的.
2. 創(chuàng)建功能分支
在多人開發(fā)的項(xiàng)目中, 是絕對不允許你直接在master分支下進(jìn)行開發(fā)的, master分支有且只能用作保存上線版本的代碼, 在開發(fā)過程中, 應(yīng)該針對每個(gè)功能點(diǎn)通過git checkout -b newBranchName來創(chuàng)建一個(gè)新的功能分支, 在該功能分支上將該功能開發(fā)完畢并在本地進(jìn)行了自測之后, 再將該功能分支merge到dev分支上, dev分支主要用來合并功能分支代碼并交由測試人員進(jìn)行測試, 當(dāng)本次迭代所有的功能測試完畢之后, 才能夠?qū)ev分支上的代碼merge到master分支上, 并準(zhǔn)備上線.
3. 使用自動化工具(Gulp, Webpack等)
如果有一定工作年限的前端開發(fā)者, 那么一定經(jīng)歷過從Grunt轉(zhuǎn)移到Gulp, 并在近兩年轉(zhuǎn)移到Webpack的過程. 這類的自動化工具, 能夠極大的優(yōu)化我們的工作流程, 幫助我們高效率的完成類似于自動刷新頁面, 壓縮CSS, JS和合并壓縮代碼等機(jī)械重復(fù)的體力活. 對于自動化工具對于開發(fā)人員的優(yōu)點(diǎn), 我看過下面這樣一句話說得很好:
每件事都是一個(gè)程序, 開發(fā)也像程序一樣, 每個(gè)步驟都是一段代碼, 當(dāng)開發(fā)規(guī)模隨著文檔, 代碼, 需求而增加時(shí), 重復(fù)的步驟變得越來越多. 此時(shí), 如果可以像抽象代碼一樣抽象出一些相同操作就可以大大提升開發(fā)效率. 因此, 出現(xiàn)了更多優(yōu)質(zhì)的工具來代替人工做一些不斷重復(fù)的開發(fā)以減少程序員的工作量.目前前端領(lǐng)域應(yīng)該使用得最多的兩個(gè)自動化工具就是Gulp和Webpack. 這兩者在功能上有一定的區(qū)別, Gulp是一個(gè)自動化構(gòu)建工具, 你可以通過豐富的插件在項(xiàng)目中自動的幫你執(zhí)行常見的任務(wù). Webpack是一個(gè)自動化打包工具, 通過一個(gè)入口文件, 將所有依賴的模塊打包成為一個(gè)js文件, 當(dāng)然你也可以通過code spliting將其切分為多個(gè)js文件, 按需加載以提高效率.
目前主流的前端框架(Vue, React和Angular)都是使用的Webpack進(jìn)行打包, 就目前的使用來看, 通過各種loader和plugins, 幾乎webpack能夠滿足所有的項(xiàng)目需求. 在前端架構(gòu)中, 由于項(xiàng)目工程化的要求, 使用gulp和webpack這類的自動化工具進(jìn)行項(xiàng)目的構(gòu)建是必須的.
(四)測試
測試是項(xiàng)目把關(guān)的最后一個(gè)環(huán)節(jié), 經(jīng)過了測試員這關(guān)才能把項(xiàng)目進(jìn)行驗(yàn)收上線. 現(xiàn)在國內(nèi)的網(wǎng)絡(luò)公司由于項(xiàng)目工期的要求, 對于測試這一塊, 大部分的做法還是雇傭能力水平一般的測試人員, 通過重復(fù)點(diǎn)擊運(yùn)行項(xiàng)目流程的方式進(jìn)行測試, 對于測試工具的使用較少. 目前其實(shí)已經(jīng)有了一批成熟的js測試工具, 例如Jasmine, Karma, Mocha, NightWatch.當(dāng)你開始為應(yīng)用程序規(guī)劃測試時(shí), 請記住以下幾條建議:
- 測試用例應(yīng)該在建站的同時(shí), 甚至在建站之前就開始編寫
- 測試代碼是真實(shí)的代碼, 應(yīng)該一起或立即提交到系統(tǒng)代碼庫中
- 必須在所有的測試用例通過后, 才能把代碼合并到主干中
- 在主干上運(yùn)行測試工具, 結(jié)果應(yīng)該都為通過才能上線
前端自動化測試的細(xì)節(jié)將在下一篇的文章中做詳細(xì)的探討, 這里我們只是強(qiáng)調(diào)測試在整個(gè)項(xiàng)目流程的必要性.
(五)上線
在測試通過之后, 一個(gè)項(xiàng)目的最后流程就是上線了. 上線時(shí)采用JenKins這類的持續(xù)集成工具進(jìn)行代碼部署是一個(gè)優(yōu)秀的架構(gòu)所必須的, 持續(xù)集成工具能夠在代碼發(fā)布到服務(wù)器前, 先對代碼進(jìn)行一些處理, 這意味著我們可以在Git上忽略那編譯后的資源. 以Vue的項(xiàng)目舉例, 我們上線前只需要將在dev上測試通過的代碼merge到master分支上, 在上傳到遠(yuǎn)程Git倉庫中. 在使用Jenkis進(jìn)行部署上線就行, 一旦配置過上線前的處理流程, Jenkins就能自動幫我執(zhí)行npm run build的操作并將build好的dist文件夾自動部署到服務(wù)器上.
友情鏈接
- 前端進(jìn)階之路: 前端架構(gòu)設(shè)計(jì)(1)-代碼核心
參考資料
總結(jié)
以上是生活随笔為你收集整理的前端进阶之路: 前端架构设计(2)-流程核心的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mybatis由浅入深day01_5my
- 下一篇： 关于数据结构（二）