浅谈重构中踩过的坑.docxVIP

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