【读书活动感悟分享】愚公-读《重构：改善既有代码的设计》有感

        在以往的工作学习中，对重构的理解比较狭隘，认为重构就是对现有代码的优化，对功能的调整。直到阅读了《重构：改善既有代码的设计》这本书后，才对重构有了一个系统、全新的认知。从定义上来说，重构可以分为动词和名词两种词性。作为名词的理解，它是对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本；作为动词的理解，它是使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
        通过这本书，知道了重构的原则。作者分别从何为重构、何时重构、怎样去重构以及具体的例子做了详细的说明。
        什么是重构。在前面通过重构的文字定义理解了重构字面的含义。然而，重构的关键在于运用大量微小且保持软件行为的步骤，一步步达成大规模的修改。每个单独的重构要么很小，要么由若干小步骤组合而成。因此，在重构的过程中，我的代码很少进入不可工作的状态，即便重构没有完成，我也可以在任何时刻停下来。进而，作者通过添加新功能和重构做了对比说明，让我们更深刻的理解了重构是什么。
        何时重构。作者说了一个很有意思的法则，叫三次法则。把我们俗语中的事不过三的说法完美融入到了重构的灵魂中。当我们第一次做某件事时，只管放手去做；当我们第二次做类似的事时，可能会有所反感，但是可还能忍受去干；当我们第三次，再去干类似的事时，我们可能就无法忍受了。在日常开发过程中中，经常出现这种情景，对一个功能不断扩展业务，虽然与最初的功能类似，但是我们每次都需要浪费很大精力去开发。出现这种情况，就应该考虑要对此功能进行重构了。除了上面说的这种场景，还有就是如果把3段一模一样且都会导致错误的代码合并到一处，问题修复起来会容易得多。或者，如果把某些更新数据的逻辑与查询逻辑分开，会更容易避免造成错误的逻辑纠缠。用重构改善这些情况，在同样场合再次出现同样bug的概率也会降低。然而，并不是说重构是万能的，确实有一些不值得重构，作者也给出了客观的说明，如果我看见一块凌乱的代码，但并不需要修改它，那么我就不需要重构它。如果丑陋的代码能被隐藏在一个API之下，我就可以容忍它继续保持丑陋。只有当我需要理解其工作原理时，对其进行重构才有价值。
        重构相比开发是有不少难度的，那我们怎么才能做好重构的工作。在真正着手重构之前，要先做好预备性重构工作。对于预备性重构工作，作者给处一个有趣的例子，如果我要往东去100公里。我不会往东一头把车开进树林，而是先往北开20公里上高速，然后再向东开100公里。后者的速度比前者要快上3倍。如果有人催着你“赶快直接去那儿”，有时你需要说：“等等，我要先看看地图，找出最快的路径。”这就是预备性重构于的意义。然后就可以开始着手了。对于重复代码毋庸置疑，做好的办法就是提炼或者抽象一个公共类；对于过长的方法与函数，要积极的分解函数；对于过长的参数，可以使用有效的类来缩短参数；散弹式代码修改，如改动一个功能时，要改动的参数，很分散，很多文件都需要改，这是我们需要考虑把所有需要修改的代码放到同一个模块里。除了这些，作者还给处了其他的几种处理，来回嵌套调用的“过长的消息链”，过多委托的“中间人”，
        在阅读《重构：改善既有代码的设计》之后，对重构的认知由零散的经验升到了系统的理论层面。从够不仅仅是代码的优化，结构的调整，是一种不断完善功能，提供可维护性的一个工程实践。书中对重构的定义、原则、时机与方法的深入阐述，让我认识到重构并非随意而为的行为，而是有章可循、有法可依的严谨过程。