【读书活动实用案例分享】愚公-读《重构：改善既有代码的设计》有感：当示例照进现实

参与新SaaS项目已经几乎有一年的时间了，这段日子，用两个字就能概括：移山——正如我们的队名“愚公”一样。从特来电的标准产品代码山中，找出我们需要的，并对其进行迁移、删减。这个过程，无时无刻不涉及到重构。当然这个工作在读到本文的主角：《重构》这本书前，就已经在做了。所以，在我在真正读书时，便能够带着一个反思的角度，对比书中的示例，来找出自己的缺点，并且体会自己与大佬之间的差距，这个差距不只是代码的规范，更是思考的高度。以下是我遇到的实际情况。

在面对此种代码的时候，我是鄙夷的：使用没有人能够读懂的写法，做各种技术而非业务上的封装，绕来绕去，绕去绕来。首先我承认，能写出来这种代码的人，他的技术是很好的，他对于C#这个工具，使用起来肯定是得心应手的。对于这种代码的重构，此书中给出了一个名词，叫做：捡垃圾式重构。具体来说，就是我已经理解代码在做什么（尽管为了达到这个目的我Ctrl和F12已经按烂了😂），但发现它做得不好，例如逻辑不必要地迂回复杂，或者两个函数几乎完全相同，可以用一个参数化的函数取而代之。在面对这种代码时，是要区分场景的。如果我这时需要在此基础上做新的开发（每个人的开发都很紧急），这里有一个取舍：我不想从眼下正要完成的任务上跑题太多，但我也不想把垃圾留在原地，给将来的修改增加麻烦。如果我发现的垃圾很容易重构，我会马上重构它；如果重构需要花一些精力，我可能会拿一张便笺纸把它记下来，完成当下的任务再回来重构它。这是书中的观点，也是我汲取的部分。其实对于我来说，我不拿什么便笺纸或者什么云笔记来记录它，我也忘不了它，因为他会在我的脑子里打上钢印，就像我无法忍受一堆垃圾一直在身边堆着一样。

普通脑回路的代码还是居多的。经过了如此多的新功能拓展之后，正常的代码，也会出现冗余。在面对这种情况来开发时，经常就会发现：如果对代码结构做一点微调，我的工作会容易得多。也许已经有个函数提供了我需要的大部分功能，但有几个字面量的值与我的需要略有冲突。如果不做重构，我可能会把整个函数复制过来，修改这几个值，但这就会导致重复代码——如果将来我需要做修改，就必须同时修改两处。而且如果以后又有相似的需求，我可能还要再复制一遍。这种情况下，便可对代码进行函数参数化重构。

当然，这本书对我的启示，远不止这两点。我也会更加深入地阅读，提升自己开发功力。不只是重构老代码，更多的是在面对新的开发时，规划出一个简单易读，同时兼顾可维护性和可拓展性的高质量代码。