在产险作为主要开发人员一共做了4个项目，分别是两个 node.js 后台服务、一个 react 移动端项目、一个 vue 移动端项目。其中两个 node.js 服务都是只有我一个人开发，移动端项目是有5个人的前端团队协作开发。
第一个 node.js 服务是一个车型查询服务，主要目标是把服务升级到新的版本，因为原有的服务依赖的 node.js 和依赖库版本都非常老了，已经不合时宜了，我们领导决定让我用最新版本的 node.js 把这个服务的逻辑重新实现一遍，所以这个项目的主要任务是搞清老的服务逻辑，然后部署到新的服务器上。
老的服务逻辑并不复杂，主要是用一个分词模块把车型信息的主要数据进行分词存入 mongodb 数据库，然后通过和用户输入的查询信息的分词数据进行对比来获得用户可能想要查询到的车型信息。这个项目让我收获最大的不是对老的逻辑的分析和实现，而是对 linux 系统的学习和操作。这个项目需要通过跳板机部署到内部的云服务器上，一开始，我是把项目代码先压缩，使用 scp 发送到跳板机上，然后再一个一个的发送到4台生产机上。这样搞起来流程比较繁琐，而且总是会让人担心是不是有一个服务器忘记重新部署了。于是，我通过搜索，发现可以使用 expect 这个 linux 下的工具实现自动登录服务器并且发送文件、执行部署命令，于是，通过几天的学习和实验，我用 expect 成功的实现了半自动化的项目重新部署方案，和前手工操作相比起来，用的时间更短，部署准确度更高。这个算是这个项目的一个亮点。我想，这应该也算是我自己性格和思维的一个亮点吧。我在生活中，不喜欢繁琐重复的事情，如果有这样的事情，我就会抱怨，就会想办法把这个事情做成能够自动化完成的事情。
第二个 node.js 服务是一个比较复杂的服务，我们称之为 padweb ，是线销C端门户系统的一个组件，现在已经包括车险PC官网接口、车险前端页面错误统计服务、车险前端页面媒体来源统计、员工账号登录服务接入、城市名称和代码搜索查询等功能。
这个项目不仅是要做一些业务的实现，同时也是为了在车险沉淀出一个功能完备的 node.js 开发框架。上一个车型服务项目使用的的 express， 在开发 padweb 之前我们的架构师组织开了一个架构讨论会议，分析对比了 express、koa、egg 等开源框架的优缺点，最终选择了用 koa@2 作为基础框架，由我对它进行扩展开发，最终形成一个既适合于进行企业级开发，又不会像 egg 那么厚重并且受制于人的一个内部基础框架。egg 被否定原因是因为架构师担心 egg 后期不再有人维护，现在看来还远远没有到不再维护的时候。而且自从那次开会之后，架构组的人就再也没有谁关心过我们的架构是什么情况了，可见被称为架构师的同事也未必都是可靠的。
架构师不管了，我自己不能不做，虽然从前也从来没有做过架构开发方面的工作，但是从其他框架学习一点经验，模仿着做一个也就是了。于是，参考着《Nodejs：摆脱黑工坊发展出一款基础企业级框架》这篇文章，先写出了一个框架的雏形，实现了文章中提到的 controller 和 service 的自动注入，route 的强制约定，另外把前一个项目的根据环境自动配置 config 文件的功能也复制了过来，之后的就要靠我自己去扩展了。首先做一些常规操作，添加了 404 和 500 的处理，使用 log4js 添加了日志记录，使用 k-cors 解决非生产环境跨域问题，使用 helmet 添加安全方面的 http header（为此还简单翻译了一下 helmet 的文档）。然后就是开始开发业务，在业务中发现问题，解决问题了。
第一个开发的业务城市名称和编码服务，这个就发现了问题。首先，我不再能登录生产服务器，其次也不想再手动开启城市数据同步方法，于是经过一段时间的思考和尝试，最终使用《多个独立进程架构下的单进程数据库同步方案》中的方案解决了这个问题。解决了这个同步数据的问题之后，很快又出现了问题，有个接口的返回数据量有二百多K，结果数据传输非常慢，在测试环境要几秒时间。于是，首先去掉了前端不需要的数据，减少到一百多k，然后使用 compress 压缩，最终减少到十几k，最后再加上服务端缓存，最终接口返回时间缩减到了几毫秒。