关于心态回顾做这个项目我觉得心态问题是最重要的技术问题倒是其次。为什么这么说呢因为对于10余年的老功能模块来说其中最复杂的其实是业务逻辑而并非技术实现。所以对于老系统的重构你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚这本身就给了重构者一个无形的压力。再加上又是核心业务模块少一点业务逻辑就会导致线上收入的减少最后就是程序员祭天的悲惨命运。这一系列的背景使得重构之时心理压力真的很大。现在回头来看对于重构项目最好的方式还是先仔仔细细梳理清楚所有的业务逻辑之后将其用思维导图画出来这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑对于你后面进行系统重新设计以及编码都是大有裨益的甚至是起决定性作用的一环。说到心态这个话题无论是做什么项目即使是重构也会涉及到排期问题。有时候很可能你自己还没完全了解业务逻辑之时上级就要你给出一个排期这时候其实作为重构者是很为难的。对于这种情况其实我建议还是与上级做好充分的沟通如果能延长给排期的时间是最好的。如果不能那应该主动上报每天的进度让上级知道你的进展。其实要你给出排期不就是为了掌控进度吗。当你给出排期后很可能会出现了许多当时预估排期时没有出现的情况这时候一般我们有两种选择一种是急急忙忙草草处理了事另一种则是稳定心态思考最好的解决方式。其实当你发觉另一种做法是更好的处理方式但这种方式在目前排期下无法完成这时候作为整体功能的开发重构人你应该有自己的判断。即使是因为做了这件事情而延期但只要你做的这件事情是对的有利于系统拓展性和稳定性的那还是应该坚持自己的选择。我想如果你因为正确的坚持而延期我想公司并不会因此而责怪只要你给出了自己的理由。最怕的是惊慌失措地写完一个东西而这东西又漏洞百出。所以有时候觉得开发或重构一个系统真的是得抱着必死的决心这样才能有自己的坚持而不会在上级的排期压力之下做出错误的选择。特别对于重构类的项目如果没有一个从容的心态那系统是肯定做不好的。关于技巧我觉得重构中的经验技巧远重要于技术实力因为一个经验可以让你减少很多不必要的麻烦。在说出我的心得之前我想问一个问题在你重构的时候遇到一个问题这个问题解决了会更好但不解决也不会影响到此次项目的结果。请问此时你是解决这个问题还是不解决好有些人会分析这要看情况如果我有时间我会去解决如果没有时间那我就会跳过它。一般会给出这种答案的人都是理论上的巨人行动上的矮子基本可以断定没有经历过实战。因为其分析很符合马克思主义的辩证主义思想啊这也确实没错。但这样的解决方式对于实际情况是不够有用的。对于这种情况我建议是不做。准确地说对于任何不影响你达成重构目标的事情能不做就不做。因为你永远不知道这个坑到底有多深在你并不知道坑有多深而此时又有排期追兵在后面这时候最聪明的做法就是不做。等你把必须做的做完了你再回头来看看这个问题如果你可以解决那就尝试着解决。但如果此时你发现坑真的很深你可以果断返回这时你其实已经做完了事情并不会有排期的压力了。这样的做法给自己留足了后路自己可进可退可攻可守。但如果你一开始就选择踩这个坑那么可能你会让自己陷入泥潭。所以建议大家在不清楚的情况下不做不是叫大家做事懒惰。而是让大家明白自己的目的是什么在资源时间有限的情况下把事情做成。关于技术技术是放最后的因为我确实觉得技术在重构中并不是特别重要。至少在我这次重构中我基本上60%的工作都是因为我的心态或技巧不足导致的重复劳动。我项目中重构涉及到的技术我只用了不到10%的时间就完成了。回头想一想真是觉得好凄凉。重构中的技术其实更多的是使用设计模式将复杂的业务逻辑用简洁的代码呈现出来。简单点来说就是用设计模式承载复杂的业务逻辑尽可能使写出的代码简洁。怎么样才是一个好的系统重构呢其实有一句话说得特别好对拓展开放对修改封闭。意思就是说别人只能拓展你的代码而不能修改你的代码。很多老系统为什么会越来越复杂逻辑越来越多原因就是他写的代码允许别人进行修改。这么说可能会很抽象我们举个例子说吧。if(type apple){ //deal with apple } else if (type banana){ //deal with banana } else if (type ......){ //...... }上面这段代码模拟的是对于水果剥皮的处理程序。如果是苹果那么是一种拨皮方法如果是香蕉则是另一种剥皮方法。如果以后还需要处理其他水果那么就会在后面加上很多 if else 语句最终会让整个方法变得又臭又长。如果恰好这个水果中的不同品种有不同的剥皮方法那么这里面又会有很多层嵌套。可以看得出来上面这样的代码并没有满足「对拓展开放对修改封闭」的原则。每次需要新增一种水果都可以直接在原来的代码上进行修改。久而久之整个代码块就会变得又臭又长。如果我们对剥水果皮这件事情做一个抽象剥苹果皮是一个具体的实现剥香蕉皮是一个具体的实现那么写出的代码会是这样的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 MapString, 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 接口而无法再原来的代码上修改。这样就实现了「对拓展开放对修改封闭」的原则。其实上面这种设计模式是最基本的设计模式抽象设计模式。对于各种复杂的业务情形还有其他许多设计模式例如代理模式、装饰模式等等。但各种模式归根到底还是考察你对业务的理解能力以及抽象能力如果你对业务足够理解你即使不知道某个设计模式你也会写着写着写出这样一个设计模式。总结
不过还好，自己还是坚持下来了
关于心态回顾做这个项目我觉得心态问题是最重要的技术问题倒是其次。为什么这么说呢因为对于10余年的老功能模块来说其中最复杂的其实是业务逻辑而并非技术实现。所以对于老系统的重构你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚这本身就给了重构者一个无形的压力。再加上又是核心业务模块少一点业务逻辑就会导致线上收入的减少最后就是程序员祭天的悲惨命运。这一系列的背景使得重构之时心理压力真的很大。现在回头来看对于重构项目最好的方式还是先仔仔细细梳理清楚所有的业务逻辑之后将其用思维导图画出来这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑对于你后面进行系统重新设计以及编码都是大有裨益的甚至是起决定性作用的一环。说到心态这个话题无论是做什么项目即使是重构也会涉及到排期问题。有时候很可能你自己还没完全了解业务逻辑之时上级就要你给出一个排期这时候其实作为重构者是很为难的。对于这种情况其实我建议还是与上级做好充分的沟通如果能延长给排期的时间是最好的。如果不能那应该主动上报每天的进度让上级知道你的进展。其实要你给出排期不就是为了掌控进度吗。当你给出排期后很可能会出现了许多当时预估排期时没有出现的情况这时候一般我们有两种选择一种是急急忙忙草草处理了事另一种则是稳定心态思考最好的解决方式。其实当你发觉另一种做法是更好的处理方式但这种方式在目前排期下无法完成这时候作为整体功能的开发重构人你应该有自己的判断。即使是因为做了这件事情而延期但只要你做的这件事情是对的有利于系统拓展性和稳定性的那还是应该坚持自己的选择。我想如果你因为正确的坚持而延期我想公司并不会因此而责怪只要你给出了自己的理由。最怕的是惊慌失措地写完一个东西而这东西又漏洞百出。所以有时候觉得开发或重构一个系统真的是得抱着必死的决心这样才能有自己的坚持而不会在上级的排期压力之下做出错误的选择。特别对于重构类的项目如果没有一个从容的心态那系统是肯定做不好的。关于技巧我觉得重构中的经验技巧远重要于技术实力因为一个经验可以让你减少很多不必要的麻烦。在说出我的心得之前我想问一个问题在你重构的时候遇到一个问题这个问题解决了会更好但不解决也不会影响到此次项目的结果。请问此时你是解决这个问题还是不解决好有些人会分析这要看情况如果我有时间我会去解决如果没有时间那我就会跳过它。一般会给出这种答案的人都是理论上的巨人行动上的矮子基本可以断定没有经历过实战。因为其分析很符合马克思主义的辩证主义思想啊这也确实没错。但这样的解决方式对于实际情况是不够有用的。对于这种情况我建议是不做。准确地说对于任何不影响你达成重构目标的事情能不做就不做。因为你永远不知道这个坑到底有多深在你并不知道坑有多深而此时又有排期追兵在后面这时候最聪明的做法就是不做。等你把必须做的做完了你再回头来看看这个问题如果你可以解决那就尝试着解决。但如果此时你发现坑真的很深你可以果断返回这时你其实已经做完了事情并不会有排期的压力了。这样的做法给自己留足了后路自己可进可退可攻可守。但如果你一开始就选择踩这个坑那么可能你会让自己陷入泥潭。所以建议大家在不清楚的情况下不做不是叫大家做事懒惰。而是让大家明白自己的目的是什么在资源时间有限的情况下把事情做成。关于技术技术是放最后的因为我确实觉得技术在重构中并不是特别重要。至少在我这次重构中我基本上60%的工作都是因为我的心态或技巧不足导致的重复劳动。我项目中重构涉及到的技术我只用了不到10%的时间就完成了。回头想一想真是觉得好凄凉。重构中的技术其实更多的是使用设计模式将复杂的业务逻辑用简洁的代码呈现出来。简单点来说就是用设计模式承载复杂的业务逻辑尽可能使写出的代码简洁。怎么样才是一个好的系统重构呢其实有一句话说得特别好对拓展开放对修改封闭。意思就是说别人只能拓展你的代码而不能修改你的代码。很多老系统为什么会越来越复杂逻辑越来越多原因就是他写的代码允许别人进行修改。这么说可能会很抽象我们举个例子说吧。if(type apple){ //deal with apple } else if (type banana){ //deal with banana } else if (type ......){ //...... }上面这段代码模拟的是对于水果剥皮的处理程序。如果是苹果那么是一种拨皮方法如果是香蕉则是另一种剥皮方法。如果以后还需要处理其他水果那么就会在后面加上很多 if else 语句最终会让整个方法变得又臭又长。如果恰好这个水果中的不同品种有不同的剥皮方法那么这里面又会有很多层嵌套。可以看得出来上面这样的代码并没有满足「对拓展开放对修改封闭」的原则。每次需要新增一种水果都可以直接在原来的代码上进行修改。久而久之整个代码块就会变得又臭又长。如果我们对剥水果皮这件事情做一个抽象剥苹果皮是一个具体的实现剥香蕉皮是一个具体的实现那么写出的代码会是这样的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 MapString, 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 接口而无法再原来的代码上修改。这样就实现了「对拓展开放对修改封闭」的原则。其实上面这种设计模式是最基本的设计模式抽象设计模式。对于各种复杂的业务情形还有其他许多设计模式例如代理模式、装饰模式等等。但各种模式归根到底还是考察你对业务的理解能力以及抽象能力如果你对业务足够理解你即使不知道某个设计模式你也会写着写着写出这样一个设计模式。总结
