最近一直忙于某铁路API升级，而今天遇到一个问题让我郁闷了好久，而最终的解决方案，引发了自己的一些关于抽象的思考。

问题如下：

在调用预订API的时候，需要提供旅客信息，根据API接口协议，需要传入用户的名和姓。

结果发过去一直报错，返回报文是“预订必须提供姓和名”。一直很郁闷，就在该铁路公司开发Wiki里面各种翻腾，终于找到了另外的例子。原来调用的姿势不对，应该是

抽象泄露

原来在铁路公司内部系统里面，技术人员对于Traveller的属性做了技术上的抽象，有了这个TravellerParameter的设计，仅仅通过配置就可以为Traveller扩充属性。

但是这种技术抽象对于G2Rail这样的业务合作伙伴就会产生不少挑战。为了对接，因为必须了解具体的技术设计和内部数据，必须要了解姓(Surname)的TyepId是11。这其实是一种抽象泄露(Leaky Abstraction)

Leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from. 

铁路公司API应该提供的抽象应该是具有领域业务意义的，而不是透露着技术细节。很简单的例子，对于这种情况，只需要把参数名改作first_name，last_name就可（可惜铁路公司的外包技术人员没做，也不Care）。

危险而愚蠢的技术抽象

更进一步，我开始思考是为什么程序员会设计出这种抽象。我的推断是这些程序员把自己拘泥于技术角色，他们的组织一定也是组件团队，因此才会往自己熟悉和擅长的方向去抽象。有了这层抽象，业务人员再提需求为Traveller添加属性的时候，只需要配置一下就可以了。

在G2Rail的早期阶段，因为团队对于铁路业务并不熟悉，而很多都是技术专家，因此在G2Rail第一代系统中迫不及待地通过重构和测试驱动开发，有了很多抽象设计。问题由于大家对领域不熟悉，而且业务不停调整（尝试），过早的抽象，引入了没有必要的复杂性。后期业务调整，这些早期设计并没有带来效率的提高，新代码代码也必须与早期的抽象设计适配，反而束手束脚。

G2Rail的玩法

感受到早期的痛苦（在保证系统正常运行前提下，完全重写早期的设计），我们渐渐总结出了一些自己的玩法：

打穿团队

G2Rail团队成员不会把自己限定于某角色&擅长，我们总是互相Step on toe of each other。互相了解领域背景，才能够从更加宏观的角度去定义问题，并思考方案。

延迟重构

让系统的Mess多残留一阵子，直到实在忍不住了，再去重构、抽象。通常忍不住的时候，是需要优化的地方，是系统的瓶颈。

业务优先

作为技术人员，首先需要把自己变成业务专家，比如通过做客服，写攻略等方式。其次尽量从业务角度去思考，把用户看成小白，简化和标准化业务流程，针对用户减少参数、提供更有业务意义接口和参数等等。