快魚吃慢魚的商業(yè)時代窘面，生存法則就是 “快”！叽躯，而我今天要闡述的“快”所指的民镜，不只是單純的開發(fā)效率環(huán)節(jié)，同時也涵蓋了協(xié)作效率险毁、研發(fā)資源調(diào)度制圈、組織過程資產(chǎn)等部分組合在一起的整體效率問題
當聊起前端，很多人會覺得非常簡單畔况，隨便拿個記事本也可以做個頁面鲸鹦，很多人正是因為前端的低門檻才開始踏上前端之路，而現(xiàn)在跷跪，各大前端技術(shù)社區(qū)卻呈現(xiàn)一片迷茫之聲馋嗜，多少有志青年被迫淪為擺爛的碼農(nóng)，框架的使用者吵瞻，工具的使用者葛菇，在三天一新框架的行業(yè)內(nèi)卷下，哭喊著 學(xué)不動了橡羞，十年的經(jīng)驗眯停，水平卻停留在了工作后的第三年，而職業(yè)天花板肉眼可見——國內(nèi)鮮有研發(fā)負責人的崗位是由前端負責人擔任的卿泽。同時各大工廠都在哭喊：前端缺少人手莺债。
我曾和很多前端從業(yè)者聊過對這個行業(yè)的理解，最普遍的認知出奇的一致—— 易懂難精签夭，門檻低齐邦，天花板也低
讓我們不妨盤一盤整個的來龍去脈：
起初，只有原生代碼第租，前端修著各種Bug和背著無盡的兼容兼容問題艱難前行措拇。
接下來，非成鞅觯“幸運”的有了很多諸如JQuery之類的簡單又給力的各種前端庫丐吓，隨手就可以完成開發(fā)需求浅悉，普通的開發(fā)者要不了多久就成了一個團隊的主力開發(fā)者。
當一些人以為前端不過如此汰蜘，駐足享樂之時，前端領(lǐng)域卻以爆炸式的增長出現(xiàn)在各種論壇之宿，頭條和Twitter 上族操。
和每個新興的領(lǐng)域一樣，造山造神造輪子比被，前端也不再是美工和“頁面仔”們的玩具色难，很多服務(wù)端開發(fā)的人也踏入了這片新大陸，轟轟烈烈的跑馬圈地等缀，給力的推動了這個領(lǐng)域的發(fā)展枷莉。
oop 、設(shè)計模式尺迂、 MVC笤妙、前端模板、微服務(wù)噪裕、中間件各種服務(wù)端的陳舊的概念套在了前端的馬車上依然锃光瓦亮蹲盘，熠熠生輝 。
PC時代還沒有終結(jié)膳音，便進入了移動互聯(lián)網(wǎng)時代召衔，終端設(shè)備和交互方式同時發(fā)生了變化。
新的平臺新的時代祭陷，帶來了更多的商機苍凛，激烈的市場競爭也日以繼夜地進行著。
在這種背景下兵志，刀耕火種的編碼方式再也無法跟上激烈競爭的市場變化醇蝴。無數(shù)的舊有web項目，像磊高的鳥卵想罕，隨時都會崩塌哑蔫，沒人敢動。
我們開始重構(gòu)弧呐，同時也背負了就有項目的技術(shù)債務(wù)闸迷，還有來自移動端的各種新特性和兼容問題， 很多前端團隊曾一度被吐槽：
為什么一個小的需求俘枫，需要這么久腥沽？
技術(shù)的挑戰(zhàn)對于商業(yè)需求，是不可見的鸠蚪。我們能做的是今阳，找到瓶頸师溅，提高效率！
就像住宅盾舌，
以前住山洞. 只需要鋪點稻草墓臭。
現(xiàn)在我們要蓋摩天大樓，我們需要 工程化妖谴！
今天的話題就從工程效率開始：
- 工程效率
所謂提升效率窿锉，是一個相對概念，實際開發(fā)中膝舅，很多效率消耗是看不見的嗡载，卻占用很多的時間，藏匿了很多的風險仍稀，所以首要任務(wù)是找到瓶頸洼滚，再找個趁手的兵器去解決掉這些的重復(fù)且易出錯的流程。
shell ,grunt ,gulp , webpack, yeoman技潘，vite, rollup, parcel ......
這些是搭建前端自動化工作流的常用工具：
還遠不止這些遥巴，很多公司也都在做自己的構(gòu)建工具，毋庸細表享幽。
主要解決的是以下問題：
- 性能
前端自動化有很大一部分工作是為了性能挪哄，yahoo在很早以前就總結(jié)了前端的34條優(yōu)化原則。
```
1. 盡量減少 HTTP 請求次數(shù)
1. 減少DNS查找次數(shù)
1. 避免跳轉(zhuǎn)
1. 可緩存的 AJAX
1. 推遲加載內(nèi)容
1. 預(yù)加載
1. 減少DOM元素數(shù)量
1. 根據(jù)域名劃分頁面內(nèi)容
1. 使 iframe 的數(shù)量最小
1. 不要出現(xiàn) 404 錯誤
1. 使用內(nèi)容分發(fā)網(wǎng)絡(luò)
1. 為文件頭指定Expires或Cache-Control
1. Gzip壓縮文件內(nèi)容
1. 配置ETg
1. 盡早刷新輸出緩沖
1. 使用GET來完成AJAX請求
1. 把樣式表置于頂部
1. 避免使用CSS表達式(Expression)
1. 使用外部JavaScript和CSS
1. 削減JavaScript和CSS
1. 用代替@import
1. 避免使用濾鏡
1. 把腳本置于頁面底部
1. 剔除重復(fù)腳本
1. 減少 DOM 訪問
1. 開發(fā)智能事件處理程序
1. 減小Cookie體積
1. 對于頁面內(nèi)容使用無coockie域名
1. 優(yōu)化圖像
1. 優(yōu)化 CSS Spirite
1. 不要在 HTML 中縮放圖像
1. favicon.ico 要小而且可緩存
1. 保持單個內(nèi)容小于 25K
1. 打包組件成復(fù)合文本
````
這其中琉闪，很多都是可以在自動化工具的構(gòu)建過程中做到的迹炼，性能有了初步保障。
流程
一個項目在開發(fā)過程中存在很多流程颠毙，它們重復(fù)頻次高且容易出錯：創(chuàng)建項目
創(chuàng)建頁面
創(chuàng)建頁面相關(guān)資源
創(chuàng)建模塊
創(chuàng)建模塊相關(guān)資源
詳細設(shè)計
創(chuàng)建接口文檔
創(chuàng)建模擬接口
接口聯(lián)調(diào)
編譯
單元測試
推送至聯(lián)調(diào)機
提測
預(yù)上線
上線
回滾
監(jiān)控
協(xié)作
協(xié)作著重點是：與PM協(xié)作斯入，與后端協(xié)作
與PM協(xié)作：
前端團隊需要跟其他團隊緊密協(xié)作，溝通協(xié)作也是制約因素之一蛀蜜。在過去的項目中刻两，你是否經(jīng)理過由于溝通誤差導(dǎo)致的無效開發(fā)，甚至線上事故滴某。
我發(fā)現(xiàn)技術(shù)團隊正在忙碌的時候磅摹，產(chǎn)品團隊有新的需求往往又不知道我們的人力狀況，這對他在指定產(chǎn)品迭代計劃不利霎奢，導(dǎo)致PM單方面制定了很多不合理的“時間倒推型”項目户誓，研發(fā)團隊集體持續(xù)加班。實際上某些情況下本可以避免的幕侠，畢竟帝美，人困馬乏非常態(tài)用兵之道。
對于我們團隊的人力投入狀況晤硕，以及人力釋放的計劃悼潭，完全可以用工具 來顯示庇忌。進一步的，PM可以在此申請項目舰褪，申請人力皆疹。但前提是，團隊需要把技術(shù)架構(gòu)統(tǒng)一占拍，使得開發(fā)者更方便的跨越產(chǎn)品線做技術(shù)支持略就，對于業(yè)務(wù)的深刻理解實際上是一種組織過程資產(chǎn)，需要團隊內(nèi)部串講與共享刷喜。
與后端協(xié)作-前后端分離
互聯(lián)網(wǎng)伊始残制，并沒有如今這么明細的分工立砸，開發(fā)人員包辦了所有開發(fā)任務(wù)掖疮。
回看那時的業(yè)務(wù)形態(tài)，多半是 新聞系統(tǒng)颗祝，企業(yè)網(wǎng)站浊闪，還有就是BBS。界面和交互基本都是千篇一律螺戳。
直到web2.0概念興起搁宾，掛起了頁面重構(gòu)風，前后端的分工越來越明確倔幼。
時至今日盖腿，前后端分離變成了熱議的話題。
聯(lián)調(diào)過程一直是WEB開發(fā)的痛點损同，在工作流中集成解決方案翩腐，可以更快定位問題，減少溝通成本膏燃。
基于nodejs的SSR與服務(wù)層實踐：
很多公司都在行動茂卦。最典型的是“某寶、某里”公司组哩，nodejs接管了許多產(chǎn)品線的httpserver等龙，做業(yè)務(wù)接口聚合，越來越多的服務(wù)端邏輯伶贰，被前端團隊接管蛛砰。后端變成了純粹的數(shù)據(jù)輸出層。
筆者曾在某浪公司也推動過nodejs的前后端分離解決方案黍衙，遇到了一些阻力暴备。 究其原因是多方面的：
服務(wù)端編程并非掌握一門服務(wù)端語言這么簡單，前端團隊的服務(wù)端開發(fā)基本技能不夠扎實们豌。
nodejs的人力來自前端團隊涯捻，但就我所在的團隊而言浅妆，短時間內(nèi)并不是每個前端都可以勝任服務(wù)端開發(fā)。開發(fā)和維護都容易出現(xiàn)人力瓶頸（曾經(jīng)就有杭州的一個nodejs項目接過來以后變成了爛尾障癌，后來還是被改回了php）
技術(shù)負責人鮮有nodejs語言和項目的把控能力凌外，一旦項目出現(xiàn)技術(shù)瓶頸，將很難把控涛浙。
原本后端的工作交接給前端來做康辑，后端剩余人力又當如何安排？當然轿亮，也考慮過請后端的同學(xué)學(xué)習使用nodejs疮薇，但收效甚微。也許是他們找不到理由學(xué)習和使用nodejs我注。
這種架構(gòu)雖然在有歷史架構(gòu)包袱的公司很難普及按咒。但是一些新團隊大膽的采用nodejs堆棧，推行全棧工程師文化（這里的全棧僅僅等于client端+server端開發(fā)但骨，更深的全棧是不局限語言的励七，不同的需求，采用不同的技術(shù)解決方案）奔缠。
不過也有落地成功的掠抬，比如某知名技術(shù)社區(qū)“某SDN”使用nodejs支撐了全站消息通知服務(wù)。某“出行巨頭“公司校哎，甚至用nodejs支撐了整個金融系統(tǒng)的券服務(wù)與活動系統(tǒng)两波。
充分說明了，不是語言的問題闷哆，事在人為腰奋。
基于其它服務(wù)端語言的SSR：
筆者曾有幸在某度工作過兩年，當時的前后端分離方案是基于前端寫php的starty模板阳准，前端開發(fā)需要依賴php環(huán)境氛堕。當然如果沒有別的方案，這樣的架構(gòu)當年也是跑的可以野蝇。只是溝通和成本變得昂貴讼稚。
某東電商的前后端分離也與此類似，只是京東是基于java的绕沈。寫的是java體系下的模板語言锐想。 好在京東的前端工程化把模板環(huán)境集成了進去，使用Nodejs就可以支撐java模板乍狐。做的比較完善赠摇。如同F(xiàn)is一樣，京東的前端團隊推出了 “jdf” 自成一體。（npmjs.com 上面可以搜索到）
相關(guān)的技術(shù)也在快速迭代—— 云函數(shù)藕帜、serverLess烫罩、graphQL
技術(shù)積累與知識共享
- 知識共享
做過業(yè)務(wù)開發(fā)的人，都知道洽故，每次的項目都會遇到一些奇葩的問題贝攒，尤其是前端領(lǐng)域，這種情況更普遍时甚。知識共享的目的是希望可以有一個地方搜索別人是否遇到同樣的問題
由于業(yè)務(wù)形態(tài)不同隘弊，在搜索引擎和stackoverflow未必能找到答案，所以需要我們自己的要有知識共享庫荒适，它將隨著時間推移避免更多人踩同樣的坑梨熙。
這在前端工程化里是個弱需求，但從長遠來看它刀诬，不可或缺咽扇。前端工作流最好提供一個更簡潔的方式，讓開發(fā)者可以快捷的提交到知識庫中舅列。后續(xù)可以在郵件收到關(guān)注問題的互動信息肌割。
-
組件生態(tài)
組件化卧蜓，也叫模塊化帐要，插件化，是一種分治思想弥奸。
組件化之路其實也是軟件世界的進化之路榨惠，前端亦是如此，從面相 對象編程到模塊化開發(fā)盛霎，越來越多的框架涌現(xiàn)赠橙，讓人目不暇接。
>我不想討論如何做模塊化開發(fā)愤炸，因為這不是工程化的重點期揪。
當你選中一個框架，決定將后續(xù)的業(yè)務(wù)代碼规个，按照它的規(guī)范進行模塊開發(fā), 那么問題來了：
- 如何提交這些組件
- 如何迭代組件版本
- 如何解決組件依賴
- 別人如何使用你的組件
- 一個標準的組件包含哪些部分
- 如何沉淀出優(yōu)秀組件
當你解決掉這些問題凤薛，我就認為你已經(jīng) 建立了一個組件生態(tài)環(huán)境
當項目以堆積木的方式開發(fā)，才能有诞仓。
前端自動化測試
前端的自動化測試一直都有爭議缤苫，問題癥結(jié)在于投入產(chǎn)出比，以及覆蓋率問題墅拭。
從工具方面其中涌現(xiàn)了許多給力的測試框架：
Mocha& Chai
JavaScript 在很長一段時間內(nèi)是非常煩人的活玲。測試任何代碼通常都被認為是惱人的，但它卻是每個開發(fā)人員都應(yīng)該做的事情。每個開發(fā)人員似乎總是蔑視和忽略它舒憾，而不測試他們的代碼镀钓。這個惱人的東西有一個解決辦法，那就是 Mocha 和 Chai镀迂。兩個庫的名字都來自美味的熱飲料掸宛，它們都能幫你測試代碼，但方式不同招拙。
Mocha 是一個 JavaScript 測試框架唧瘾，使得你在 node 模塊和瀏覽器 app 中測試異步代碼變得更容易。Mocha 測試可以串聯(lián)運行别凤，可以為正確的測試用例添加異常跟蹤的能力饰序。
Chai 是一個行為驅(qū)動開發(fā)/測試驅(qū)動開發(fā)的斷言庫，可以搭配 Mocha 使用规哪。它可以把你需要測試的東西用可讀的風格簡單地表達出來求豫。
何時使用 Mocha & Chai？總是诉稍！請測試你的代碼蝠嘉，讓世界變得更美好。
Karma
既然已經(jīng)把 Mocha 和 Chai 包含在這個列表中了杯巨，如果不包含用來運行這些測試或設(shè)置持續(xù)集成測試的測試運行器蚤告，那將是不完整的。Karma 是一款旨在幫助你在不同的瀏覽器上自動運行測試的工具服爷。它可以幫助你在所有瀏覽器上運行 Mocha 和 Chai 測試杜恰。
不是每個瀏覽器都運行在所有平臺，但幸運的是可以使用一些免費工具來測試其他瀏覽器仍源，看看 Browser Screenshots心褐。如果你正在 OS X 上運行代碼，想測試 Edge 或 IE笼踩，可以 免費 使用這個工具逗爹。
在前端工具中，的每次編譯任務(wù)集成自動測試使得每一次的修改更加放心嚎于，但是掘而，很顯然這里面有個測試用例和覆蓋率的成本問題，這是一個博弈的過程.
我的想法是不推薦在所有業(yè)務(wù)代碼中都去寫測試用例匾旭，只在通用性較強和比較關(guān)鍵的镣屹，重復(fù)迭代的模塊中使用。
開源貢獻
不重復(fù)造輪子价涝！除非你的輪子是革命性的女蜈。
在這個技術(shù)領(lǐng)域“物產(chǎn)豐富”的時代，往往會發(fā)現(xiàn)互聯(lián)網(wǎng)上能找到很多你原本想要自己做的東西，你唯一需要考慮的是如何使用伪窖，如何按照自己需求去迭代逸寓。
開源是這個時代最好的禮物，可以通過開源快速滿足項目需求覆山，交流技術(shù)竹伸，認識更多更優(yōu)秀的人。
如今對于程序員的社交平臺 非github莫屬了簇宽。
一個高產(chǎn)的團隊勋篓，不僅要滿足業(yè)務(wù)需求，還需要有開源精神魏割。
不但要把自己團隊產(chǎn)出的資源共享譬嚣，也需要與你使用的開源項目一起迭代，積極提交PR（pull request）
github如今也變成了招聘技術(shù)人才的絕佳平臺钞它，從他的代碼上基本可以基本了解這個人的技術(shù)能力拜银，甚至性格和追求。
代碼審查
關(guān)于代碼審查遭垛，很多團隊都表示難成其重尼桶，成本太高。作為學(xué)習使用锯仪。
也有作為開發(fā)流程的一部分泵督，強制執(zhí)行的。
在這里卵酪，我想談的是幌蚊，如何建立一份代碼審查清單:
常規(guī)項
代碼能夠工作么谤碳？它有沒有實現(xiàn)預(yù)期的功能溃卡，邏輯是否正確等。
所有的代碼是否簡單易懂蜒简？
代碼符合你所遵循的編程規(guī)范么瘸羡？這通常包括大括號的位置，變量名和函數(shù)名搓茬，行的長度犹赖，縮進，格式和注釋卷仑。
是否存在多余的或是重復(fù)的代碼峻村？
代碼是否盡可能的模塊化了？
是否有可以被替換的全局變量锡凝？
是否有被注釋掉的代碼粘昨？
循環(huán)是否設(shè)置了長度和正確的終止條件？
是否有可以被庫函數(shù)替代的代碼？
是否有可以刪除的日志或調(diào)試代碼张肾？
安全
所有的數(shù)據(jù)輸入是否都進行了檢查（檢測正確的類型芭析，長度，格式和范圍）并且進行了編碼吞瞪？
在哪里使用了第三方工具馁启，返回的錯誤是否被捕獲？
輸出的值是否進行了檢查并且編碼芍秆？
無效的參數(shù)值是否能夠處理惯疙？
文檔
是否有注釋，并且描述了代碼的意圖妖啥？
所有的函數(shù)都有注釋嗎螟碎？
對非常規(guī)行為和邊界情況處理是否有描述？
第三方庫的使用和函數(shù)是否有文檔迹栓？
數(shù)據(jù)結(jié)構(gòu)和計量單位是否進行了解釋掉分？
是否有未完成的代碼？如果是的話克伊，是不是應(yīng)該移除酥郭，或者用合適的標記進行標記比如‘TODO’？
測試
代碼是否可以測試愿吹？比如不从，不要添加太多的或是隱藏的依賴關(guān)系，不能夠初始化對象犁跪，測試框架可以使用方法等椿息。
是否存在測試，它們是否可以被理解坷衍？比如寝优，至少達到你滿意的代碼覆蓋(code coverage)。
單元測試是否真正的測試了代碼是否可以完成預(yù)期的功能枫耳？
是否檢查了數(shù)組的“越界“錯誤乏矾？
是否有可以被已經(jīng)存在的API所替代的測試代碼？
你同樣需要把特定語言中有可能引起錯誤的問題添加到清單中迁杨。
這個清單故意沒有詳盡的列出所有可能會發(fā)生的錯誤钻心。你不希望你的清單是這樣的，太長了以至于從來沒人會去用它铅协。僅僅包含常見的問題會比較好捷沸。
優(yōu)化你的清單
把使用清單作為你的起點，針對特定的使用案例狐史，你需要對其進行優(yōu)化痒给。一個比較棒的方式就是讓你的團隊記錄下那些在代碼審查過程中臨時發(fā)現(xiàn)的問題坯钦，有了這些數(shù)據(jù)，你就能夠確定你的團隊常犯的錯誤侈玄，然后你就可以量身定制一個審查清單婉刀。確保你刪除了那些沒有出現(xiàn)過的錯誤。（你也可以保留那些出現(xiàn)概率很小序仙，但是非常關(guān)鍵的項目突颊，比如安全相關(guān)的問題）。
得到認可并且保持更新
基本規(guī)則是潘悼，清單上的任何條目都必須明確律秃，而且，如果可能的話治唤，對于一些條目你可以對其進行二元判定棒动。這樣可以防止判斷的不一致。和你的團隊分享這份清單并且讓他們認同你清單的內(nèi)容是個好主意宾添。同樣的船惨，要定期檢查你的清單，以確保各條目仍然是有意義的缕陕。
有了一個好的清單粱锐，可以提高你在代碼審查過程中發(fā)現(xiàn)的缺陷個數(shù)。這可以幫助你提高代碼標準扛邑，避免質(zhì)量參差不齊的代碼審查怜浅。
小結(jié)
高產(chǎn)的前端團隊，最終還是取決于人蔬崩，工具自動化恶座，組件的生態(tài)，質(zhì)量把控沥阳， 這一系列的努力跨琳，才能讓一個團隊保持激情和戰(zhàn)斗力。
開源社區(qū)的使用沪袭、互動和參與迭代湾宙，甚至走出公司做技術(shù)交流的活動，讓團隊技術(shù)視野保持在業(yè)界水準冈绊。
