内容简介：最近重构了公司一个将近10年的核心功能模块，踩了不少坑。在做这个重构的时候好几次都觉得做不下去，好几次压力都非常大，心想着我该不会做着做着就退出编程届了吧。
最近重构了公司一个将近10年的核心功能模块，踩了不少坑。在做这个重构的时候好几次都觉得做不下去，好几次压力都非常大，心想着我该不会做着做着就退出编程届了吧。
不过还好，自己还是坚持下来了，回想写这个项目的时候自己曾三次推翻重来，那种心路历程真的只有经历了才知道，真是煎熬。后来回想起这一路踩过的坑，其实更多的是经验问题，而不是技术方面的问题。
关于心态
回顾做这个项目，我觉得心态问题是最重要的，技术问题倒是其次。为什么这么说呢？因为对于10余年的老功能模块来说，其中最复杂的其实是业务逻辑，而并非技术实现。所以对于老系统的重构，你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚，这本身就给了重构者一个无形的压力。再加上又是核心业务模块，少一点业务逻辑就会导致线上收入的减少，最后就是 程序员 祭天的悲惨命运。这一系列的背景，使得重构之时心理压力真的很大。
现在回头来看，对于重构项目，最好的方式还是先仔仔细细梳理清楚所有的业务逻辑，之后将其用思维导图画出来，这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑，对于你后面进行系统重新设计以及编码都是大有裨益的，甚至是起决定性作用的一环。
说到心态这个话题，无论是做什么项目，即使是重构，也会涉及到排期问题。有时候很可能你自己还没完全了解业务逻辑之时，上级就要你给出一个排期，这时候其实作为重构者是很为难的。对于这种情况，其实我建议还是与上级做好充分的沟通，如果能延长给排期的时间是最好的。如果不能，那应该主动上报每天的进度，让上级知道你的进展。其实要你给出排期，不就是为了掌控进度吗。
当你给出排期后，很可能会出现了许多当时预估排期时没有出现的情况，这时候一般我们有两种选择：一种是急急忙忙草草处理了事，另一种则是稳定心态思考最好的解决方式。其实当你发觉另一种做法是更好的处理方式，但这种方式在目前排期下无法完成，这时候作为整体功能的开发重构人，你应该有自己的判断。即使是因为做了这件事情而延期，但只要你做的这件事情是对的，有利于系统拓展性和稳定性的，那还是应该坚持自己的选择。我想，如果你因为正确的坚持而延期，我想公司并不会因此而责怪，只要你给出了自己的理由。最怕的是惊慌失措地写完一个东西，而这东西又漏洞百出。
所以有时候觉得开发或重构一个系统真的是得抱着必死的决心，这样才能有自己的坚持，而不会在上级的排期压力之下做出错误的选择。特别对于重构类的项目，如果没有一个从容的心态，那系统是肯定做不好的。
关于技巧
我觉得重构中的经验技巧远重要于技术实力，因为一个经验可以让你减少很多不必要的麻烦。在说出我的心得之前，我想问一个问题：
在你重构的时候遇到一个问题，这个问题解决了会更好，但不解决也不会影响到此次项目的结果。请问，此时你是解决这个问题，还是不解决好？
有些人会分析：这要看情况，如果我有时间我会去解决，如果没有时间，那我就会跳过它。一般会给出这种答案的人，都是理论上的巨人，行动上的矮子，基本可以断定没有经历过实战。因为其分析很符合马克思主义的辩证主义思想啊，这也确实没错。但这样的解决方式对于实际情况是不够有用的。
对于这种情况，我建议是不做。准确地说：对于任何不影响你达成重构目标的事情，能不做就不做。因为你永远不知道这个坑到底有多深！在你并不知道坑有多深，而此时又有排期（追兵）在后面，这时候最聪明的做法就是不做。等你把必须做的做完了，你再回头来看看这个问题，如果你可以解决，那就尝试着解决。但如果此时你发现坑真的很深，你可以果断返回，这时你其实已经做完了事情，并不会有排期的压力了。这样的做法给自己留足了后路，自己可进可退，可攻可守。但如果你一开始就选择踩这个坑，那么可能你会让自己陷入泥潭。
所以建议大家在不清楚的情况下不做，不是叫大家做事懒惰。而是让大家明白自己的目的是什么，在资源（时间）有限的情况下把事情做成。
关于技术
技术是放最后的，因为我确实觉得技术在重构中并不是特别重要。至少在我这次重构中，我基本上60%的工作都是因为我的心态或技巧不足导致的重复劳动。我项目中重构涉及到的技术，我只用了不到10%的时间就完成了。回头想一想，真是觉得好凄凉。
重构中的技术其实更多的是使用 设计模式 将复杂的业务逻辑用简洁的代码呈现出来。简单点来说，就是用设计模式承载复杂的业务逻辑，尽可能使写出的代码简洁。
怎么样才是一个好的系统重构呢？其实有一句话说得特别好：对拓展开放，对修改封闭。意思就是说别人只能拓展你的代码，而不能修改你的代码。很多老系统为什么会越来越复杂？逻辑越来越多？原因就是他写的代码允许别人进行修改。这么说可能会很抽象，我们举个例子说吧。
|
1 2 3 4 5 6 7 |
if(type == apple){ //deal with apple } else if (type == banana){ //deal with banana } else if (type == ......){ //...... } |
上面这段代码模拟的是对于水果剥皮的处理程序。如果是苹果，那么是一种拨皮方法；如果是香蕉，则是另一种剥皮方法。如果以后还需要处理其他水果，那么就会在后面加上很多 if else 语句，最终会让整个方法变得又臭又长。如果恰好这个水果中的不同品种有不同的剥皮方法，那么这里面又会有很多层嵌套。
可以看得出来，上面这样的代码并没有满足「对拓展开放，对修改封闭」的原则。每次需要新增一种水果，都可以直接在原来的代码上进行修改。久而久之，整个代码块就会变得又臭又长。
如果我们对剥水果皮这件事情做一个抽象，剥苹果皮是一个具体的实现，剥香蕉皮是一个具体的实现，那么写出的代码会是这样的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
public interface PeelOff { void peelOff(); } public class ApplePeelOff implement PeelOff{ void peelOff(){ //deal with apple } } public class BananaPeelOff implement PeelOff{ void peelOff(){ //deal with banan } } public class PeelOffFactory{ private Map<String, PeelOff> map = new HashMap(); private init(){ //init all the Class that implements PeelOff interface } } ..... public static void main(){ String type = "apple"; PeelOff peelOff = PeelOffFactory.getPeelOff(type); //get ApplePeelOff Class Instance. peelOff.pealOff(); } |
上面这种实现方式使得别人无法修改我们的代码，为什么？
因为当需要对西瓜剥皮的时候，他会发现他只能新增一个类实现 PeelOff 接口，而无法再原来的代码上修改。这样就实现了「对拓展开放，对修改封闭」的原则。
其实上面这种设计模式是最基本的设计模式：抽象设计模式。对于各种复杂的业务情形，还有其他许多设计模式，例如：代理模式、装饰模式等等。但各种模式归根到底还是考察你对业务的理解能力以及抽象能力，如果你对业务足够理解，你即使不知道某个设计模式，你也会写着写着写出这样一个设计模式。
总结
此时重构的经历让我觉得十分痛苦，但熬过来了就觉得没什么了。忽然感叹道重构还是很有技巧性的，对于技术要求反而没有那么高。重构更多考验的是对业务的深入理解，对抽象思维的进一步运用。如果业务理解深入，有抽象的思维，那设计模式还可以一点点学出来。而如果反过来，则没有办法做下去。
重构何其苦，且做且前行。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
C++标准程序库
[德] Nicolai M. Josuttis / 侯捷、孟岩 / 华中科技大学出版社 / 2002-9 / 108.00元
这本包含最新资料的完整书籍，反映出被ANSI/ISO C++语言标准规格书纳入的C++标准程序库的最新组成。更明确地说，这本书将焦点放在标准模板库身上，检验其中的容器、迭代器、仿函数和算法。读者还可以找到特殊容、字串、数值类别、国际化议题、IOStream。每一个元素都有深刻的呈现，包括其介绍、设计、运用实例、细部解说、陷阱、意想不到的危险，以及相关类别和函数的精确樯记式和定义式。一起来看看 《C++标准程序库》 这本书的介绍吧!
