今天在想本周文章写啥，头疼欲裂，由此发现那些写网络小说的作者真是牛逼，可以每天持续几千字的产出，还能够质量不差，相比而言，自己真是弱爆了，最后逼着自己还是先写写最近做的事情，周末梳理个长期计划，以后按长期计划写，不然这样下去不是个事哈；
最近在做驾照的重构，引入新的驾照翻译方；从背景来说，这是件很有意义的事情，因为从之前收到的调研来看，驾照问题是影响用户最重要的几个因素之一，而我们之前的驾照翻译只有单纯的字面翻译，调用的是开源的库；这会遇到两个问题，第一是翻译的质量问题，直译会有很多翻译的不好的地方，比较难理解；另外一个方面，在很多场景下，这种直译的翻译件并不能起到驾照的凭证，应用场景比较狭窄；所以在现状的基础上，我们引入了新的翻译方，这个是可以通过国际认证的，所以可以应用于更多的场景；
本文介绍两部分，第一部分为老系统的架构，第二部分是新系统的架构；
原来的逻辑由一个页面构成：从首页进去后，填完所有的信息；点提交后，会将数据先入数据库；再通过第三方lib对数据进行翻译；翻译完成后，将数据入库；同时生产pdf文件，并将图片信息发送给用户；
过程还是比较多的，主要是2个数据库操作，1个翻译，1个生成图片，1个发送邮件，会涉及多个外部lib
新版的增加了多个页面，大概8,9个页面，后端增加了10几个接口，主要分类为：
1. 订单list：2个，查询，最近一个详情查询
2. 订单类：2个，查询，修改，
3. 订单类地址：2个，增加，修改，只修改订单绑定的地址id
4. 地址类：4个，地址的增删改查
5. 线下，回调数据
修改了一下，将订单的地址抽象出来，变成订单的一部分，然后对原有的重复接口进行合并，就只有7个接口了：
1. 订单类(增加个订单绑定的地址id，默认-1)：3个，list查询，查询（如果没有订单id，则返回最新的一个订单），修改
2. 地址类：4个，地址的增删改查
3. 线下，回调数据
其实还有个更老的版本，有13个接口，梳理一遍，只有7个接口，看起来这个事就是个很简单的事情了；
写到这里，但实际在想，7个还是很蛋疼呀，是不是可以搞一个自动生成的脚本，自动生成api查询的框架，我一个都不用写；再扩展一点，我们的mis系统，是不是基本上都是数据库的增删改查，是不是通过这样一个框架的落地，前后端都可以通过配置完成，可以解决80%的mis问题；回到海外租车，我们的竞品租租车已经成立6年了，线下的我们不说，线上的我们如何通过5-6个人的小组花半年的时间去干1-2百人的花了5年干的事情，那这个新的框架就更有意义了；
所以稍微想了想框架的雏形，留待后用，就不画图了：
1. 后端的表是要提前提供的，这个需要预先准备；
2. 前端提供的是框架+模板，将通用的页面通过模板的方式固化下来，变成可配置的
3. 后端提供的是框架+api接口，将数据库的增删改查抽象成api接口出来，并对接口做业务上的控制；
总结起来无非就是一个自动生成api以及自动生成页面模板的功能，介绍一下2和3部分；
第二部分的核心是交互，如何有效降低门槛，让大部分的界面和接口配置变得非常容易，是这部分的关键，事情上分为3小块：
1. 抽象常用的业务模板，这个很简单；
2. 搭建前端框架，主要解决，a.引入模板，b.模板部署和上线，c.模板和后端api的交互配置(每个模板有多个接口，每个接口对应一个api接口)
3. 搭建后端Api配置，api主要配输入、输出和sql，这个和常用的框架差不多；
第三部分是后端的架构，主要是保证稳定性和各服务的独立性，一期为了简单些，这个都可以不用考虑独立性的问题
1. 定期从数据库读取各模块配置，并将配置变成本地缓存；
2. 根据api接口的参数，选择对应的api配置，并进行处理参数（过滤，判断是否合法等通用处理），调用sql，返回数据包
很简单有没有，这个搞完之后，大部分的增删改查的简单逻辑就可以通过配置来解决，项目的瓶颈就只在于一些静态页面和一些逻辑比较复杂的业务模块（如排人排车，这一类的比较少），而这些都可以通过堆人力去解决的，因此整个项目的开发速度会大大加快；
说一下优点：
1. 开发人员不用去配环境，新同学上手快；
2. 新增接口QA测试的点非常少，且bug会大大减少（因为大部分的功能框架都做了）
3. 整个开发流程增快很多，PM出完后，就能很快在线上看到，QA环节也时间减少
4. 不用上线
整体总结下来，就是减人力，开发快，且出bug少。。。
缺点：
1. 只能做简单业务处理，这个算优缺点并存吧，不过我们大部分的场景都是简单业务处理
2. 多个接口在一起，如果项目代码开发不好，会影响多个业务；
整体总结下来，就是因为只能处理通用问题，所以肯定不能覆盖所有，且如果推广多，会变成比较重要的业务，影响面大；
不过现在这个阶段，看到的业务和技术瓶颈还是比较明显的，技术瓶颈通过这个应该可以解决不少问题，但是还是不能花主要人力去做这个，因为主业务压力就很大了，所以其实项目的前期瓶颈还是在人身上；