企业开发中，你“会说话”吗？

比较下面两行

 

5000*14=？

---

茶啊二中开展为期两周的师生运动打卡活动，小强同学决定每天走路5000步，照这样下去，活动结束后，小强同学累计走多少步？

---

 上面两道题答案相同。所不同的是，前者是计算题，后者是应用题。再一点，对于二三年级的小学生来说，能答对第一道题，未必能答对第二道题。

 

下面是正文

 

企业应用系统通常是针对特定的业务领域和企业需求而开发的。这些系统被设计用于支持和优化企业的各种业务流程和操作。 企业应用开发也就是围绕这些业务领域来开发和维护，它要求开发人员具备一定的技术知识和对业务需求的理解，以确保开发出满足企业要求的高质量应用系统。 企业应用开发是一个复杂的过程，需要跨多个阶段和团队的合作。在日常的需求研发过程中，我们要站在业务实现的角度来分析、设计、沟通交流，达到信息的正确传达和一致性。

 

身为程序员，当你与同行朋友聊天时，如果被问到你做的是什么？你回答“我做一个springboot项目”，或者回答“我做的是一个系统”，对方多半获取不到什么信息。对方可能想知道的是，你从事什么样的应用系统的开发工作。你这样回答“我们做一个聚合支付系统，对接了许多银行通道，商户可以简捷地接入我们，实现多银行多渠道资金支付”，或回答“我们做的项目是个SAAS系统，为企业客户提供差旅出行服务”，这些回答可以传达更多有价值信息。

 

系统里的交易表，交易金额类型是bigint，以“分”为单位来存储数据。用户页面上，自然是显示以“元”为单位的金额。这种情况下，就需要分与元的互转工具方法。代码如何写？我认为每个同学都没问题，不过是数字乘以100或除以100而已。所不同的是，你站在的角度不同，编写出来的代码会不同。

BigDecimalUtil {     long multiply100(BigDecimal)     BigDecimal divide100(Long) }

MoneyConverter{    long convertToFen(BigDecimal)    BigDecimal convertToYuan(Long) }

不凭借代码调用，单看上面两个工具类，我们得到的信息就不一样：前者是一个Long与BigDecimal以100互转的工具，后者是关于金额的分与元的互转工具。

 

我们刚投产的一个需求是“分账API支持多通道”。我不清楚当时的产品需求名称，在技术团队内的项目进度表和开发组里是这个名字。先介绍一下背景，背景一：分账指的是合作商户通过我们平台对接的银行通道实现平台管理费和服务结算款的资金划转；背景二：分账API是我们给合作商户提供的发起分账充值的API接口，其中的通道指的我们平台对接的银行通道；背景三：在我们系统里，每个合作商户的分账通道需要在后台运营系统配置。我们提供的商户门户系统里会引导商户按照事先配置的银行通道进行分账交易，而我们提供给商户的分账API此前写死了中信银行，就是说商户通过API接口发起分账的话仅限中信银行通道。now，你听到这个“分账API支持多通道”需求，你理解是什么需求吗？或者说，你所理解的这个需求会是什么呢？
看看下面这种理解：理解①：商户通过分账API发起分账，既可以走A通道，也可以走B通道。理解②：我们熟知的购物类APP，通常支持组合支付，我们下单支付时，可以同时结合券、满减、银行卡完成支付。这个需求，莫非也是支持商户同时使用多银行通道来完成分账交易。。
实际的需求是：商户通过API发起分账时，不再只按中信银行通道来判断了，而是与商户门户系统操作对齐，根据事先配置的银行通道来执行分账交易。

 

明辉同学分享我们系统中的开票业务。在开头，他先引入了发票相关的知识，包括发票的概念、发票的种类、发票票面包含的内容、发票与收据的区别。我们日常工作生活中经常接触到发票，例如打车发票、餐饮发票，但多数同学未注意这些票据。正好赶上明辉这次分享，大家在轻松活跃的气氛中，对发票知识有了一定的了解。这个富有带入感的引子，促成他的后续的系统业务实现逻辑的分享过程中得到了很好的互动。大家对发票知识产生兴趣，顺其自然地好奇我们系统是如何实现的开票业务，不仅理解得透彻，同时，还针对一些实现展开讨论，并提出改进建议。

 

试想，如果干巴巴地按照文档里的描述的逻辑和流程来解说，效果会怎样。填鸭式的培训、宣贯以及教育带来的收益往往甚微，人纯靠记忆力来记住一些知识，这些琐碎的孤立知识，可能会遵循艾宾浩斯记忆曲线的路子逐渐从大脑中消失。还以我们的系统为例，曹老师分享企业入网的流程。讲到企业的认证时，一会是调用易保全通道去做认证，一会是企业上传授权书认证，一会是打款认证，一会是未认证不需要认证，把企业的开户状态与认证状态再一结合，听的同学云里雾里。因为曹老师的分享内容和流程，一方面是基于代码梳理的，一方面是自己数度参与了企业入网的需求开发。曹老师对这个业务的理解并不深入，或者说未思考升华到实际的业务领域。

 

关于认证，后来，我举了一个简单的例子，一些同学的任督二脉遂被打通。什么例子？→我们使用打车软件时，首先要上传我们的身份证信息来实名登记，另一块，这些APP要求我们做人脸识别等活体认证。这两个都属于认证，不同的是，一个是证明用户是个真实存在的人，一个是证明用户是活生生的本人。

 

同样的业务还有结算。我们平台涉及到企业与服务商的结算、企业与自由职业者的结算。一些产品需求里经常直接简化为“结算”，开发人员对“结算”的概念和业务也一知半解。这导致在业务代码和数据表里出现了许多笼统的settle/settlement，甚至有的业务直接把两个结算业务使用了同一张表，程序实现也杂乱繁杂，增加了系统的理解难度和维护难度。“结算”通俗的概念是，根据业务往来和一定的业务公式，计算出来谁该谁多少钱。（清算：偿清 结清 实际的金钱资金，把该给的钱给上。）

 

说1000道10000，我们对自己所做的事情要有清晰的认识。——这是个空洞的口号，正如家长挂在嘴边的那几个字“好好学习”一样。——那么，如何做到呢？首先，团队内成员要对系统有整体的认识，其次，开发团队内，对特定的业务形成一致的语言和术语，统一词典，形成规范。每个人都是系统的建设者和守护者，我们要不断遵循和持续关注这些词典。再次，在需求评审时，开发团队要充分理解需求，发现需求描述不够准确和具体，及时反馈，与产品团队达成一致。最后，最重要的，我们要要求自己严谨一些，靠谱一些，说“人话”，说直白的话，说人能听懂的话。当我们正确理解需求和工作任务，无论使用人类语言，亦或计算机语言，呈现出来时都明确。用人类语言，沟通表达出来时就不会有歧义，用计算机语言，程序实现出来就易读易维护。