? ? ? ? 此文為惠裝網(wǎng)前端leader姜姜傾力奉獻饥脑，我轉(zhuǎn)載分享而已阿蝶。技術(shù)無好壞合適就好，分享無對錯真誠就好柬甥！
? ? ? ? 雖然每次總結(jié)都是一把辛酸淚饮六，但是實踐出真知，趟過走過才知水深水淺苛蒲，不為分享只為記錄曾經(jīng)的青春卤橄。
– 小程序
小程序1.0.0
18年3月- 惠裝小程序1.0.0上線，主要的功能就是惠裝app分享到微信的承載臂外，包含首頁窟扑、紅包、文章漏健、日記嚎货、帖子、美圖展示蔫浆、裝修計算器（下工長訂單）等頁面殖属。
從拿到需求原型設(shè)計稿到上線，僅僅用了三天瓦盛。小程序是微信全新定義的規(guī)范洗显，團隊成員雖然之前都學(xué)習(xí)過，但并沒有實際的項目開發(fā)經(jīng)驗谭溉。 除了首頁墙懂，其他的頁面都是采用web-view組件，內(nèi)嵌的h5 扮念。web-view 組件僅開放給企業(yè)級的小程序使用损搬，個人開發(fā)的小程序是無法使用的。 這使得我們可以利用之前的h5頁面柜与，快速搭建惠裝小程序巧勤。
后來我們發(fā)現(xiàn)，小程序的體驗真的很好弄匕，加載速度颅悉，運行流暢度比起普通原生的App也不遜多少，甚至用戶根本感覺不到差距,當(dāng)然內(nèi)嵌的h5還是依然需要一個加載過程迁匠。微信提供了豐富的原生API剩瓶，比如用戶信息驹溃、設(shè)備信息、本地存儲延曙、地圖豌鹤、拍照、消息枝缔、支付布疙，等等，可以實現(xiàn)很多h5無法實現(xiàn)的功能愿卸。
小程序2.0
之前的1.0是小打小鬧試水小程序灵临。這次才算是真的新開一條產(chǎn)品線了。長期維護一條產(chǎn)品線的成本不菲趴荸，我們得好好規(guī)劃了儒溉。
2.0版本加入了整個訂單流程，從開工到完工赊舶，用戶可以在小程序上面管理自己的裝修了睁搭。這次不能再大量的內(nèi)嵌h5了，加載h5速度慢笼平，會嚴(yán)重降低用戶體驗，失去了部分開發(fā)小程序的意義舔痪。
這次的開發(fā)時間相對比較充足寓调，在需求評審前一周，我們對技術(shù)選型進行了研究和討論锄码。
最先考慮的是結(jié)合之前的web框架的開發(fā)經(jīng)驗夺英，找一款類似的小程序開發(fā)框架，提高開發(fā)效率滋捶。經(jīng)過多方比較美團點評團隊出品的 mpvue 被選定作為重點研究對象痛悯。
在之前的web項目中，前端積累了豐富的Vue開發(fā)經(jīng)驗重窟，Mpvue是基于Vue開發(fā)的载萌，相當(dāng)于給Vue本身增加了開發(fā)微信小程序的能力，擁有Vue所有的開發(fā)體驗：組件化巡扇、支持?jǐn)?shù)據(jù)狀態(tài)管理扭仁、可以使用Npm，支持webpack厅翔。 甚至在理想的狀態(tài)下乖坠，可以一套代碼跑在多端：WEB、微信小程序刀闷、支付寶小程序熊泵、Native( 借助weex）仰迁。看起來很誘人顽分！可是我們最終沒有選擇它徐许。
各個端是存在一些比較明顯的差異性，不可真的能多端公用一套代碼怯邪；
從我們研究這個框架的demo來看绊寻，很多功能，還是要靠小程序本身提供的組件實現(xiàn)悬秉，Vue不可能搞定所有的事情澄步，所以我們饒不開對小程序原生開發(fā)的學(xué)習(xí)；
在相互有交叉的地方和泌，編譯起來很容易出錯村缸，解決這些問題需要對小程序原生開發(fā)規(guī)范和Vue都有深刻的理解，而我們的小程序開發(fā)經(jīng)驗顯然還很薄弱武氓；
我們回過頭來仔細研究小程序的開發(fā)框架梯皿，它提供了自己的視圖層描述語言 WXML 和 WXSS，以及基于JavaScript 的邏輯層框架县恕，并在視圖層與邏輯層間提供了數(shù)據(jù)傳輸和事件系統(tǒng)东羹，理解起來很容易，開發(fā)者可以方便的聚焦于數(shù)據(jù)與邏輯上忠烛。學(xué)習(xí)曲線比較平緩属提，上手還是比較容易的。
小程序本身的應(yīng)用場景美尸，注定了它的功能不可能像App一樣復(fù)雜冤议，我們開發(fā)的并不是一個大型應(yīng)用，原生提供的框架可以滿足產(chǎn)品需求师坎。
微信提供了一個專門的社區(qū)供小程序開發(fā)者學(xué)習(xí)交流恕酸，有官方人員回答開發(fā)者的問題。
原生開發(fā)的UI庫比較多胯陋，我們熟悉的weui也有小程序版本蕊温，試用過，還是很不錯的惶岭。
最終團隊內(nèi)部成員都傾向?qū)W習(xí)小程序原生開發(fā)語言寿弱，大家一起邊學(xué)習(xí)邊開發(fā)邊交流，相信沒有邁不過去的砍按灶。
11月份症革，12月份小程序又上線了兩個版本，新的功能和優(yōu)化正在不斷迭代鸯旁。 我們在原生開發(fā)的路上越走越遠…
– OA系統(tǒng)
任何一家公司都離不開OA系統(tǒng)噪矛。 OA系統(tǒng)在前端組的工作中占據(jù)了相當(dāng)大的一部分量蕊。
前端組開發(fā)的OA系統(tǒng)有：客服系統(tǒng)、電銷系統(tǒng)艇挨、運營管理系統(tǒng)残炮、財務(wù)系統(tǒng)、商家管理系統(tǒng)缩滨、員工管理系統(tǒng)势就、權(quán)限管理系統(tǒng)（已廢棄）、bi系統(tǒng)
1脉漏、開發(fā)OA是后臺的事
15年的時候苞冯，前端幾乎不參與OA系統(tǒng)的開發(fā)。 全部由后臺搞定侧巨。
2舅锄、從界面開發(fā)介入到前后端分離
16年，隨著前端組的發(fā)展司忱，前端參與到了AO系統(tǒng)的研發(fā)皇忿，負責(zé)靜態(tài)界面，以及部分動態(tài)加載的數(shù)據(jù)處理坦仍。 前端寫好界面鳍烁，打包發(fā)送給后臺php開發(fā)人員，由后臺來嵌入邏輯繁扎，發(fā)布上線老翘。
老版本的客服系統(tǒng)、已經(jīng)廢棄的權(quán)限管理系統(tǒng)都是采用這種模式锻离。
這是一種比較老式傳統(tǒng)的開發(fā)模式，后臺再嵌入邏輯代碼的過程中墓怀，常常會破壞原有的布局汽纠，需要前端協(xié)助聯(lián)調(diào)，效率低下傀履。
在后來的重構(gòu)和新系統(tǒng)的開發(fā)中虱朵，我們摒棄了這種開發(fā)模式。
協(xié)商定義了接口規(guī)范钓账，前后端共同維護接口wiki碴犬。前端需要展示的所有的數(shù)據(jù)都由前端向后臺發(fā)起請求調(diào)用。前端代碼單獨部署在服務(wù)器上面梆暮。 用戶訪問前端服務(wù)器獲取頁面服协，前端服務(wù)器再去訪問后臺服務(wù)器獲取數(shù)據(jù)。前后端開發(fā)徹底分離啦粹，各司其責(zé)偿荷，大大減少了聯(lián)調(diào)時間窘游。 當(dāng)然前端的任務(wù)也更重了。
3跳纳、組件化開發(fā)起步
16年底10月 產(chǎn)品研發(fā)部對OA系統(tǒng)發(fā)起了一輪梳理整合忍饰，當(dāng)時的OA系統(tǒng)：
在這次OA梳理整合過程中，結(jié)合Adminex和Bootstrap前端開發(fā)了一套UI組件寺庄，包含 列表艾蓝、對話框、表格斗塘、登陸赢织、表單、導(dǎo)航等逛拱。在財務(wù)系統(tǒng)敌厘、運營管理系統(tǒng)、客服系統(tǒng)中廣泛應(yīng)用朽合。
有了這套UI組件俱两，大大加快了研發(fā)效率。 新的頁面開發(fā)曹步，幾乎不需要寫前端樣式宪彩，直接拷貝組件，拼拼湊湊讲婚，一個頁面就出來了尿孔。至今任然有部分系統(tǒng)在使用這套UI。
當(dāng)然它也有一個致命的缺陷筹麸，它僅僅是一個UI組件活合，沒有對應(yīng)的邏輯處理。 對一個完整的組件來說物赶，這僅僅是一個半成品白指。但就是這樣一個半成品，我們也是為之付出了很多的時間酵紫。 組件的開發(fā)和維護是一個長期的大工程告嘲。
4、引入第三方組件Element
隨著OA需求越來越多奖地，之前我們自己開發(fā)的UI組件已經(jīng)不能滿足需求橄唬。前端急需一個成熟好用的OA組件，包含完整的UI界面和數(shù)據(jù)邏輯處理参歹。
17年初仰楚，從運營管理系統(tǒng)開始，我們引入了餓了么團隊開發(fā)的 Element。 這是一套基Vue的OA組件缸血，有著豐富的組件蜜氨、漂亮的UI、穩(wěn)定的維護團隊捎泻、成熟的社區(qū)飒炎、多款成功的應(yīng)該案例、中文文檔笆豁、自定義皮膚郎汪。在運營管理系統(tǒng)中試用兩個月后，這套組件被我們應(yīng)用到了隨后開發(fā)的所有OA系統(tǒng)中闯狱。開發(fā)效率煞赢，進一步提高。前端幾個人力哄孤，支撐這么多的項目開發(fā)照筑，這套組件功不可沒。
另外一個意外的收貨瘦陈，就是這套組件讓團隊對vue的組件有了更深刻的理解凝危，提高了大家開發(fā)組件的能力。甚至一個只做重構(gòu)寫界面的前端同學(xué)晨逝，通過這套組件學(xué)會了邏輯開發(fā)蛾默。
當(dāng)然這世上沒有完美的事，Element升級到2.0以后捉貌，不再向下兼容這導(dǎo)致新版本的功能支鸡，我們都無法使用〕们裕可是新版本有著更漂亮的ui和一些更實用的功能牧挣，我們無法舍棄。為此我們采取了以下措施：
1醒陆、同一套系統(tǒng)中浸踩，新舊版本并存， 新開發(fā)的頁面使用新版本统求；
2、使用自定義皮膚据块，讓新老版本UI表現(xiàn)一致码邻；
3、進行二次組件封裝另假；
在這個過程中像屋，我們也受了一些折磨，走了一些彎路边篮。 最直接的表現(xiàn)就是UI不一致己莺，比如同一個系統(tǒng)中存在多種時間選擇器奏甫。 同時，我們也重構(gòu)了部分重要頁面凌受。
5阵子、我們自己的OA組件
Element 是一個受眾廣泛的組件，所以它的組件顆粒很細胜蛉，可以搭建各種各樣的應(yīng)用挠进。 但我們開發(fā)的是自己的OA系統(tǒng)，功能很多都是重復(fù)的誊册。我們需要顆粒更大的組件领突。
18年，在bi系統(tǒng)重構(gòu)的過程中案怯，我們根據(jù)需求原型君旦，基于Element封裝了一系列的大組件，加上自己研發(fā)的城市選擇等組件一起組合成了新的Bi嘲碱。 真正使得bi系統(tǒng)的前端開發(fā)就像搭積木一樣金砍。
可惜，這種操作是不可復(fù)制的悍汛。 因為bi系統(tǒng)太特殊了捞魁，它的每個頁面交互都非常的一致。
嘗到甜頭的前端們离咐，是不可能就此停止的谱俭。我們根據(jù)現(xiàn)有的OA系統(tǒng)，把握顆粒大小平衡宵蛀，封裝了一套惠裝OA組件庫昆著。 并且搭建了惠裝私有npm庫，解決了組件跨項目使用的維護問題术陶。
這套組件現(xiàn)在正在圖上的四個系統(tǒng)中跑著凑懂。
今年前端人員流失，以及大家轉(zhuǎn)向研究小程序的熱情梧宫，這套UI庫已經(jīng)有幾個月沒有更新了接谨。
6、OA歷史問題
隨著OA越來越龐大塘匣，使用的時間的增加脓豪，一些之前不是問題的也變成了問題。比較突出的就是某些功能上線使用不到幾個月就廢棄忌卤，甚至還有從來沒使用過的功能扫夜。這是產(chǎn)品規(guī)劃層面的問題，不多說。
技術(shù)層面說一點笤闯。OA編輯文章使用的是html富文本編輯器堕阔，html富文本在h5里面可以得到很好的呈現(xiàn)，但是app原生和小程序都不支持颗味。 文章詳情頁我們本來是打算全部原生化超陆，正是這個原因，內(nèi)容部分不得不內(nèi)嵌h5脱衙，小程序只能完全內(nèi)嵌h5侥猬。其實圖文結(jié)合就可以滿足絕大多數(shù)的應(yīng)用場景了，文章編輯以json格式保存捐韩，可以支持絕大多數(shù)端的前臺展示退唠。不得不背的歷史包袱。
7荤胁、移動端OA系統(tǒng)
最早的移動端OA系統(tǒng)是飽受大家詬病的“分站管理系統(tǒng)”（現(xiàn)在已經(jīng)廢棄瞧预，取而代之的是工長App和服務(wù)商App）。16年的時候仅政，前端可以說沒有使用什么技術(shù)框架垢油。 靜態(tài)頁面加上jquery 的ajax 拉取數(shù)據(jù)，操作Dom渲染數(shù)據(jù)圆丹。加上開發(fā)這個系統(tǒng)的人之前根本沒有相關(guān)經(jīng)驗滩愁，連普通的編程思維都沒有，做出來的東西辫封，別說性能了硝枉，連基本的可以使用都做不到。 對于技術(shù)人員來說倦微，實際項目妻味，還是要有多大能力做多大事，可以加一點挑戰(zhàn)欣福，如果全部都是挑戰(zhàn)责球，就無法保證項目的結(jié)果了。學(xué)習(xí)能力高一些的拓劝，可以多給一些挑戰(zhàn)雏逾，進步的快。 公司項目郑临，不是自己練手的demo校套，是有項目開發(fā)時間和質(zhì)量要求的。
當(dāng)年看起來難以完成的挑戰(zhàn)牧抵，如果放到現(xiàn)在，前端組可以很輕松的踩過去。我們進步了犀变。
18年妹孙，前端開發(fā)了電銷h5版本。 技術(shù)框架是 Vue全家桶（vue+ vuex +vuerouter）获枝，非常適合開發(fā)移動端的單頁應(yīng)用蠢正。 不僅開發(fā)速度快，應(yīng)用的相應(yīng)也非呈〉辏快嚣崭。 可惜我們選擇了一款不適合的UI框架：mint UI。 這個是餓了么團隊開發(fā)的移動端UI框架懦傍，我們之前使用過這個團隊開發(fā)的PC端的element雹舀，所以毫不猶豫的選擇了minit。 開發(fā)之前我們并沒有對Minit進行研究考察粗俱，而是直接上手说榆。電銷h5的開發(fā)時間總共不到一周，這回真是掉坑里了寸认。 這個UI框架的視覺和交互只能算一般般签财，跟PC端的element差了太多。 更重要的是時間選擇等插件偏塞，在表單中混用的時候唱蒸，總是出現(xiàn)各種界面錯位等bug，調(diào)試起來非常困難灸叼，電銷作為一個OA系統(tǒng)神汹，表單的存在無處不在，嚴(yán)重影響了開發(fā)效率怜姿。還有一系列跟mini相關(guān)的坑慎冤，我們都踩了，它真的不適合做移動端的ui框架沧卢。 最終上線的項目蚁堤，視覺上看著慘不忍睹，簡直不敢相信這是前端出品的東西但狭，沒臉了披诗。
即使是同一個團隊出品的框架，也不能盲目信任立磁；
適合別人不一定適合自己的項目呈队，從自己的項目出發(fā)去挑選；
每一個應(yīng)用到項目中的技術(shù)慎重對待唱歧，至少先出一版demo宪摧；
UI框架可能更重要粒竖，這是擺在面子上的東西，一毀毀所有几于；
– Node.js
node.js是跑在服務(wù)器上的js語言蕊苗。用Node.js開發(fā)Web服務(wù)器端，有幾個顯著的優(yōu)勢：
后端語言也是JavaScript沿彭，以前掌握了前端JavaScript的開發(fā)人員朽砰，現(xiàn)在可以同時編寫后端代碼；
前后端統(tǒng)一使用JavaScript喉刘，就沒有切換語言的障礙了瞧柔；
速度快，非衬郎眩快造锅！這得益于Node.js天生是異步的。
在Node.js誕生后的短短幾年里推沸，出現(xiàn)了無數(shù)種Web框架备绽、ORM框架、模版引擎鬓催、測試框架肺素、自動化構(gòu)建工具，數(shù)量之多宇驾，即使是JavaScript老司機倍靡，也不免眼花繚亂。感覺前端仿佛無所不能了课舍！
1塌西、thinkjs
16年前端開始搭建Node.js服務(wù)器，選擇了Thinkjs作為 運行在node端的框架筝尾，主要負責(zé)處理前端請求捡需，復(fù)雜的數(shù)據(jù)處理、記錄日志筹淫。
其實node端的框架很多站辉，Thinkjs算是小眾的。當(dāng)年選擇它损姜，我想最大的原因可能是它有詳細的中文文檔饰剥。使用到現(xiàn)在，其實我們連它30%的能力都沒有發(fā)揮出來摧阅。 很多復(fù)雜的邏輯已經(jīng)在后臺php那邊處理好了汰蓉。 再加上前端Vue實在是太好用了，曾經(jīng)規(guī)劃的node層處理數(shù)據(jù)邏輯也被拋棄棒卷，全都用vue在瀏覽器端處理了顾孽。
18年上半年祝钢，感覺thinkjs太重，同時眼熱其他的前端框架若厚，雄心勃勃的想研發(fā)前端3.0技術(shù)框架太颤。當(dāng)時重點研究了KOA，一個月的業(yè)余時間都泡在這上面盹沈，順帶著使用KOA + React + Redux 搭建了一個移動端demo項目。全新的框架吃谣，學(xué)習(xí)曲線非常陡乞封。習(xí)慣了Vue開發(fā)模式，很難理解React岗憋。 帶頭研究這個框架的童鞋還做了一期分享肃晚，最吸引人的就是頁面的前后端（服務(wù)器和瀏覽器端）同構(gòu)了。
研究了一個月的KOA仔戈，最大的感受就是這個框架太靈活了关串。什么都可以自定義。 但另一方面监徘，就是什么都沒有晋修，都需要自己寫。 跟Thinkjs這種各種功能都封裝好的框架凰盔，區(qū)別很大墓卦，上手難度也高。最終户敬，這套前端框架僅僅作為業(yè)余研究試水落剪，并沒有在實際項目中使用。原因有下：
1尿庐、全新框架忠怖，學(xué)習(xí)曲線陡；
2抄瑟、沒有不可替代的技術(shù)優(yōu)勢凡泣；
3、只能在全新項目中使用锐借，維護兩套框架成本高问麸；
2、webpack
我們的自動化構(gòu)建工具webpack也是運行在node上的钞翔。今年上半年严卖，花了很大力氣來配置這個工具，打造成完全適合我們自己的自動化構(gòu)建工具布轿。 選擇它哮笆，應(yīng)該是毫無爭議的来颤，易用而且強大。
弊端的話稠肘，實時編譯福铅，對電腦配置要求比較高。我們一般本地都開著兩個以上的項目项阴。 如果再開啟photoshop 這種大型圖片處理軟件滑黔，電腦簡直要卡死。嚴(yán)重影響開發(fā)效率环揽。 今年前端所有人都加了固態(tài)硬盤略荡，如果內(nèi)存再加一點就更好了。電腦配置升級歉胶，永遠趕不上我們的需求啊汛兜。 不要小看前端折騰的能力。
前文中提到的Npm私服也是運行在node上通今。沒有node.js粥谬，前端完全癱瘓。
線上的node是跑在Linux系統(tǒng)上的辫塌。 前端不懂Linux漏策，運維不懂node。 服務(wù)器時不時的異常報錯璃氢，解決起來有點吃力哟玷，特別是剛開始的時候。 前端沒有太多時間和精力去研究這塊內(nèi)容一也，線上的node服務(wù)器配置到底有沒有問題巢寡，我不知道，只知道能用椰苟。
– 惠裝App內(nèi)嵌h5
惠裝app從誕生起抑月，就從來沒有缺少過內(nèi)嵌h5。純展示的舆蝴，經(jīng)常變動的內(nèi)容都非常適合使用h5開發(fā)谦絮。不僅開發(fā)速度快，也可以快速迭代洁仗。對h5來說在App里面展示层皱，跟在瀏覽器中展示沒有本質(zhì)上的區(qū)別。
從15年到現(xiàn)在赠潦，累積了不少相關(guān)的研發(fā)經(jīng)驗叫胖。
比如h5需要能夠鑒別自己是否在app里面，我們使用過的方法如下：
1她奥、app通過url給h5傳參瓮增。 這種方法的弊端就是非常容易被偽造怎棱。也容易出錯帮坚，app開發(fā)人員忘記加appid的就歇菜了十减。
2潦闲、app提供相關(guān)的api松逊，比如getSystemInfo。 h5通過js來調(diào)用 api來獲取app相關(guān)信息诈铛。 這種方法需要app編寫對應(yīng)的api离福，h5主動調(diào)用仇祭。
3垦藏、使用userAgent吩谦。app內(nèi)嵌瀏覽器 userAgent 帶有特殊標(biāo)識，可以用于識別h5是否在app內(nèi)部加載的膝藕。 這是我門現(xiàn)在使用的方法。 開銷小咐扭，使用簡單芭挽。
App可以提供一系列的api供h5使用，以期讓h5獲得app的能力蝗肪，比如呼氣登錄袜爪、分享、查看大圖等等薛闪。為了長期維護使用辛馆，我們編寫了詳細的weik使用說明。這么幾年下來豁延，累積了不少api昙篙。 有些已經(jīng)廢棄不再使用了，應(yīng)該進行一輪梳理了诱咏。
開發(fā)app內(nèi)嵌的h5苔可，調(diào)試時一項費事費力的工作。受到電腦配置以及這種聯(lián)調(diào)工作只是一個低頻事件袋狞，前端沒有安裝app的開發(fā)工具焚辅。app在包里提供了一個專門給前端調(diào)試使用的界面，可以輸入前端頁面地址（一般是本機ip的頁面地址）苟鸯，來在app里面打開h5 同蜻。前端通過tips，抓包工具來調(diào)試頁面早处。這樣基本可以確定問題來源湾蔓。
原文首發(fā)在掰1掰大本營
