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

吐槽几个地方

1. "不知从哪年开始有个傻子填进去的就是 UID"  "一个错误会污染到其所有的使用者"。
真的就没有想过为什么会出这样的错？怎样在开发流程中杜绝这种低级错误？有没有测试？有没有code review？（虽然这么说，但是我理解你。因为我所在的团队和你们的一样。但是，这不是借口，对吧）

2. “在真实世界里，因为一定有别的系统已经默认去访问原来的位置。”
这句话太理解你了，因为我们也都在写这样的业务和sql。然而，我是从一个做server系统的团队跳过来做业务系统，所以对软件可能更倾向于优雅的设计和代码的最佳实践。所以，当我看到这种现象时，我大吃一惊。在一个健康的软件设计中，如果这个table由我的系统所管理，那么其他系统对它的调用，万万不能直接写SQL调用（我知道有时候复杂逻辑时被迫sql跨表甚至垮库级联性能可能快一些）。各种外围系统错综复杂的直接调用，不仅容易出错，而且容易出错。所以，正确的做法是你应当提供外界所需的基本调用的高级语言层面API，比如java，而事先无法预料的需求，首先你要扩展你的API库，比如将修改用maven更新到某个中央库，外围系统开发人员更新后使用（别以为说得狠炫酷，也别以为复制黏贴不用动脑经会省时间）。

     这个叫什么？叫组件化思维。

    举个恶心的切身感受，上礼拜正在写的系统中，有一个涉及到插数据到某个其他库中等需求。我们怎么做的，首先让那个库相关系统的人拷给我一份包含了他业务逻辑的java代码，然后一行一行看把它的业务逻辑删掉，然后在合适的地方添加并处理我系统的参数，匹配它拷给我的sql（里面包含了各种空字符串值和null值，还有hardcode字段值），问他我的参数需要插哪几个字段，然后才能写完。
   用一个project专门管理核心系统中需要被外界调用的中间层的API，你可能觉得复杂的需求这样做是不够的，但是，别以为API只能传递string int long，对于复杂的需求往往需要在API方法签名上传递抽象类，匿名类，泛型等。在这个项目中，编译出javadoc.jar（让别人少问你问题），编译出sourcecode.jar(让别人在IDE中debug)。
  觉不觉得这样像在做开源软件？觉不觉的在恶心的业务系统crud之外尝到一丝春天的甘泉。

虽然我这么说，但是我还是理解你，理解吐槽的大家，因为老系统的重构涉及到的因素不仅仅是技术层面的，事实上在一根绳子上的蚂蚱，谁都左右不了被拉向深渊。（当然，作者似乎是被请去做leader负责重构的，有这个话语权，同时技术也扎实的话，书里所说的的确是对的）。而我们大部分人只能感叹：“世界上最恶心的事情不是看翔一样的代码，而是为了保持统一，将自己的代码模仿翔的样子写出来”。

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

如果当初的设计者和相关人等在10年前已经辞职，那么你就会发现根本没有人能够把事情说清楚，也许在某行代码里有注释，但是 anyway ，目前没人知道。否则这样的系统就不会叫遗留系统了。


组件化也只是看上去很美好的概念而已，在企业中，很多时候大家需要重用数据而不是逻辑，用 Java 和 C# 编写一套漂亮的组件又如何，A 部门的新软件想用 PhP 访问你的数据，C 部门说他们只熟悉 C/C++ 和 SP， F 部门想直接用 QlickView 连接数据库，X 部门在搞大数据，打算用XXXXX牛皮技术。迫于各种压力，作为妥协的结果，最后数据都会暴露给别的部门使用。

组件化阻止不了业务对数据表的锁定。


别老想着把系统设计得漂亮，凑合着能跑就好了。

@ray_linn
哎，可以看出你的无奈也是长期被迫养成的，共勉共勉啦

想重构的永远不是第一个，在你之前，也有同样牛B哄哄的人，之所以搞不动，肯定有个大黑坑是填不了，而且往往超越了技术范畴的。

是的，这就是我前面说的，“因为老系统的重构涉及到的因素不仅仅是技术层面的，事实上在一根绳子上的蚂蚱，谁都左右不了被拉向深渊”

所以我更倾向于能够在编码的过程中快速迭代重构，优化架构，但是这个强大的能力和经验是需要以往的长期积累。所以成了一个圈，越是不锤炼自己，越是上手写不出好代码；越是写的烂，越是挖的坑大。于是就造成了一个状态：很多人是会写代码，但是不懂“编程”。

编码过程中，其实怎么重构都无所谓，最多也就是害了程序员阿甲阿乙的模块跑不了；一旦上线之后并移交出去，这个系统就成为“系统”中的“系统”，这时候谨慎应该高于一切。

@ray_linn
嗯，挺好的
“别老想着把系统设计得漂亮，凑合着能跑就好了”

尝试过，没有成功。。。。婚恋网站不好做。。。。

@boywukong  不需要再把以前那100种开发票的方法在纠结进来。 这句话我非常同意。

这就是客观上的高内聚，低耦合。

如果考虑了以前的100种，QA测试会很痛苦的。

不明白这种完全背离软件复用原则的事情，怎么还会有那么多人去支持。
另外，分开独立100条线，才是真正的高耦合。