03 服务端重构总结

花费了差不多1个多月的时间，任天赋、王帅琪和我三人功共同完成了隐私信息管理系统的前后端代码的重构工作。

其中，王帅琪独立完成了前端代码的重构工作，任天赋负责服务端代码中大部分“写”的操作以及与第三方平台对接的代码工作，我负责的是服务端代码中绝大部分与前端对接的“读”的操作以及与隐私合规平台预设规则对接的代码工作。

下面谈一谈我在进行重构过程中的体会和看法。

重构的原因

之所以进行重构，是因为之前的系统虽然能够继续开发，但是因为代码结构和业务逻辑的原因，后续维护难度会越来越大，我理解的主要的问题是：

1. 代码结构比较自由，服务端逻辑比较分散，难以维护，可读性不好
2. 有硬编码的现象，前端、后端维护分别维护同一份数据的配置文件，容易出现问题
3. 数据库字段设计不统一，导致增加了大量的处理逻辑
4. 前端负责了很多数据二次处理的工作

重构就是为了解决问题，所以针对上面的问题，这次重构的思路是：

1. 选用Egg框架代替Koa，代码使用一套统一的约定进行开发，让逻辑尽量清晰
2. 数据相关的配置文件由后端维护，变化较大的存入数据库，有必要的以接口的形式返回给前端
3. 优化数据库的字段设计，结合相关的配置文件，减少不要的处理逻辑
4. 服务端完成绝大部分的数据处理工作，以较规范的REST接口形式将数据返回给前端，前端可以直接展示数据

框架选型

在重构之前，我针对BFF进行了调研，针对几种Web开发框架进行了对比，比较可行的方案就是Egg和Koa（Express），最后之所以选择用Egg代替了Koa作为框架进行开发，主要基于以下几个原因：

1. Egg是在Koa的基础上进行的封装，完全兼容Koa的中间件，并且文档比较友好
2. 是蚂蚁金服的最佳实践的封装，有众多的插件支持，配套完善
3. Egg更适合于企业开发，以约定代替配置，可以做到代码规范的统一，提高代码的可维护性

Koa比Egg更加灵活，这就导致了代码无论怎么写，都能够运行，并且很多配套的支持都需要自行搭配，而Egg提供了一整套的解决方案，更适合有严格要求、长久更新维护的企业项目，也更能做到渐进增强的研发体验。当业务开发到一定程度时，完全可以由Egg抽象、封装出属于特定业务、特定模式的中间件、插件甚至框架。

使用了Egg，感觉最大的好处有两个：

（1）大量的约定

大量的约定，既限制了开发者，又给开发者自由。

在Egg的约定下，MVC的架构非常清晰，目录结构合理，可以按需选择。

egg-project
├── package.json
├── app.js (可选)
├── agent.js (可选)
├── app
|   ├── router.js
│   ├── controller
│   |   └── home.js
│   ├── service (可选)
│   |   └── user.js
│   ├── middleware (可选)
│   |   └── response_time.js
│   ├── schedule (可选)
│   |   └── my_task.js
│   ├── public (可选)
│   |   └── reset.css
│   ├── view (可选)
│   |   └── home.tpl
│   └── extend (可选)
│       ├── helper.js (可选)
│       ├── request.js (可选)
│       ├── response.js (可选)
│       ├──