3.6 shotgun surgery(散弹式修改)

“发散式变更与霰弹式修改之间的精妙点：单一职责(SRP:Single responsibility principle)”

牵一发而动全身,每次遇到某种变化，都必须在不同的类中做出小修改

《重构：改善既有代码的设计》中提到过一些代码的坏味道，针对这些坏味道，需要进行重构。 霰弹式修改 shotgun surgery 问题1：修改某个功能，要在不同的类中做出愈多小修改 解决方案：使用move method和move field， inline class将所有需要修改的代码放进同一个类中。如果眼下没有合适的类可以放置这些代码，就创造一个。 ...

霰弹式修改和发散式变化是相似的但是正好是相反的。你嗅到这个每当你做出一种修改的时候，你必须在很多不同的类中做出很多小的改动。当这些改动四处都有的时候，它们是难以被发现的，这样就很容易漏掉一些重要的改动。 在这种情况下你就想要使用Move Method和Move Field来把这些所有的变化点都放到一个单一的类中。如果没有一个现成的类看起来像是一个好的选择，那么新建一个。通常你可以使用In

一个需求变化会引发多个类进行相应修改，则为散弹式修改 每次遇到某种变化，都必须在许多不同的类做出许多小修改 使用 7.1 Move Method 迁移方法 和 7.2 Move Field 迁移字段 将所有需要修改的代码放进同一个类进行处理 若当前不存在这么一个类，则创建一个 一些关联情况 3.5 Divergent Change 发散式变化 是指一个类受到多种变化的影响 3.6 Sho...

散弹式修改（Shotgun Surgery）是指在软件开发中，当需要修改一个功能时，需要同时修改多个类或方法，导致代码的可维护性下降。这种情况下，修改代码就像是用散弹枪射击，一发子弹可以命中多个目标，但也增加了代码的复杂性和风险。散弹式修改的问题通常出现在代码设计不合理或耦合度过高的情况下。当多个类之间存在紧密的依赖关系，修改其中一个类的属性或方法时，就需要同时修改其他相关的类，以确保系统的一致性。这种修改方式不仅繁琐，还容易引入错误和不一致性。

散弹式修改（Shotgun Surgery）类似 发散式变化（Divergent Change）,但恰恰相反。如果每遇到某种变化，都必须在许多不同的类中做出许多小修改，你所面临的坏味道就是散弹式修改（Shotgun Surgery）。如果需要修改的代码散布在四处，你不但很难找到它们，也很容易忘记某个重要的修改。 可以使用 Move Method （搬移函数）和 Move...

Shotgun Surgery类似Divergent Change，但恰恰相反。如果每遇到某种变化，你都必须在许多不同的classes内做出许多小修改以响应之，你所面临的坏味道就是Shotgun Surgery。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。 这种情况下你应该使用Move Method（搬移函数） 和 Move Field （搬移值域）把所有需

5.Divergent Change发散式变化 描述：一个类被锚定了多个变化，当这些变化中的任意一个发生时，就必须对类进行修改。 解释：一个类最好只因一种变化而被修改 操作：你应该找出某特定原因而造成的所有变化，然后运用Extract Class将它们提炼到另一个类中。 6.Shotgun Surgery散弹式修改 描述：一种变化引发程序多处的修改。 解释:一种变化在程序中有多个锚点...

使用移动语句（223）和提炼函数（106）尽量把逻辑从处理更新操作的代码中搬移出来，将没有副作用的代码与执行数据更新操作的代码分开。据我们的经验，活得最长、最好的程序，其中的函数都比较短。很多语言支持更复杂的switch语句在不同的地方反复使用同样的switch逻辑（可能是以switch/case语句的形式，也可能是以连续的if/else语句的形式）。命名是编程中最难的两件事之一正因为如此，改名可能是最常用的重构手法，包括改变函数声明（124）（用于给函数改名）、变量改名（137）、字段改名（244）等。

之前的文章对重构的本质和基本原则做一个总结记录，今天这篇文章主要是总结一下"何时重构"，即该在时候才需要去重构？什么样的代码需要重构？

本文摘抄自《重构 改善既有代码的设计》一书 Shotgun Surgery(霰弹式修改)：如果遇到某种变化，你都必须在许多不同的类中做出许多小修改。 如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某个重要的修改。 这种情况下你应该使用Move Method和Move Field把所需要修改的代码放进同一个类中。 ...

膜拜下 Martin Fowler 大神 , 开始学习 圣经 重构-改善既有代码设计 . 代码的坏味道就意味着需要重构, 对代码的坏味道了然于心是重构的比要前提; . 作者 : 万境绝尘 转载请注明出处 :http://blog.csdn.net/shulianghan/article/details/20009689 . 1. 重复代码 (Duplicated Code) 用到的重构方法...

在上一篇文章中，介绍了通过名字就能理解的 8 个坏味道，感兴趣可以查看识别代码中的坏味道（一）。本篇文章将识别代码中的另外 10 个代码坏味道：10个晦涩但是通过简单的即可识别的坏味道。 如上图，这 10 个代码坏味道是： 发散式变化 霰弹式修改 依恋情结 数据泥球 基本类型偏执 平行继承体系 冗赘类 过度耦合信息链 异曲同工的类 纯数据类 01 发散式变化 简而言之就是一个类总是因为不同类型的原因发生变化。例如：需要修改数据源时要修改该类，需要修改缓存时还需要修改这个类，甚至当修改某个策略的计算公.

在软件维护过程中，两类典型问题常困扰开发者：发散式变化（一个类频繁因不同原因被修改）和霰弹式修改（一个功能需要改动多个类）。这两种问题看似相反，实则都指向重构的核心逻辑：通过分析代码的共性与差异，建立更合理的关系边界。

最近在做项目的代码重构和治理，根据《重构》的定义： 在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。 良好的代码设计对与后续维护、改动的作用是不可忽视的。差劲的代码重构，几乎等同于重写。 1.Duplicated Code(重复的代码) 坏味道的首当其冲是重复的代码Duplicated Code。假设你在一个以上的地点看到同样的程序结构，那么当可肯定：设法将它们合而为一，程序会变得更好。 最单纯的Duplicated Code就是［同一个class内的两个方法含有同样表.

文章目录前言一、pandas是什么？二、使用步骤1.引入库2.读入数据总结 前言 从第三章开始，作者就开始介绍一些重构的具体细节了，通过这些的具体的方法就可以一步一步慢慢开始整个重构的过程了。本章主要讲述的主题是代码的坏味道。第一次是从一个华为的架构师口中听到代码的坏味道，所谓代码的坏味道，我想就是指代码不好的感觉吧，其实我们很难通过一些量化标准来判定一份代码是否是好的代码，但是随着开发经验不断地提升，我们会对 提示：以下是本篇文章正文内容，下面案例可供参考 一、pandas是什么？ 示例：pandas

代码坏味道

前言 什么样的代码是好代码呢？好的代码应该命名规范、可读性强、扩展性强、健壮性…而不好的代码又有哪些典型特征呢？这25种代码坏味道大家要注意啦 公众号：捡田螺的小男孩 github地址 1. Duplicated Code （重复代码） 重复代码就是不同地点，有着相同的程序结构。一般是因为需求迭代比较快，开发小伙伴担心影响已有功能，就复制粘贴造成的。重复代码很难维护的，如果你要修改其中一段的代码逻辑，就需要修改多次，很可能出现遗漏的情况。 如何优化重复代码呢？分三种情况讨论： 同一个类的两个函数含有相