下次老板让你重构系统,让他看看这篇文章.pdfVIP

下次老板让你重构系统，让他看看这篇文章 编者按：面对遗留的老系统，人人都很不爽，都想推倒重来。但是要如何推倒重来呢？听听 余晟的看法，本文首发于他的微信公众号余晟以为（ yurii-says ） 上个月，有个以前的同事问我： 你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊“ ” 。 我说： 我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、“ API 通讯机制 的建立、内部分层的整理。 ” 他说： 对，但我还是想知道，你为什么不把系统重做了呢？“ ” 于是我问： 我离职之后，后来似乎多投了不少人重做系统？结果怎么样呢？“ ” 他说： 结果，结果就是做业务要同时操作三四套系统“ ……” 就我所见，把原有系统 推倒重来“ ”的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说 ，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统 推翻 重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕 …… 所以都想拿出 敢叫日月“ 换新天 ”的劲头，来个干脆的彻底解决。 这种心情可以理解，但在我任内 重做系统“ ”一直没有被提上日程，整个技术团队所做的都是 改良“ ” 的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、 API 通讯机制 的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然 推倒重来“ ”，我未必 能比继任者做得更好，甚至可能更糟糕，因为 推倒重来“ ”绝不是那么简单的事情。 众所周知，软件开发的难点之一就是控制复杂度。但是在不同的领域，复杂度有不同的表现。对于 纯互联网 业务，或者 IT 基础架构来说，其复杂度在于软件本身，架构的制定、类库的选择、编码 的质量等等。对于其它 IT 系统 —— 尤其是公司迅速成长，业务不断复杂化的 IT 系统 —— 而言，其 复杂度并不在于软件本身，安全、性能、负载的问题都套用现成的 IT 解决方案，真正的复杂度来自 系统承载的业务本身，比如最简单的：系统里有哪些单据，各种单据承载什么信息，用在什么场景 ，这些单据是怎样流转的，各种单据 存在怎样的约束关系，出现异常情况应当如何处理才能保证业 务数据的一致性 …… 这些问题没有准确而稳定的答案， IT 再怎样努力也是白搭。 对于已经能在线下规范运行的业务，或者是有经典解决方案的工作（比如财务、仓库管理），这些 知识都是现成的，可以直接拿来用。但对于新兴领域、新兴业务来 说，往往不存在 经典解决方案“ ” 。加上很多公司成长速度飞快，一开始并没有构筑好的 IT 基础（其实是业务架构基础）。典型的情 况就是： 业务概念混乱不清 。业务逻辑层也是杂乱无章，很多系统里干脆把数据库当作业务逻辑 层（这可不是说笑，因为数 据库无法推脱责任了）。结果，混乱的业务逻辑依附于糟糕的