银行核心系统之报表开发：如何写一份程序员爱看的报表Mapping?

在开发报表的阶段，作为应用负责人，你肯定遇到过如下的痛点吧：

含辛茹苦地写完报表Mapping，开发人员却不看文档，要求你先讲解一遍；
开发人员反复来回地确认表和字段的含义、处理逻辑等，问的你一脸懵逼，只能默默地去修改文档；
开发完成，进入测试阶段，想着一锅香喷喷的米饭就要上桌了，打开一看，居然是热腾腾的一锅粥~；

以上问题之所以会发生，主要的罪魁祸首当然是你的Mapping，写的有问题：
一堆文字描述，开发看起来，犹如吃了安眠药，不想看；
抽数逻辑有遗漏或存在不清楚的点，开发/测试需要反复确认规则，浪费大量时间；
简单的问题就口头说规则，后续文档没有更新文档，出现BUG后开始扯蛋...

那么，如何写一份程序员爱看的报表Mapping?

将从以下6个原则来说：

1.规则的完整性。因为写抽数规则过程中，有时没能把需求想清楚、或是会漏掉一些细节，那么开发碰到问题就会问这点/场景/情况没有考虑到，该如何处理？如果Mapping比较完整，偶尔有遗漏也还好，但如果非常不完整/经常出现这种问题，那么开发慢慢就不愿意看这份Mapping文档，会觉得看了也白看。因为很多细节都没有写清楚，那还不如就坐在旁边碰到问题就问。所以完整性很重要，首先是体现你的专业性，其次是影响开发的进度。
2.规则的准确性。举个栗子，比如说我们提供给用户一份系统存量数据的手工补录文档，文档列出了20个栏位，却没有标识哪些栏位必输或选输、或是什么情况是必输什么情况是选输；再如，文档中的A栏位我们写出了长度最多支持60位，那到底是支持60个英文字母呢还是60个汉字、万一输多了会怎么样；再如，文档中的B栏位与A栏位的长度要求一样，那么可能会写同上，其实这样也是不准确的，因为在开发眼中可能理解为B栏位与A栏位字段的值域一样，所以为了避免产生歧义发生问题，必须要写的更准确些。
3.规则的清晰度。首先整个抽数规则的结构，该换行的换行、该分段的分段、该标粗的标粗，能够让开发或团队成员一眼就能抓住重点，知道你的整体逻辑是什么样的，比如以哪张表为主档案进行抽数、以什么样的顺序编码性能更好、或是对性能有什么样具体的要求(比如执行时间不能超过1分钟)，而不是说报表重跑起来很快，不能用很快这样的词，更多是要使用数字。开发人员做起来才清楚，知道怎样做才符合要求。
4.描述的简洁性。若是文字描述抽数逻辑时，需要言简意赅。其一、开发不原意看一大堆字； 其二、废话少一点，因为有时会情不自禁的写上抽数用途等。所以要一二三点直接写出逻辑，不要写无意义的词，否则没法提高质量。简洁很重要。
5.规则的稳定型。其实，抽数规则的稳定性，与需求的理解离不开关系。经常也会遇到报表同事吐槽，比如抽数规则改来改去。所以，无论是写Mapping规则也好、还是进行需求分析时，最好是先将需求想清楚，与同事/领导审批、和用户或IT确认清楚，补充完复杂部分的抽数逻辑后再转给开发。不过说回来，需求百分百不变是不可能的，比如人行下发了一封通知文件，每个人的解读是不一样的，用户的理解也可能存在误差，所以规则确认后不要随意变来变去。
6.能够开发报表。即可执行性，与第3点有点像。写出来Mapping，别人看了知道该怎么开发，不可有含糊点，才有利于开发或测试。