我们该重用代码还是复制粘贴？答案是“分情况”，那么这个边界在哪呢？这也是我这篇博客所思考的问题。
今天在老德德的推荐下开始看了《架构之道》，这本书并不厚，但是干货挺多。我用了一些琐碎的时间看了几章，每章长度也不长，每章都像一篇高手的博客，很有意思。
这本书的四分之一处开始介绍一些设计原则，首当其冲的就是单一职责原则，这个职责的学术范儿定义我不想赘述，因为并不好理解，我打算从书中的一个例子开始说起。
假设有这样一种情况
假设有这么一个类Employee雇员类，这个类里面有3个方法：
class Employee {
caculatePay(); //这个方法用于计算当月工资
reportHours(); // 这个方法用于计算当月工时
save(); //这个方法用于将工资和工时存入数据库
}
你看这三个方法：
- caculatePay(); 这个方法用于计算当月工资，财务部的软件会调用这个方法来显示工资。
- reportHours(); 这个方法用于计算工时，人事部的软件会调用这个方法来显示工时。
- save();这个方法用于将工资和工时存入数据库
那么此时，程序员在实现这两个方法的时候，都使用了一个公共函数，regularHours(),如下图：
有一个程序员不小心踩了雷
财务部的程序员需要对caculatePay这个方法进行更新，因为财务部的计算模型变了。于是这位程序员发现caculatePay这个方法其实是调用了一个regularHours方法，于是他就把regularHours给改动了一下。拜托，他可不知道这个方法正在被别人使用呢！理所当然的，人事部的数据就出现了问题。
单一职责的解决之道
单一职责的思路是：我们需要将Employee类拆分成两个类。同样的，这两个类所共同依赖的regularHours方法当然也要被实现2次。没错，目前看来，我确实是在复制粘贴regularHours方法中的代码，可是这样一来，财务部的程序员就不会影响到其他部门的同事了。
内心OS：如果这本书的作者不是大牛的话，可能这个复制粘贴的行为会被喷。但这个例子是可以说服我的。
缺点
在《设计模式之禅》这本书里也提到了，单一职责这种设计方法很容易导致代码超级膨胀，本来一个类可以做的事情被拆成了多个类。那么什么时候该拆分，什么时候不该拆分呢？我需要讲述另一个例子。
一个现实中的例子
我们当前的项目中，在订票的流程页面写了一个卡片，类似于这样：
过了很久后来了一个新需求，我们需要在管理页面也实现这样一个卡片的样式。我有两个选择：
-
import scss from 'normalBookingFlow';这句话能看明白吧？哈哈，就是我在管理页面直接导入之前的scss文件。 - 创建一个新的scss文件，并且将之前的scss样式复制粘贴过来。
显然，这是一个分水岭，而我该怎么做呢？
我的个人见解是：根据team来决定是否选择复制粘贴。说的直白点：
对于复制粘贴还是直接复用的边界在于，两段代码当前是否处于同一个小团队在开发，或者是否处于同一个业务流程。
因为人事部和财务部不是同一批开发团队，所以对于这两个部门共用的代码应该拆分成两个部分。
因为普通的订票流程和管理页面的流程不是一个业务流程，所以也应该被拆分。
说来说去，其实结论一句话就说明白了。但是如果我在题头直接写这句话：对于复制粘贴还是直接复用的边界在于，两段代码当前是否处于同一个小团队在开发，或者是否处于同一个业务流程。 不着头不着尾的谁他妈看得懂啊？
结论：
1. 单一职责其实解决的是代码复用与代码复制的边界问题。
2. 对于复制粘贴还是直接复用的边界在于，两段代码当前是否处于同一个小团队在开发，或者是否处于同一个业务流程。
以上只是我结合自己的开发经验和书中所写产生的联想和理解，毕竟代码开发因人而异，如果编程可以做到完全客观呈现没有个人风格，那么要我们还有什么用呢？找一帮编程的机器人就完事儿了。编程的艺术正在于，你可以从代码看到一个人的成长和影子。
