一个企业级的应用，即使是诸葛亮级别的设计人员，最初的考虑都不可能尽善尽美，会存在设计不够或者设计过头的情况。加上业务的发展可能与当初的推想不一致，这样就使得上线初期稳稳当当的一个系统，在若干轮的需求驱动下，就变成了补丁之上打补丁，活成自己讨厌的样子。当然，我们也可以把锅往最初的设计和开发上面扔，但还是解决不了系统维护越来越困难的事实，“累了，毁灭吧”想推倒重构的想法其实是大家喜闻乐见的。

然而对于企业级的应用，系统的重构，不管是对软件供应商，还是对企业本身，还都是个痛苦的过程。重构不仅要需要考虑众多的技术、业务因素，也需要考验甲乙双方的管理水平，协调能力等等。如果涉及到软件供应商的更换，那么这个事情就难上加难了。

大家所期待的，是重构后系统更加适应现在的业务，使新的需求、新的业务开发更加丝滑，大家所担心的，其实是伤筋动骨后，系统如何能够保证业务的稳定性和准确性，大家对于重构的态度其实是：像一个少女等待他的男朋友，既怕他不来，又怕他乱来。  

对于喜欢的部分，主要靠设计和开发的大牛们来实现，而对于害怕的部分，就主要看我们交付的兄弟们了。

虽然如此，但是现在如果去百度一下，如何确保系统重构时的业务准确性，甚至你去问chatgpt（没错，我问过了），得到的答案绝大部分与设计和开发有关，却很少有测试和实施的部分。

主要原因是实施方面与业务相关性太强了，要总结这方面的共性，无非就是数据迁移要准确、回归测试要充分之类的，至于如何保证，那就要开始说业务特性，但说业务，有点无从下嘴的感觉。

当然，今日份的骨头，我啃了。

电信运营商的计费系统可能是最不敢在重构时乱来的企业级应用了，“计费”这两个字就说明需要极强的准确性。在计费系统的重构实施中，对于如何确保业务准确性，形成了自己固定的一个自己固定的套路，也就是对账。计费系统的工程实施人员，很多从事的第一项工作就是对账。当然，对于发量充足的新手，这时候自然要发出灵魂三问：

我是谁？你是计费系统实施人员。

我从哪儿来？刚从公司总部出差而来。

要到哪儿去？你要对账。什么是对账？

（头发丝落在了地上，没听见一点声响，忧伤的悲伤的音乐响起）。

对于被这么硬核强扯到“对账”这个名词一脸无辜的同学，还是要先给对账做个定义，这个词源头应该来自于会计专业（可能与计费系统的前身与财会有很大关系有关），在计费专业，对账这个词的意思一般是，对重构前（老系统）和重构后（新系统）的系统运行的结果，进行差异比对的过程。只有这个比对的差异到了足够小，一般是一致率到99.99%，才说明新系统的计费结果是准确的。你可能认为这种手段比较极端，但是本着我能崩溃，程序不能崩溃的原则，这种手段其实是很必要的，不然计费系统永远没底气上线。

聪明如你，其实已经发现，对账其实是一种回归测试手段，因为如果对任何程序：“输入 + 程序处理 = 输出”的话，那么对账就是对输出的比对，用来确认新的程序是否存在不能兼容老的程序的问题。

也就是说，对账其实就是使用相同的数据源输入（有时候未必能做到，可以使用尽可能一致），经过不同的程序处理（老系统和新系统）后，通过比对输出，来对新程序的正确性进行判断，并且通过修改程序来纠正新程序的错误的一个过程。当然，对于一个大的系统重构，这个程序处理应该替换为系统处理，因为整个大的系统处理的流程、配置、资料结构都可能出现大的修改，差异的原因，也往往需要从程序、流程、资料、配置等几个大的方面去寻找。

计费对账在计费系统重构时，非常重要，甚至可以说，工程实施的很多工作，都是围绕对账来进行的。基本上，计费系统的所有工程实施人员，从事的第一项工作就是对账，其实这并不是因为对账是个简单的工作，恰恰相反，对账是所有工程实施工作中最难的，它需要有扎实的业务功底，也需要非常熟悉新老系统。

那为什么基本上所有的工程实施人员第一课都是对账呢？原因很简单，从业务学习的角度来说，对账是一个最好的切入方式，也是一个相对容易上手的方式。但是，也因为这个工作要做好，实际比其他任何的工程实施工作要复杂，要难，所以基本上所有的新手压力都非常巨大。

首先要说个无用的废话，对账的准备最重要的是，对于计费系统的重构实施的进度，到了能够对账的程度。这其实也是实施中一个重要的里程碑点：