主观上：重构是一个年轻的“疾病”。 根据个人观察，26年后的某个地方开始放手。 就像那句老话：“他年轻时就不是革命者-他没有一颗心，他没有成为成熟的保守主义者-他没有头脑。” 因此，在我最终放手之前，我将尝试描述重构用户案例以及使用它可以实现的可能目标。
启发者
在下一次查看对150多个文件的拉取请求之后，我开始写东西，其中激烈地涉及新功能和对现有功能的重构。 重构不仅是表面上的，而且是逻辑上的，这造成了最大的痛苦。 例如，在Ruby中， amount == 0替换为amount.zero? 在没有考虑到数量nil的情况下amount这些构造是不等效的。 所有这些都大致解释如下：“但是根据代码，标准是这样假设的！” 对于逻辑问题“将代码遵循标准的目的是什么，总的来说，您作为开发人员的目标是什么？” 这个男人锁住了自己，并再次犯了些罪恶感，“但是按照代码标准，你必须这样写……”，看上去像一个金发碧眼的服装店，无法应付欲望 重构 买东西。
定义
该主题很敏感，因此您需要特别注意“谁是谁”这个问题。 因此， 根据Wiki ，重构是更改程序内部结构的过程，该过程不影响程序的外部行为 ，并且旨在促进对程序工作的理解。
就我而言，我想缩小界限并定义重构（从最糟糕的意义上来说）是指与解决的问题不直接相关且不改变系统外部行为的任何更改，而是作为原始任务的一部分执行的。
也就是说，我不想谈论代码库的计划变更（已概述了工作范围并已设定特定目标），而是谈论在开发过程中发生的自发修改。
产品价值
现在，我将从远处开始。 源代码既不是目标也不是价值。 当然，从美学或艺术角度讲，它可能会引起人们的兴趣，但这是例外。 通常，代码是用于创建任何人都可以使用的软件产品的工具。 因此，对于初学者而言，最好确定产品中的值是多少。
直接产品价值
这里的一切都很简单。 他们使用产品，因此直接价值就是用户清楚地感受到/看到/感觉到的东西。 即：
- 各种产品功能；
- 可用性（UI / UX，性能，容错等）。
第二点可能引起一些讨论。 毕竟，许多人认为这不是主要内容。 由于该功能是否良好，封装在哪都无所谓。 没有理智的UI / UX功能的好例子： Redmine和SAP 。 但是，我不同意这种看法，并且对艾伦·库珀同志和他的“病人手中的精神病学医院”持不同的看法。
间接产品价值
这些是本身不会影响用户的值。 但是它们可以“射击”或“累积”，并会对产品或其功能产生影响（程度不同）。
- 虫子。 值的临界情况。 它们是次要的，因为值本身并不携带，而是从相邻要素中获取。
- 清洁度。 这与可读性，模块化，传入组件的最小化，接口的标准化和统一有关。
- 文献资料 这是关于开发人员的代码和说明，而不是业务说明或用户帐户。 一个采访中一个开朗的农民的话很好地说明了这一点：“数据库中的逻辑就像一本书一样写。”
- 可伸缩性/安全性/安全性。 用户只有在发生不良情况时才能看到它们。
开发者价值观
这是许多人忽略的非常重要的类别，但它始终会影响结果。
- 按标准代码。
- 缩进风水。
- 有良知的其他交易。 毕竟，代码已经编写好了，所以每天都有结果，因此有好处。
- 符合内部世界规范。
但说实话。 所有这些都与与产品和最终用户关联的值无关。 这与心理学和个人蟑螂有关。
从业务角度看
为了完整起见，必须从业务的角度而不是软件产品的角度来看所有这些。 在这种情况下，直接和间接价值的划分变得很平庸：直接-显然带来了金钱，您可以进行明确的定量评估； 间接的-他们不带钱和/或很难量化； 开发人员的价值不会带来任何形式的收益（甚至可能带走收益）。
举个例子
- 带有OAuth增强功能的新功能使注册数量增加了10％，我们获得了+ 1k $。
- 根据单一责任模式，我们将计费模块分为几个独立的部分。 似乎维护起来更容易了，但是却无法测量。
- 我们使代码库与代码标准保持一致，而...却一无所获。
值得注意的是，根据以上估计，随着心爱的业务加速，普遍的匆忙和不愿将时间投入到除功能性和可能的错误修复之外的任何事情上，人们的脚步越来越长。 实际上，可以估计和“出售”直接值，而间接值则非常困难或不可能。 事实证明，间接价值要么通过工程背景实现，要么在直观的水平上被理解，要么被抛为“毫无价值”。
公平地讲，在这里我们需要回顾使能器的概念，该实现器为实现所需功能“铺平了道路”，但对用户没有明显的好处。 但这是另一个故事。
那重构呢？
至少尽管他只能影响产品的间接价值。 因此，用户不会因任何重构而感觉更好。
记住熵也很重要。 重构总是将其最小化。 为了减少熵，理想情况下，您需要一个在设计阶段使熵最小的建筑师团队。 引用《神话人月》中的一篇文章：
系统编程是一个减少熵的过程，因此其中具有亚稳定性。 程序维护是一个增加熵的过程，即使最熟练的维护也只能延迟系统陷入无望的过时。
因此，如果我们认为重构是程序维护过程的一部分，那么重构次数越少，无需重写的代码将存在的时间越长。
重构可以有哪些目标？
让我提醒您，我所说的是功能实施过程中的自发变化，而不是计划中的变化。 在这种情况下，目标的定义完全取决于开发人员。 他必须问自己主要的问题“为什么？”，然后回答，然后朝着预期的目标迈进。
为了熵！
自己做很难。 进行审查通常是不现实的。 目标当然是好的：清除取得新成就的桥头堡，并清除产品支持期间积聚的毒素和毒素。 但是，从头开始铲几个模块而又不丢失任何东西并不是一件容易的事。 如果有的话，应该与业务分析师和架构师一起解决。 因此，很少有人冒着自愿进行此操作的风险。
对于文档！
这已经很容易了。 重命名变量/函数的原则是“先在框内，然后在框内”，由于语言和库的功能，简化设计，在不明显的地方添加注释等。 这可以单独完成，也可以通过正确的方法对自己和对未来的同事都做得很好。
为了速度！
老实说，应将此类工作突出显示为一项单独的任务。 由于该系统的当前功能足以满足您的需要，而您无需执行任何操作，或者您确切知道加速所需的内容和数量。
一切都属于此类：从对N +1的无害校正到由于运算算法的更改而导致的严重加速。 整个问题在于错误的“奇偶性”总是处于高速状态。 举个例子：在一个事务中推送数据库中的数据，在同一事务中，在Sidekiq中设置任务； Sidekiq在Redis中的队列，该事务不适用于它； 当队列速度增加时，有时会在提交数据之前执行任务； 您可以自己想象后果和调试过程。
为了重构！
想象一下您使用了公寓清洁服务。 他们来了，开始打扫卫生，但是，一路上，他们把公寓里的所有家具都搬走了，并从客厅到浴缸勾勒出窗帘的轮廓，理由是“在这样的条件下，清洁工做得更好。” 图片来自“ WTF？！” 您可以自己想象。
我希望您了解，您不必考虑自己，而应该考虑为谁服务。
谦虚与接受
总而言之，有必要在重构之前给出一份“手册”。 的确，这不是TODO列表，而是您需要达成共识并接受或不采取行动的事实列表。
- 我正在增加该项目中的错误数量，并且可以为其提供铃鼓。
- 我成为重构代码的所有者，关于它的所有问题首先将被发送给我。
- 通过我的行动，我不会为最终用户带来任何有价值的东西。
一点解释。
- 对代码进行的任何更改都有非零的机会生成错误。 而且由于此操作与最终功能无关，因此您只需生成错误而无需生成核心价值。 意识到这一点很高兴，不要在遇到问题时假装成软管。
- 诸如“注释先前的注释”之类的借口非常惨，因为在同一个github / gitlab中没有此类功能。 另外，前一位作者确认，一切都可以在他的配置下进行，并且他对您的更改不承担任何责任，并且丢失了部分正在发生的情况。 更确切地说，您将它与责任一并带走。
- 用户确实并不关心重构，他对稳定性和功能感兴趣，而重构与之无关。
再说一遍：如果您不同意其中至少一项，请不要开始重构。 更好地阅读Habr，Lurk，喝茶，或者最糟的是从仪表板上阅读下一个功能。
结束
不要严格判断。 如果可能，进行建设性批评。 并始终考虑您的行动目的。 谢谢啦