代码重构

最近在对手头的项目进行重构，以下是这个过程中的一些思考。

1.项目为什么要重构？

1.1架构无法横向拓展

问题：

在项目初期，我们只做了pc端的应用，但是项目到了一定阶段后，我们需要开发app；此时发现，由于前期没有很好的规划，项目的架构无法拓展，虽然项目也是按照web层，service层，dao层来设计的，但是很多本该写在service层的逻辑，为了省事儿，都写在了web层，这样的service层是没法让app项目来公用的。

解决方法：

我们把web层中的业务逻辑代码，全部迁移到service层，这样web层的作用就很单一了，就是接受请求，调用service层获取数据，跳转页面；而service层，就专门用来处理业务逻辑；这样，我们开发app时，只用写一套页面，再写一套web层就可以了，后面的业务逻辑都在service层中，可以直接公用的。

1.2代码无法维护

问题：

review代码时，发现很多类似下面的问题：

1.一条sql语句100多行，在sql语句中处理业务；

2.2个饼图2个折线图的数据用一个接口返回，另外一个页面只需要其中2个图的数据，还是拿这个接口，然后无视多余的数据；

3.一个接口返回60多个字段，而且这些字段很多都是查询后经过计算的；

4.一个方法300多行，而且没有一行注释；

5.监控出的慢sql追过去都是那种复杂无比没法看的；

6.大段大段的代码被注释，一年前注释掉的代码还在；

在接手项目的时候，看到这些代码，内心简直是fuck的，在后期数据量不断增大，用户量不断增加，出现问题候，我们来维护这些代码时，充满无力感，一条sql看半天也不知道究竟是在干什么（写复杂sql的确是技术活，但一条sql连10张表，再处理各种业务，的确牛x，我很佩服，但是你去维护一下就知道这种牛x的代价了），无从下手。

解决方法：

重构这种代码，是最痛苦的事情了。除了重写，没有其他办法，因为根本看不懂，或者说，看懂一个300行没有注解的方法花费的时间，要远远大于根据需求自己重写一个新方法；公司的开发团队一定要打成一种共识：

1.写代码写优雅一点，必要的注释写一下;

2.sql语句好好写，你的装x对公司和团队是一种灾难，fuck;

3.写接口思考一下，低耦合啊，方法功能单一一些，这样其他地方或者其他人可以复用啊;

4.没用的垃圾你给删掉啊，别人不敢删你的代码，以为你的代码哪天有用，但只有你知道那是垃圾！

5.做到了第3点上面的问题2就没了啊，方法功能单一原则啊！

1.3业务逻辑无法拓展

问题：

项目中有很多关于税收的图表，在初期时，查的数据都是当前年份某省的数据；看到没，这个需求：“查询当前年份某省的数据”！！！看到这个需求，就有人直接写了个接口，查询当前年某省的数据，接口参数就留了一个：省份！我第一次看到这个接口就在想，这个接口一看作用和参数，就是垃圾！为什么？果然，后期，我们查询维度变了，有些页面展示省级的，有些展示市级的，有些展示县级的；过了段时间，我们又加了个年份筛选框；几十个接口，数据查完还得计算，现在突然加这样那样的筛选条件，fuck，这不是怪产品，这是写代码不带脑子！

解决方法：

写接口时，思考一下啊，看看是不是后期拓展可能会加参数啊，你不用想太多，起码让你查今年的数据，你能想到某天会查去年的数据吧，你的公司表中有省市县字段，现在让你查陕西省的年度税收，你应该能想到过段时间会查西安市的年度税收吧！不然表中要这个省市县字段干嘛啊！！！和合理的参数预留啊，觉得麻烦，那你写个通用的参数传递类啊，用这个实体传参数，后期加条件了直接改一下实体和sql就可以了啊，不用满世界去改啊！