在软件项目开发过程中， BA会将对业务的理解输出成UseCase。该文档主要是体现将业务需求转化为技术人员能看懂的内容，使得技术人员理解需求（很多时候是自以为理解了），帮助技术人员进行良好的软件设计和编码。
但是很多技术人员在这步会犯一个特别严重的错误，简单的认为该文档的业务语言即是能够指导编程的技术语言，从而忽视了对于业务逻辑的二次梳理。
虽然有软件设计阶段，但这个时候，技术人员的精力大多是放在了数据库设计，接口设计，目录结构，程序命名，单元测试，搭建框架，工具选择等方面，而忽视了根据UseCase对于业务逻辑的二次梳理，使业务语言能够转换为技术语言。
将业务语言转化为技术语言，具有的好处是：
1有效的指导程序开发，技术语言和程序之间的差别基本上就很小了，不会存在很大的代沟和误差。实现为代码的效率和准确性都会更高。
2 能够快速响应变化。因为在二次梳理的过程中，很容易识别出易变的部分，能够预感到将来的变化，怎样变化，变化成什么样子。所以相当于变化之前就做好了相应的准备。当变化发生时，快速响应也就很容易了。
3 代码质量会提高。翻译为技术语言后，整个代码的逻辑会对象化，抽象化，模块化，这样会有效的提高代码质量。同时能够做到保证质量的前提下，快速响应变化，那么代码的质量一定是非常高的。这样就形成了闭环，互为证明。
关于如何将业务语言翻译为技术语言，下面介绍一个很玄妙的点，就是：
将一切不同的逻辑尽量梳理成一致的逻辑。
这里的关键点是尽量，这样就赋予了这件事情是不可量化的，是永远没有终点的，是永远没有终极答案的。每个人都能自圆其说就可以了。但说的水平高低，就靠自身能力了。
无法准确量化是很美的，它是构成了这个世界丰富多彩的原因之一，也是每个人能够在这个世界上有意义的活下去的基础之一。
第一个例子是某TOP车企车辆管理系统其中的一个案例：
如下这个需求的业务语言表述为：
如果是车辆申请的是京牌，需要到系统中校验一下京牌（特殊国情）的限额是否满足，如果满足就可以上牌操作。如果是非京牌，直接上牌。基本如下图所示。
目前存在两个相反的逻辑判断，是否京牌，导致了程序走向不同。经过梳理，会发现非京牌也可以去校验额度，只不过额度是Integer.MAX。
经过梳理后的技术语言如下：
如果是京牌，获取京牌的额度，如果是非京牌，获取非京牌的额度(默认Integer.MAX)，后面的步骤就完全一致了。
将一切不同的逻辑尽量梳理成一致的逻辑，中的尽量体现在：
1 京牌和非京牌是完全互斥的，无法调和的，所以做不到一致。
2 京牌非京牌的不一致限制在了灰色的范围中，实际的代码可以是一个类或者一个方法。此处可以扩展，可以应对变化。如果以后非京牌也需要限额，或者增加了沪牌，改动量非常小。
3 后续流程完全一致了。
第二个例子是TOP 1 电信设备公司的供应链供需匹配系统。
业务语言如图1所示，非常好理解，每个步骤内部十分复杂，但并不妨碍理解总流程。
但是如果按照这个理解去编写代码，最后的结果就是乱七八糟。
经过梳理后，建立了图2的技术语言：每个灰色框可以代表类或者方法，目的就是隔离不同的业务语言，使其不要影响技术人员的代码实现。
这样的好处有：
1 对于特殊输入的校验完全隔离，比如供应量是空列表，提前就可以知道结果。
2 匹配算法内部不需要进行各种校验，供应量是空列表，可以认为是有供应量，只是供应量为零。这样算法更加纯粹，也更加通用。
3 特别好给各个层级编写配套的单元测试。出现的任何Bug, 都可以方便的增加单元测试用例固化下来。
"尽量" 体现在：
获取数据是一致的，校验是一致的，初始化是一致的，算法也是一致的。
在分析业务逻辑的细节，转化成代码的过程中，多使用反向思维，比如 没有可以理解成有0个，这样就和有逻辑一致了；没有最大值，可以理解成有最大值，最大值是无限大。这样才能将一切不同的逻辑尽量梳理成一致的逻辑。
九阴真经下部的第一句话是： "天之道,损有余而补不足。是故虚胜实,不足胜有余"。虚比实好，缺比足强。我们所做的一切也都是在慢慢地不断地的尽量向完美前进，并永远不可能达到。
