重构VS重写？Express VS Nest?

最近，我们的Node Application马上要做系统集成了，但是目前看来项目代码的问题很大。

现有的项目是从别人手里接过来的，用的是Express. Express的优点很明显，简单灵活，但是一旦Application逐渐变大，就会慢慢不受控制，具体体现在：

1. 没有模块和分层，导致所有的模块，文件全都混在在一起，进而导致我们很难快速找到目标文件甚至是函数，新人也很难一眼看清项目包括什么；
2. 接口完全没有规范，一部分接口遵循Restful风格，入参没有校验，出参也没有标准统一的格式，错误处理也没有统一，导致前端同事使用接口时很难受；
3. 有一个巨大无比的service文件，已经很难维护了；
4. 开发效率低，很难受。比如没有加入热更新，每次改了代码都要重启服务；没有cli工具生成模板代码；也没有什么开箱即用的工具比如Guard来帮助提升效率；
5. 代码格式不统一，并且还含有许多dead code;
6. 命名不科学，部分函数逻辑冗杂混乱。

针对这些问题，我的目标是：

1. 分模块，分层，并且方便以后加模块；
2. 统一接口规范，入参出参，错误消息；
3. 拆分过长文件，把他们放在对应的模块里；
4. 用工具提升开发效率；
5. 统一代码风格，去处所有dead code, 并且做pre-commit;
6. 科学命名，无过多冗杂代码。

那么具体怎么做呢？
一开始我只想做小范围重构，既然是重构，意味着实在不影响现有功能的情况下，在原有代码上做调整，这对问题5，6明显是行得通的。

但是如果我想解决其他的问题，也许可以考虑更强大的一点框架呢？这就令我很头大了。本质来说，这涉及到两个选择：

1. 重构还是重写?
   这个问题，我认为主要看工期。这次领导听到我想重写的想法时，第一个顾虑点就是工期，他甚至提出了一种继续用Express框架做分层的方案，我思考再三，哪怕是这样写，也很费事，和重写的effort是一样的，毕竟我们不是单纯新开一个项目，把老项目的功能迁移过来就行了，我们的情况是，老的接口实现全都要改，那这样，还不如重写。

2. 如果重写，选哪个框架？我了解到有KOA, Egg，Midway, Nest
   这是一个技术选型的问题，我在这一块确实没什么经验，不过，这也正好说明，我遇到了一个学习的好机会。

我先翻了这几个框架的文档，然后，我在网上搜索了很多资料，也咨询了一些前辈，关于选用哪个框架，要从这几个方面考虑：

1. 项目的大小与复杂度
2. 项目团队规模
3. 人员情况与分工模式
4. 工期
5. 框架靠谱度
6. 项目发展方向
7. （公司内部能用这个框架吗？）

综合考虑，决定还是用nest. 比较能明确的是，模块化方案非常契合我们的需要，我们还可以根据模块分工；另外nest是有明确约束的框架，能规范我们的开发的API，错误捕获处理方式等等；其次，nest的生态非常强大，几乎是应有尽有，各种开箱即用的工具都是express没有提供的，目前唯一的顾虑是我们的项目并不是特别大，也并不是十分复杂，所以说科学性还有待验证。
------------------------------2022/7/7------------------------
很遗憾，global boss还是拒绝nest. 我能理解他的顾虑，一方面他担心引入新框架会增加复杂度，而我们的项目还没有达到需要用重框架的size和复杂度；另一方面碍于一些风险厌恶情绪，担心工期问题。所以最终还是决定继续用express，不过会调整一下结构，重构部分代码。

虽然没有成功用上nest, 但是这次我的收获还是很大：

1. 首先，我敢想敢做，当我意识到享有项目的问题之后，没有放任不管，而是积极主动地思考如何改进，并且迅速开始行动。
2. 其次，锻炼了沟通表达能力。我为了说服boss, 准备了PPT，并且在会上表达论点论据，还需要现场回答问题，并且全程都是英文，实际上当天boss是被说服了，他是第二天自己反悔了，所以我们算还是部分成功的吧。
3. 最后，拓宽了知识面。虽然没有真正用上Nest，但是这几天我已经基本摸清了nest这个框架，并且也搭建好了一个完整的项目架子。功不唐捐，甘之如饴。