《大型项目重构实战指南: 从混乱到秩序的渐进式策略》这本书, 它的第一个大项就是引言部分, 引言部分的主要内容是在回答为什么要进行重构。在软件开发这个领域, 根本不可能存在哪一个项目是一直永远都能够保持那种“干净整洁”的状态的。后面会因为业务上的那些需要被非常快速地给重复修改、变化, 加上团队里面的人也在不停地换着来, 还有那个用来写代码的技术体系也是一直地在发展改变这么一些情况出现以后, 那个存放所有代码的大仓库就肯定会是没办法避免地变得越来越大、越来越让人看不懂去操作, 甚至是会像东西坏掉了一样发生“腐化”这样的情况发生的。尤其是 项目由于语言本身的灵活性和动态特性初期编写往往能快速交付但随着时间推移代码质量问题逐渐显现模块耦合严重、测试缺失、性能瓶颈、文档不全……最终让开发者望而生畏。当许多团队碰见到这个情况之后, 他们的心里头就会冒出个想把一切从头来过的念头。可是你想想看, 事实其实并不是这样子的。如果真要把整个东西重新一遍, 那这事情就等于是自己把自己往死路上逼了。这种做法的风险是非常高的, 所花费的时间周期是长得让人受不了的成本开支也是巨大到难以承受的程度。更让人头疼的一点是, 在你辛辛苦苦把重写的那些部分全都做完之前, 市场上对业务的需求很可能就已经发生了变化, 根本就不是你原先想的那样了。所以, 慢慢来一点一点地去改, 这才是更实际、也更有效的办法。这篇文章会把好多年搞大项目还有教学生的经验拿出来跟大家说说道道讲清楚怎么弄, 就是在不用把原来的全都推翻掉重来这个大前提下头把那些又大多老旧的代码一个一个地一点点去改好。二、重构这件事里面, 最核心的一种想法。在正式进入那些具体操作策略的讲解之前, 大家有必要先把几个核心的想法或者基本理念给弄明白弄清楚。重构的意思呢, 并不是推倒重来, 而是不断地向前发展的。重构的目标在于去改善一下代码内部的那种结构, 而绝不是要去改变那个外部行为的表现。换一种说法来讲, 就是功能方面不改变, 质量一点一点地提上去。要采用步伐小的方式快速奔跑, 并且进行持续不断的交付。通过采用那些规模小巧并且能够得到验证的步骤来进行逐步的推进工作。这种做法的核心意图在于, 我们不应该去进行一次性的大范围改动, 而是应该避免这种大规模变动的情况发生。测试这件事其实就是重构的时候用来挡住风险的护城河。没有经过测试的改造工作, 这情况就跟在没有任何安全措施的情况下蒙住双眼去走平衡木是一样的危险。在进行实际操作之前, 务必先建立起充足的测试覆盖率, 这是绝对不可省略的前置环节。三、在重构之前, 需要先进行一些准备工作, 其中一个重要的准备工作就是建立测试体系。以下是示例代码, 该代码用于执行单元测试操作:# test_math_utils.pyimport pytestfrom myapp.utils import adddef test_add():assert add(2, 3) 5assert add(-1, 1) 0