大话重构连载：遗留系统——软件工业时代的痛

看了楼上最后一段总结，基本得出结论，即便现有2种开发票的方法，现在新增一种，你依然是不会去做整合，而是新开一条路，“输入输出中间那段数据处理，随便怎么写”。我们所痛苦的老项目，正是有大量这样的人每时每刻伴随着这种思想，而导致了无可控制。

我们可以因为苦衷而在错误的道路上艰难前行，但我们不能将这种错误的道路视为正确，更不能将正确的道路视为错误，这是一个基本的价值观。

请注意我的语境：
所以我说：重构是代码级别的，只适用简单的情况或者系统的开发阶段。
如果目前系统中已经有100种开发票的方法了，还要再增加一种极其特殊的情况，怎么办？
理智的方式是看：系统当前的方式里能不能解决新的需求，不能的话.....

我认可重构可以解决简单的情况和局部问题。如果是简单的系统，核心业务逻辑总共在万行级别或者以下那种的，整个系统重构一遍也未尝不可，既然是重构了，跟新做了个系统有啥区别的？无非就是copy的多少的问题，如果是一个业务复杂的庞大系统，如果对某个简单的局部重构也行，大面积的重构？能解决问题么？或者重构的了么？

我们现在理清一下思路：

    重构是代码级的，只能解决逻辑清晰不清晰的问题，对于不断增加业务需求，重构也许能让问题变得简单，也许会让问题变得更抽象难于理解，这个楼上认可不认可？

在需求不断增加不断变更的大前提下：

    楼主说的系统经过几次需求变更之后业务需求文档变得模糊不清是哪出了问题？ 是重构不重构以前系统代码能解决或者带来问题么？

    设计思路已经跟不上变更的脚步是哪出了问题？ 是重构不重构以前系统代码能解决或者带来问题么？

    程序代码则随着业务逻辑的复杂而臃肿不堪是哪出了问题？ 是重构不重构以前系统代码能解决或者带来问题么？

    程序员开始读不懂代码是哪出了问题？ 是重构不重构以前系统代码能解决或者带来问题么？


思考一下上面几个问题。

我现在也没捋清楚到底不同的争论纠结在哪，但貌似重构，不是解决遗留系统众多问题的银弹。

嗯

小样，干了几年开发了？来谈重构？

程序猿：老大，我要把我们系统进行重构，需要5个月时间，这期间我将不吃不喝不眠不休日日加班夜夜操劳，最终将把我们的软件系统提高到一个崭新阶段。

项目经理：很好，那么5个月后这500个需求也就全部完成了吗

程序猿：一个都没有完成，就是重构啊，您懂得

项目经理：额，那么，系统性能应该提升很多吧，现在查询很慢啊，你也知道的

程序猿：性能提高？也不会的啊，就是重构啊，您懂得

项目经理：那这5个月可以不发工资吗

程序猿：不行啊，老大，重构是高级活，您还得加工资呢

项目经理：我一脚踢飞你，快干活去，在这做梦

好问题，在大话重构里已经给予解答了，不过那是在最后一章，你只有耐心等待了：
http://fangang.iteye.com/blog/2081995

这里给你摘一段吧：
作为老板，对待重构通常要分两个阶段：最初阶段，老板是不支持系统重构的。这个阶段，老板比较直观的想法就是，本来运行好好的，要重构出错了怎么办？这个阶段老板通常不支持大范围的重构，系统级别上的重构，但在部分地方小修小改还是不会反对的，只要别出什么乱子。然后，遗留系统在日后的运行维护过程中问题越积越多，维护的成本越来越高，变更的风险越来越大。当遗留系统开始走向一种恶性循环以后，老板慢慢开始转变态度，开始支持系统重构了。最后，当我们终于说服老板开始系统重构时，老板通常要问的一个问题就是，我们怎样来评价系统重构的效果呢。我们说我们可以通过系统重构改善遗留系统，我们可以通过系统重构改善代码质量，可以通过系统重构提供系统的可读性、可维护性、易变更性，然而老板不喜欢听这些。我们应该怎样评价我们提升的效果呢？我们是提升了一点点，还是提升了很多，甚或还是依然在原地打转。作为老板，他所关心的是实效。因此，我们需要一系列的指标来做出评价。

终于明白楼主的意思了，你说的这些准确的说不叫重构，叫迭代开发。

看看是不是这种情况吧：

1.花费n个月完成了一个项目：System1.0
2.m个月后，忽然发现System1.0版本不怎么适用了，针对现有的缺陷和问题开发：System2.0
3.n个月后，忽然发现System2.0版本不怎么适用了，针对现有的缺陷和问题开发：System3.0
......

随便看看所有的开源项目，都是不断的根据新需求不断迭代开发，开发出适应性更好新版本软件。
如果这样的话，需要重构的话就重构，不需要重构的话重构有什么意义呢？重构就是refactor，重新组织重新组装的意思，就好比我一句话说的罗嗦了或者跑题了，我重新组织一下，为的是把话说明白。
迭代开发无非可能有下面几个内容：小修小改——改进，推倒重来——重新设计和开发，另加东西——新增特性（功能），废弃东西——关闭特性（功能），等等。

所以用“重构”这个概念 偷换了 小修小改——改进，推倒重来——重新设计和开发，另加东西——新增特性（功能）
三种概念，才是这个帖子的症结所在，重构是个外来词，千万别偷换了它的外延和内涵。

你关键是还没有理解什么是重构。毫无疑问，重构与迭代开发都是敏捷开发的重要组成部分，敏捷开发将他们有机地组织在一起，你中有我、我中有你。但重构不等于迭代开发，它们各自描述的是敏捷开发的两个方面：迭代开发是一种项目组织形式；重构则关注于代码应当如何修改与维护。

搞了半天还在纠结概念么？那么我引用一下楼主认可算是比较权威的引用吧：

    重构，就是在不改变软件外部行为的基础上，改变软件内部的结构，使其更加易于阅读、易于维护和易于变更[1]。

[1] Refactoring: a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.  ——引自《重构：改善既有代码的设计》


注意：“在不改变软件外部行为的基础上”
外部行为没变，我认为可以理解为软件的功能没变、数据输入、数据输出、操作流程和方式都没变，什么都没变的话如何能满足变化了的需求？不还是得为了新需求迭代开发么？咱不说迭代开发，客户听不懂这个，咱就说给现行软件打补丁，不还得继续打补丁么？

那么就回到了文章的核心内容里了：重构能解决软件需求不断膨胀，软件规模不断膨胀的问题？

我多次提出重构只能解决代码清晰不清晰的问题，吹的再高级点，重构还能一定程度上解决软件健壮性的问题。

但是，这和解决需求不断膨胀是两码事，如果负责编码的人思路足够清晰，对需求的理解足够准确，一点不用什么高深的“设计模式”也一样能编写出健壮、有效、正确的软件。尤其是有众多开源框架可以用来解决各种系统常见需求的今天。

做软件项目的团队：软件交付使用，上线运营，项目核心人员基本就算可以撤出，后期维护还要大动干戈要重构？谁听了第一反应就是：这是不是在搞笑？

做软件产品的团队：软件自身就需要版本迭代，比如chrome这个浏览器版本号居然30+了还在不停升级，那么如果需要重构，全完可以放在下个版本里迭代开发，把相应需要重构的地方推倒重建。

就跟上面有个回复很有意思：老板说：我们软件多了这样那样的新需求；程序员说：给我开双倍工资我把系统重构一下；老板说：重构了就能解决这样那样的问题了么？程序员说：不能，只是重构，您知道的......

只能说井口有多大，能看到的天就有多大

业务逻辑的走向和软件设计还是不同的，你是愿意写出“业务说一句，你写一行”的流水账的代码，还是通过一定的设计模式架构出高可用，高扩展的代码，这就是一个人的眼界

新需求来了，当然可以在原逻辑中添加if else，再来再加

也可以将主逻辑抽象成模板，新的扩展只需实现新的子类，新的子类只需实现不同的特征，取决于一个人的经验，态度和能力

代码抽取那叫refactoring，业务抽取那叫re-engineering，英文单词都不一样的，别想太多，重构在一个类，一个包中也许还合适，到大规模业务范畴内，难。

那天遇到一个简单的例子：我们有个字段叫 ProductName ，不知从哪年开始有个傻子填进去的就是 UID，而不是产品的真正名称，就这么一个简单的要命的需求变更，前前后后开了2个礼拜的会，就是没办法改正过来。

楼主举的地址信息表的例子，“将地址提取出来单独形成一个“地址信息表”，在真实世界里，这么做，倒霉的一定是楼主，因为一定有别的系统已经默认去访问原来的位置。


一个错误会污染到其所有的使用者，结果就导致错误成为了惯例甚至是规则。