关于重构

重构

这是一个非常敏感的话题
站在一个有着代码强迫症的程序员角度来看，一堆“烂代码”不进行重构的话估计连觉都睡不好
站在一个不懂技术或者对代码没有强迫症的老板角度来看，重构跟不重构效果上没有任何区别，代码的整洁，高效，易读，易扩展等事情老板是没有概念的
但是，越烂的项目有新的需求或改动时，坑就会越多，花费的时间就越多，如此会恶性循环
如此一来，是否要重构可能真需要好好考虑一下

重构的起因

冰冻三尺非一日之寒，我相信如果从写第一行代码开始，就认真的思考业务与项目的结构之间的关系，并在编写过程中不断进行小的调整的话，代码是不会烂的。重构其实就是在编写过程中没有进行小的调整导致后来需要进行大的调整

过度设计

假设我现在有一个需求，只想要一个接口返回给前端一条数据库里的记录的 JSON 字串

• 一个 Java 程序员可能会这样（我在这里没有对 Java 程序员有任何的歧视，只是举一个例子，而且这个例子是很普遍的现象）：

1. 先搭建微服务，分布式框架
2. 分层，定义实体类，定义接口，写 SQL，查询
3. 将 SQL 跟代码分离，定义实现类，然后接口返回结果
4. 启动项目，抛异常
5. debug
6. 重复 4，5 两步 n 次
7. 接口正常返回结果

• 一个 PHP 的程序员可能会这样：

1. 写代码连接数据库
2. 写 SQL 查询
3. 返回结果

结论

所以写代码这件事其实应该是跟着业务走的

• 如果业务很庞大，那么这个时候设计就显得很重要，代码的结构，模块的耦合，性能的优化等等诸多问题都得考虑
• 如果业务只是一个很简单的系统甚至都不算系统时，也就不用过度设计了，不能为了设计而设计，要满足实际需求