此文为惠装网前端leader姜姜倾力奉献，我转载分享而已。技术无好坏合适就好，分享无对错真诚就好！
虽然每次总结都是一把辛酸泪，但是实践出真知，趟过走过才知水深水浅，不为分享只为记录曾经的青春。
– 小程序
小程序1.0.0
18年3月- 惠装小程序1.0.0上线，主要的功能就是惠装app分享到微信的承载，包含首页、红包、文章、日记、帖子、美图展示、装修计算器（下工长订单）等页面。
从拿到需求原型设计稿到上线，仅仅用了三天。小程序是微信全新定义的规范，团队成员虽然之前都学习过，但并没有实际的项目开发经验。 除了首页，其他的页面都是采用web-view组件，内嵌的h5 。web-view 组件仅开放给企业级的小程序使用，个人开发的小程序是无法使用的。 这使得我们可以利用之前的h5页面，快速搭建惠装小程序。
后来我们发现，小程序的体验真的很好，加载速度，运行流畅度比起普通原生的App也不逊多少，甚至用户根本感觉不到差距,当然内嵌的h5还是依然需要一个加载过程。微信提供了丰富的原生API，比如用户信息、设备信息、本地存储、地图、拍照、消息、支付，等等，可以实现很多h5无法实现的功能。
小程序2.0
之前的1.0是小打小闹试水小程序。这次才算是真的新开一条产品线了。长期维护一条产品线的成本不菲，我们得好好规划了。
2.0版本加入了整个订单流程，从开工到完工，用户可以在小程序上面管理自己的装修了。这次不能再大量的内嵌h5了，加载h5速度慢，会严重降低用户体验，失去了部分开发小程序的意义。
这次的开发时间相对比较充足，在需求评审前一周，我们对技术选型进行了研究和讨论。
最先考虑的是结合之前的web框架的开发经验，找一款类似的小程序开发框架，提高开发效率。经过多方比较美团点评团队出品的 mpvue 被选定作为重点研究对象。
在之前的web项目中，前端积累了丰富的Vue开发经验，Mpvue是基于Vue开发的，相当于给Vue本身增加了开发微信小程序的能力，拥有Vue所有的开发体验：组件化、支持数据状态管理、可以使用Npm，支持webpack。 甚至在理想的状态下，可以一套代码跑在多端：WEB、微信小程序、支付宝小程序、Native( 借助weex）。看起来很诱人！可是我们最终没有选择它。
各个端是存在一些比较明显的差异性，不可真的能多端公用一套代码；
从我们研究这个框架的demo来看，很多功能，还是要靠小程序本身提供的组件实现，Vue不可能搞定所有的事情，所以我们饶不开对小程序原生开发的学习；
在相互有交叉的地方，编译起来很容易出错，解决这些问题需要对小程序原生开发规范和Vue都有深刻的理解，而我们的小程序开发经验显然还很薄弱；
我们回过头来仔细研究小程序的开发框架，它提供了自己的视图层描述语言 WXML 和 WXSS，以及基于JavaScript 的逻辑层框架，并在视图层与逻辑层间提供了数据传输和事件系统，理解起来很容易，开发者可以方便的聚焦于数据与逻辑上。学习曲线比较平缓，上手还是比较容易的。
小程序本身的应用场景，注定了它的功能不可能像App一样复杂，我们开发的并不是一个大型应用，原生提供的框架可以满足产品需求。
微信提供了一个专门的社区供小程序开发者学习交流，有官方人员回答开发者的问题。
原生开发的UI库比较多，我们熟悉的weui也有小程序版本，试用过，还是很不错的。
最终团队内部成员都倾向学习小程序原生开发语言，大家一起边学习边开发边交流，相信没有迈不过去的砍。
11月份，12月份小程序又上线了两个版本，新的功能和优化正在不断迭代。 我们在原生开发的路上越走越远…
– OA系统
任何一家公司都离不开OA系统。 OA系统在前端组的工作中占据了相当大的一部分。
前端组开发的OA系统有：客服系统、电销系统、运营管理系统、财务系统、商家管理系统、员工管理系统、权限管理系统（已废弃）、bi系统
1、开发OA是后台的事
15年的时候，前端几乎不参与OA系统的开发。 全部由后台搞定。
2、从界面开发介入到前后端分离
16年，随着前端组的发展，前端参与到了AO系统的研发，负责静态界面，以及部分动态加载的数据处理。 前端写好界面，打包发送给后台php开发人员，由后台来嵌入逻辑，发布上线。
老版本的客服系统、已经废弃的权限管理系统都是采用这种模式。
这是一种比较老式传统的开发模式，后台再嵌入逻辑代码的过程中，常常会破坏原有的布局，需要前端协助联调，效率低下。
在后来的重构和新系统的开发中，我们摒弃了这种开发模式。
协商定义了接口规范，前后端共同维护接口wiki。前端需要展示的所有的数据都由前端向后台发起请求调用。前端代码单独部署在服务器上面。 用户访问前端服务器获取页面，前端服务器再去访问后台服务器获取数据。前后端开发彻底分离，各司其责，大大减少了联调时间。 当然前端的任务也更重了。
3、组件化开发起步
16年底10月 产品研发部对OA系统发起了一轮梳理整合，当时的OA系统：
在这次OA梳理整合过程中，结合Adminex和Bootstrap前端开发了一套UI组件，包含 列表、对话框、表格、登陆、表单、导航等。在财务系统、运营管理系统、客服系统中广泛应用。
有了这套UI组件，大大加快了研发效率。 新的页面开发，几乎不需要写前端样式，直接拷贝组件，拼拼凑凑，一个页面就出来了。至今任然有部分系统在使用这套UI。
当然它也有一个致命的缺陷，它仅仅是一个UI组件，没有对应的逻辑处理。 对一个完整的组件来说，这仅仅是一个半成品。但就是这样一个半成品，我们也是为之付出了很多的时间。 组件的开发和维护是一个长期的大工程。
4、引入第三方组件Element
随着OA需求越来越多，之前我们自己开发的UI组件已经不能满足需求。前端急需一个成熟好用的OA组件，包含完整的UI界面和数据逻辑处理。
17年初，从运营管理系统开始，我们引入了饿了么团队开发的 Element。 这是一套基Vue的OA组件，有着丰富的组件、漂亮的UI、稳定的维护团队、成熟的社区、多款成功的应该案例、中文文档、自定义皮肤。在运营管理系统中试用两个月后，这套组件被我们应用到了随后开发的所有OA系统中。开发效率，进一步提高。前端几个人力，支撑这么多的项目开发，这套组件功不可没。
另外一个意外的收货，就是这套组件让团队对vue的组件有了更深刻的理解，提高了大家开发组件的能力。甚至一个只做重构写界面的前端同学，通过这套组件学会了逻辑开发。
当然这世上没有完美的事，Element升级到2.0以后，不再向下兼容这导致新版本的功能，我们都无法使用。可是新版本有着更漂亮的ui和一些更实用的功能，我们无法舍弃。为此我们采取了以下措施：
1、同一套系统中，新旧版本并存， 新开发的页面使用新版本；
2、使用自定义皮肤，让新老版本UI表现一致；
3、进行二次组件封装；
在这个过程中，我们也受了一些折磨，走了一些弯路。 最直接的表现就是UI不一致，比如同一个系统中存在多种时间选择器。 同时，我们也重构了部分重要页面。
5、我们自己的OA组件
Element 是一个受众广泛的组件，所以它的组件颗粒很细，可以搭建各种各样的应用。 但我们开发的是自己的OA系统，功能很多都是重复的。我们需要颗粒更大的组件。
18年，在bi系统重构的过程中，我们根据需求原型，基于Element封装了一系列的大组件，加上自己研发的城市选择等组件一起组合成了新的Bi。 真正使得bi系统的前端开发就像搭积木一样。
可惜，这种操作是不可复制的。 因为bi系统太特殊了，它的每个页面交互都非常的一致。
尝到甜头的前端们，是不可能就此停止的。我们根据现有的OA系统，把握颗粒大小平衡，封装了一套惠装OA组件库。 并且搭建了惠装私有npm库，解决了组件跨项目使用的维护问题。
这套组件现在正在图上的四个系统中跑着。
今年前端人员流失，以及大家转向研究小程序的热情，这套UI库已经有几个月没有更新了。
6、OA历史问题
随着OA越来越庞大，使用的时间的增加，一些之前不是问题的也变成了问题。比较突出的就是某些功能上线使用不到几个月就废弃，甚至还有从来没使用过的功能。这是产品规划层面的问题，不多说。
技术层面说一点。OA编辑文章使用的是html富文本编辑器，html富文本在h5里面可以得到很好的呈现，但是app原生和小程序都不支持。 文章详情页我们本来是打算全部原生化，正是这个原因，内容部分不得不内嵌h5，小程序只能完全内嵌h5。其实图文结合就可以满足绝大多数的应用场景了，文章编辑以json格式保存，可以支持绝大多数端的前台展示。不得不背的历史包袱。
7、移动端OA系统
最早的移动端OA系统是饱受大家诟病的“分站管理系统”（现在已经废弃，取而代之的是工长App和服务商App）。16年的时候，前端可以说没有使用什么技术框架。 静态页面加上jquery 的ajax 拉取数据，操作Dom渲染数据。加上开发这个系统的人之前根本没有相关经验，连普通的编程思维都没有，做出来的东西，别说性能了，连基本的可以使用都做不到。 对于技术人员来说，实际项目，还是要有多大能力做多大事，可以加一点挑战，如果全部都是挑战，就无法保证项目的结果了。学习能力高一些的，可以多给一些挑战，进步的快。 公司项目，不是自己练手的demo，是有项目开发时间和质量要求的。
当年看起来难以完成的挑战，如果放到现在，前端组可以很轻松的踩过去。我们进步了。
18年，前端开发了电销h5版本。 技术框架是 Vue全家桶（vue+ vuex +vuerouter），非常适合开发移动端的单页应用。 不仅开发速度快，应用的相应也非常快。 可惜我们选择了一款不适合的UI框架：mint UI。 这个是饿了么团队开发的移动端UI框架，我们之前使用过这个团队开发的PC端的element，所以毫不犹豫的选择了minit。 开发之前我们并没有对Minit进行研究考察，而是直接上手。电销h5的开发时间总共不到一周，这回真是掉坑里了。 这个UI框架的视觉和交互只能算一般般，跟PC端的element差了太多。 更重要的是时间选择等插件，在表单中混用的时候，总是出现各种界面错位等bug，调试起来非常困难，电销作为一个OA系统，表单的存在无处不在，严重影响了开发效率。还有一系列跟mini相关的坑，我们都踩了，它真的不适合做移动端的ui框架。 最终上线的项目，视觉上看着惨不忍睹，简直不敢相信这是前端出品的东西，没脸了。
即使是同一个团队出品的框架，也不能盲目信任；
适合别人不一定适合自己的项目，从自己的项目出发去挑选；
每一个应用到项目中的技术慎重对待，至少先出一版demo；
UI框架可能更重要，这是摆在面子上的东西，一毁毁所有；
– Node.js
node.js是跑在服务器上的js语言。用Node.js开发Web服务器端，有几个显著的优势：
后端语言也是JavaScript，以前掌握了前端JavaScript的开发人员，现在可以同时编写后端代码；
前后端统一使用JavaScript，就没有切换语言的障碍了；
速度快，非常快！这得益于Node.js天生是异步的。
在Node.js诞生后的短短几年里，出现了无数种Web框架、ORM框架、模版引擎、测试框架、自动化构建工具，数量之多，即使是JavaScript老司机，也不免眼花缭乱。感觉前端仿佛无所不能了！
1、thinkjs
16年前端开始搭建Node.js服务器，选择了Thinkjs作为 运行在node端的框架，主要负责处理前端请求，复杂的数据处理、记录日志。
其实node端的框架很多，Thinkjs算是小众的。当年选择它，我想最大的原因可能是它有详细的中文文档。使用到现在，其实我们连它30%的能力都没有发挥出来。 很多复杂的逻辑已经在后台php那边处理好了。 再加上前端Vue实在是太好用了，曾经规划的node层处理数据逻辑也被抛弃，全都用vue在浏览器端处理了。
18年上半年，感觉thinkjs太重，同时眼热其他的前端框架，雄心勃勃的想研发前端3.0技术框架。当时重点研究了KOA，一个月的业余时间都泡在这上面，顺带着使用KOA + React + Redux 搭建了一个移动端demo项目。全新的框架，学习曲线非常陡。习惯了Vue开发模式，很难理解React。 带头研究这个框架的童鞋还做了一期分享，最吸引人的就是页面的前后端（服务器和浏览器端）同构了。
研究了一个月的KOA，最大的感受就是这个框架太灵活了。什么都可以自定义。 但另一方面，就是什么都没有，都需要自己写。 跟Thinkjs这种各种功能都封装好的框架，区别很大，上手难度也高。最终，这套前端框架仅仅作为业余研究试水，并没有在实际项目中使用。原因有下：
1、全新框架，学习曲线陡；
2、没有不可替代的技术优势；
3、只能在全新项目中使用，维护两套框架成本高；
2、webpack
我们的自动化构建工具webpack也是运行在node上的。今年上半年，花了很大力气来配置这个工具，打造成完全适合我们自己的自动化构建工具。 选择它，应该是毫无争议的，易用而且强大。
弊端的话，实时编译，对电脑配置要求比较高。我们一般本地都开着两个以上的项目。 如果再开启photoshop 这种大型图片处理软件，电脑简直要卡死。严重影响开发效率。 今年前端所有人都加了固态硬盘，如果内存再加一点就更好了。电脑配置升级，永远赶不上我们的需求啊。 不要小看前端折腾的能力。
前文中提到的Npm私服也是运行在node上。没有node.js，前端完全瘫痪。
线上的node是跑在Linux系统上的。 前端不懂Linux，运维不懂node。 服务器时不时的异常报错，解决起来有点吃力，特别是刚开始的时候。 前端没有太多时间和精力去研究这块内容，线上的node服务器配置到底有没有问题，我不知道，只知道能用。
– 惠装App内嵌h5
惠装app从诞生起，就从来没有缺少过内嵌h5。纯展示的，经常变动的内容都非常适合使用h5开发。不仅开发速度快，也可以快速迭代。对h5来说在App里面展示，跟在浏览器中展示没有本质上的区别。
从15年到现在，累积了不少相关的研发经验。
比如h5需要能够鉴别自己是否在app里面，我们使用过的方法如下：
1、app通过url给h5传参。 这种方法的弊端就是非常容易被伪造。也容易出错，app开发人员忘记加appid的就歇菜了。
2、app提供相关的api，比如getSystemInfo。 h5通过js来调用 api来获取app相关信息。 这种方法需要app编写对应的api，h5主动调用。
3、使用userAgent。app内嵌浏览器 userAgent 带有特殊标识，可以用于识别h5是否在app内部加载的。 这是我门现在使用的方法。 开销小，使用简单。
App可以提供一系列的api供h5使用，以期让h5获得app的能力，比如呼气登录、分享、查看大图等等。为了长期维护使用，我们编写了详细的weik使用说明。这么几年下来，累积了不少api。 有些已经废弃不再使用了，应该进行一轮梳理了。
开发app内嵌的h5，调试时一项费事费力的工作。受到电脑配置以及这种联调工作只是一个低频事件，前端没有安装app的开发工具。app在包里提供了一个专门给前端调试使用的界面，可以输入前端页面地址（一般是本机ip的页面地址），来在app里面打开h5 。前端通过tips，抓包工具来调试页面。这样基本可以确定问题来源。
原文首发在掰1掰大本营