认识达内从这里开始

当工程师在进行软件开发的时候，如果时间比较赶的话，一般都是先让软件上线，然后在后期的工作中慢慢重构修补来替换当初因为时间不足而留下的漏洞。

今天，我们就从心态、技巧、技术这三方面来简单了解一下，在进行软件重构的时候，我们都需要注意哪些问题。

关于心态

回顾做这个项目，我觉得心态问题是最重要的，技术问题倒是其次。为什么这么说呢?因为对于10余年的老功能模块来说，其中最复杂的其实是业务逻辑，而并非技术实现。所以对于老系统的重构，你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚，这本身就给了重构者一个无形的压力。再加上又是核心业务模块，少一点业务逻辑就会导致线上收入的减少，最后就是程序员祭天的悲惨命运。这一系列的背景，使得重构之时心理压力真的很大。

现在回头来看，对于重构项目，最好的方式还是先仔仔细细梳理清楚所有的业务逻辑，之后将其用思维导图画出来，这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑，对于你后面进行系统重新设计以及编码都是大有裨益的，甚至是起决定性作用的一环。

说到心态这个话题，无论是做什么项目，即使是重构，也会涉及到排期问题。有时候很可能你自己还没完全了解业务逻辑之时，上级就要你给出一个排期，这时候其实作为重构者是很为难的。对于这种情况，其实我建议还是与上级做好充分的沟通，如果能延长给排期的时间是最好的。如果不能，那应该主动上报每天的进度，让上级知道你的进展。其实要你给出排期，不就是为了掌控进度吗。

当你给出排期后，很可能会出现了许多当时预估排期时没有出现的情况，这时候一般我们有两种选择：一种是急急忙忙草草处理了事，另一种则是稳定心态思考最好的解决方式。其实当你发觉另一种做法是更好的处理方式，但这种方式在目前排期下无法完成，这时候作为整体功能的开发重构人，你应该有自己的判断。即使是因为做了这件事情而延期，但只要你做的这件事情是对的，有利于系统拓展性和稳定性的，那还是应该坚持自己的选择。我想，如果你因为正确的坚持而延期，我想公司并不会因此而责怪，只要你给出了自己的理由。最怕的是惊慌失措地写完一个东西，而这东西又漏洞百出。

所以有时候觉得开发或重构一个系统真的是得抱着必死的决心，这样才能有自己的坚持，而不会在上级的排期压力之下做出错误的选择。特别对于重构类的项目，如果没有一个从容的心态，那系统是肯定做不好的。

关于技巧

我觉得重构中的经验技巧远重要于技术实力，因为一个经验可以让你减少很多不必要的麻烦。在说出我的心得之前，我想问一个问题：

在你重构的时候遇到一个问题，这个问题解决了会更好，但不解决也不会影响到此次项目的结果。请问，此时你是解决这个问题，还是不解决好?

有些人会分析：这要看情况，如果我有时间我会去解决，如果没有时间，那我就会跳过它。一般会给出这种答案的人，都是理论上的巨人，行动上的矮子，基本可以断定没有经历过实战。因为其分析很符合马克思主义的辩证主义思想啊，这也确实没错。但这样的解决方式对于实际情况是不够有用的。

对于这种情况，我建议是不做。准确地说：对于任何不影响你达成重构目标的事情，能不做就不做。因为你永远不知道这个坑到底有多深!在你并不知道坑有多深，而此时又有排期(追兵)在后面，这时候最聪明的做法就是不做。等你把必须做的做完了，你再回头来看看这个问题，如果你可以解决，那就尝试着解决。但如果此时你发现坑真的很深，你可以果断返回，这时你其实已经做完了事情，并不会有排期的压力了。这样的做法给自己留足了后路，自己可进可退，可攻可守。但如果你一开始就选择踩这个坑，那么可能你会让自己陷入泥潭。

所以建议大家在不清楚的情况下不做，不是叫大家做事懒惰。而是让大家明白自己的目的是什么，在资源(时间)有限的情况下把事情做成。

关于技术

技术是放最后的，因为我确实觉得技术在重构中并不是特别重要。至少在我这次重构中，我基本上60%的工作都是因为我的心态或技巧不足导致的重复劳动。我项目中重构涉及到的技术，我只用了不到10%的时间就完成了。回头想一想，真是觉得好凄凉。

重构中的技术其实更多的是使用设计模式将复杂的业务逻辑用简洁的代码呈现出来。简单点来说，就是用设计模式承载复杂的业务逻辑，尽可能使写出的代码简洁。

怎么样才是一个好的系统重构呢?其实有一句话说得特别好：对拓展开放，对修改封闭。意思就是说别人只能拓展你的代码，而不能修改你的代码。很多老系统为什么会越来越复杂?逻辑越来越多?原因就是他写的代码允许别人进行修改。

重构更多考验的是对业务的深入理解，对抽象思维的进一步运用。如果业务理解深入，有抽象的思维，那设计模式还可以一点点学出来。而如果反过来，则没有办法做下去。

作者：陈树义

来源：博客园

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。