发散式变化和霰弹式修改经常会让人难以区别？霰（xiàn）弹式修改这个借助了霰弹枪隐喻。玩过魂斗罗的小伙伴应该知道里面就有一种散弹枪（可能是为了方便辨识，做了更改），扫射出来的子弹是大范围的分散的。霰（xiàn）弹式修改意味着你的改动会造成大范围的影响，一处修改，到处修改。这句话也道出了重复代码的坏味道，所以想重复代码和重复Switch也都散发出了霰弹式修改的坏味道，这样的代码坏味道在代码中很常见，也较容易识别出来。
发散式变化，这个坏味道从字面上来看，是引起变化的原因很发散，就好比，我是一个初来乍到的实习生，有好几个部门的主管，比如财务部，人事部，市场部，他们都可以给我下指令，导致我在工作中不得不去面对这些不太相关指令，不断的在不同的上下文中切换，这种感觉肯定不会好到哪去，虽然不敢太有怨言。
如果一个类或模块中，它关注的上下文太多了，就势必导致不同的上下文的改动都会引发该类的改动，职责过大，后期越来越难维护。等等，单一职责不就是这么讲的吗？对的，这个其实就有点违背SOLID中的单一职责原则的。
不幸的是，这种坏味道不太容易被识别出来，尤其对一些新手而言，就好比一个大厨告诉一个新厨，炒菜要放盐少许，这就有点很难把握了。有一些经验可供参考，比如一个类或模块关注了明显能区分的业务模块，就要考虑拆分了，比如：
- 处理保险业务还处理数据库相关操作，
- 处理了日志工作，还做了用户管理。
- 处理字符串格式化报表，还做了第三方用户系统集成
另外，业界提倡的DDD也可以在前期帮助我们去梳理业务，寻找聚合，划分限界上下文，都能很大程度规避了后期的设计问题。
用一个连贯的故事总结这两种坏味道：初来乍到，3个不同部门的主管都可以给我下工作指令，能让我变化的点很发散。经过十年努力，我开创了的3家公司，每做一次体制改革，我需要在三家公司都执行一遍，引发大范围修改。
关于这两种坏味道，你在代码中见得多吗？
