常见的代码坏味道--重复代码，大类，长参数列表

1. 重复代码

重复代码很容易产生，主要是因为开发的本质就是复制粘贴，找一段类似的逻辑做一个简单的额修改就上线了。这样做在开发的时候可能没啥问题，但是一旦重复代码变多，面对一个简单的修改修改就要在整个项目中不断地找，一个个修改，这样速度和效率不能保证，而且很容易出错。

另外，如果在看到if语句出现，并且if和else的代码块比较像，就很有可能是坏味道。

重复代码的解决关键在于开发功能时就要时刻注意，在典型场景要合理使用设计模式。

2. 大类

我觉得类的最大的行数200行左右就够了。

如果类太大了，相同的功能可能不能很好地复用，另外大类会让人难以理解。因为面向对象要求每个类的功能相对独立，相对单一，这个理念和微服务，分治算法的思想很类似。

大类产生的原因就是职责不够单一，建议多用组合代理的方式就行拆分，尽量少用继承的方式去拆分（面向修改关闭，面向拓展开放）。

3. 长参数列表

参数的本质就是不同函数之间共享信息，除了参数列表，还有全局变量的方式可以传递信息，但是全局变量会有很多并发，安全等问题要注意。

3.1 将参数列表封装成为对象 

消灭长参数列表的重构手法在于，将参数列表封装成为对象。第一步是将相关联（且变化频率相同）的变量封装成DTO,info等，后面还可以进一步拓展，让DTO,info具备一些方法，思维也就可以冲面向过程转变为面向对象了。

3.2 动静分离

另外，函数传递的参数应该是动态的，（直接）影响方法执行结果的，如果是相对的静态数据，可以采用共享的方式避免传递，也就是动静分离

上面代码中 bookId是动态的，但是httpclient，processor 是相对静态的，所以，重构后代码如下：

3.3 参数不应包含标记

最后，很重要的一点，告别标记。这里的标记，就是把一些分支逻辑放在参数中传递，函数内部通过对应条件执行不同逻辑，这是坏味道。

在修改功能或者重构的时候，遇到这种代码很头疼，只能一个个的看，很小心的修改。

 解决这个办法最简单的办法就是把传递标记参数的方法进行拆分（移除标记参数），提前根据不同的标记调用不同的相对小块，独立的方法。

3.4 不使用Map

除了长参数列表，还有一种做法是将 Map（或者继承Map的JSONObject） 作为参数进行传递，这也是我最不喜欢的，key 要分别存取，不同的地方没有一个标准，感觉很不可控（升级版就是接口的参数竟然也有用Map的）。

去掉Map很简单，使用固定了字段名的类（DTO）就行了。