【架构设计】从业务场景出发，从事开发工作

前言

从实习到工作，可能会有很多不知道是对的或是错的想法，需要我们一个个去实践，然后验证。这篇文章主要有两个目标：

1. 总结来时路，以昭后途
2. 分享心得与收获

一、观点总结

在一家互联网公司或者一家企业的技术部门，从事产品研发，用代码的方式工作赚工资，在从事这类工作的过程中，我也认为带着业务的视角进行编码很重要。

二、从业务出发从事开发

 2.1 作用

     我也认为这样做确实很有代理，因为从业务出发，从事开发工作，可以帮助我们快速快速理解需求，从产品层面理解业务从而组织自己的代码逻辑，实现甲方的需求，有时候甚至能想在业务方或者（PM、PD）前面。

2.2 案例分析

案例一：

当业务方发现一些他之前没有考虑到的场景，提出需要优化上次做的功能时，你其实在上次需求实现的时候比较深入地考虑过这些，代码逻辑里面做了一定的扩展，这次优化只需要改动很小的地方就可以满足要求。你当然可以按照他们预估的时间接下这个需求，并且提前完成，这很爽，对吧?

案例二：

当产品出现线上bug时，需要排查问题。从以往经验来看，我认为可以分为 功能性bug和代码层面问题。

•  功能性bug是代码确实按照需求文档实现了，但是是功能设计和产品设计上的欠考虑导致的问题。

     比如需求上要求做一个文本框，用户可以输入文字、上传图片、发视频、发语音，这些功能代码都很好地实现了，代码质量本身没有问题。可是在线上运行的时候发现，用户输入的文字中带有emoj表情（就是这种 😁😁😁，我们手机输入时经常可以用到的）时，服务器报错，简而言之就是功能出问题了，是之前产品设计的时候没有考虑到这种情况。 （题外话，如果遇到这种情况可以参考下消息中有emoj表情的处理方式 ）

• 代码层面问题分为三种情况

• 一种是 逻辑错误，说白点就是写代码的时候，逻辑不对，自己想错了
• 另一种是 手误 ，这种情况很好理解，比如数字 1 写成 字母 l，用错了方法（本来要用StringUtil.isNotBlank()对String类型进行判空的，错写成了StringUtil.isNotEmpty()）...
• 还有一种是技术问题，比如在有并发的场景下没有进行相应处理等

在排查问题的过程中，如果单纯地从代码逻辑、日志上分析原因，有时候难免会有些理不清头绪。如果这个时候，以

  观察日志 -> 对比代码 -> 充分想象问题出现的可能业务场景 -> 再对比代码验证猜想

的流程，可以先确定问题出现场景，在这个过程中，我们当然能大概判断出来是哪一类问题（功能bug还是代码层面问题），接下来进一步确定问题、对症下药就好啦~
这样，思路是不是就清晰好多？

三、 怎么实现

3.1 能力储备-日常开发

日常开发中，写代码的时候，尽量将功能逻辑从前端顺到后端（这个相对来说比较好实现，日常开发中我们会经常这样做）

• 举一个简单的例子，接口的代码实现（略）

小明被需要开发一个接口，简略的要求如下：
1、接口提供给前端
2、接口的作用是新建
3、前端与后端约定好出入参及错误码
4、新建后，数据库中 xx表 新增一条记录
这里假装有张图
接口实现好了，方法的单元测试和接口测试都ok了，交付给前端了，联调也ok了，是不是就完事了？
感觉还差点啥，对吧？经过上面的需求分析、功能开发（可能还有测试过程）并交付后，似乎有这么几个问题不清楚：
1、这个需求的背景是啥？
2、这个需求要实现的一个功能具体是怎样的？
3、我写的这些代码发布上线后，作为产品/项目/app的一部分，在里面充当什么角色？
4、用户做了哪些操作会触发前端调用这个接口？
5、我这个接口与DB交互后，数据库多了一条记录，这一条记录会在哪些场景下用到？哪些方法会用到这条记录？这条记录中的哪些字段会被其他接口用到？这条记录中的哪些字段会透出到页面上，用户能感知到？

我认为，把以上5个问题搞清楚了，再进行开发（或者边开发边理解这些问题，再或者开发后逐渐了解这些问题），这样我们对当前开发的代码所处的业务场景就比较清楚了，而且是结合代码沉淀自己的业务场景，增加自己的能力储备。
经过一番了解和理解，小明了解到：

1、需求大背景
当前的系统是一个半即时性的问题解答的平台（名字叫A平台），用于一家 比较有规模的办公用品公司 的售后环节，平台的主要使用方是公司的客服和技术支持人员。
客服在接到用户的投诉、咨询电话后，会先根据公司提前发给他们的《日常答疑手册》进行处理用户电话中提的问题，对一些技术性比较高、需要技术人员协助排查的问题，客服只能在A平台上提工单，系统内部分配工单到相对闲置的技术人员，技术人员通过工单内容了解情况，回复工单后，客服根据回复内容为用户答疑。

2、需求功能的具体实现方式
当前需求需要完成 工单创建这个功能，需要
前端一个页面提供给用户（就是客服）填写表单，里面包括 问题类型、机器型号、机器使用时间、机器的问题描述等信息
后端提供接口用于工单创建
DB里面的工单表（tb_ticket）插入一条记录，包含 记录id、提单人（客服）工号、提单时间、提单内容等
前端同步调用接口。用户（客服）点击“确认提交”的按钮后，前端页面调用后端接口创建工单，后端接口执行（DB中插入记录）成功后，返回给前端 创建成功 的信息，前端拿到 创建成功 的信息后，页面提示给用户（客服）“工单创建成功”，并跳转到工单详情页面。

3、代码发布上线后，充当什么作用 - 综合“需求大背景”和上述 #1、#2了然。

4、客服进入系统 -> 客服点击进入提单页面 -> 客服填写表单 -> 前端非空等表单校验通过后展示“提交"按钮 -> 客服点击“提交”按钮 -> 前端调用后端接口

5、 DB交互后 tb_ticket 表多一条记录，记录字段有 id（记录的唯一性标识）、create_by（提交人的工号）、create_time（工单创建的时间）、product_model（产品型号）、duration_of_use（使用了多久）、problem_desc（问题描述）。
创建工单的时候插入这条记录，工单详情页面展示这条记录中的信息（客服和技术支持人员均能看到），技术人员在线回复工单后平台给客服发送消息推送（工单内容是“xx您好，您于 xxx时间提交的工单有回复了，跳转链接 https://xxxxx”）
工单查询方法、发送推送消息的方法里面会用到这条记录的信息
除了id，上述的几个字段信息都会展示到工单详情页，消息推送时 create_time 的信息也会推给用户

小明现在大概了解到代码实现之外的业务，并且经过这次的开发，积累了一个新的业务场景，下次有类似的业务场景出现时，可以轻松套用，更容易理解啦~

3.2 能力储备-日常生活

   个人理解的产品的思维模式是需要渗透到日常生活中，通过对生活周边的所见所闻进行一些反思，尝试用产品经理的思维去理解这些事情、现象，培养自己的产品思维的习惯。
比如：

• 小明去楼下超市买东西，结账的时候使用 扫码付款，发现几个点：

• 买完东西，收银员用扫码枪扫描商品外包装上的条形码，录入商品信息，收银系统展示商品价格并计算总额
• 给收银员出示二维码，收银员选择“开始收款”，用另一个扫码枪（有时是用同一个）扫码收款
• 扫码后等一会儿后，付款的手机上二维码页面会跳转为“支付成功”页面，整个付款过程结束。

• 其实，从这三步中或许可以拓展一些问题：

1. 收银员在使用商家扫码枪的时候好像有商家自己的一套商品管理系统和收银系统（或者是一个系统中的两个功能模块）？
2. 为什么扫码枪扫了商品外包装的条形码，就能识别商品信息？识别了商品信息后系统怎么就能立刻展示出商品的价格？
3. 为什么扫码枪扫了手机上的二维码，就能在付款方的账户中扣指定金额？商家的收银系统和付款的软件（支付宝、微信）之间貌似在扣款的过程中进行了某种通信（两个系统在暗送秋波？(:з」∠)）？
4. 商品包装上的二维码是商品生产的时候生产商印制的，为啥售货的商店里面有扫码机扫一下就能查到信息，售货方和生产方式系统打通的还是？
5. ......横向、纵向拓展出去，问题简直是“子子孙孙无穷尽也”

所以，在这种一个个生活场景中，多想想、多注意下这些细节，并尝试用技术来解释他们的实现方式，或许在这种过程中会加深自己对技术的理解。直接点的结果可能是，下次我们做为开发同学，遇到类似的需求，能够通过联想的方式脑海浮现出实际场景，能更立体地理解需求，对需求中的实现目标中的细节能更好地把握。

3.3 思维应用

• 以 3.2.上的例子为延伸，再举个栗子。

小明买完东西，回到工位，产品经理找到小明：“小明，帮忙写个功能，我们需要一个用户扫码登录的功能。就是网页上展示一个二维码，用户通过手机扫码实现登录”（当然还有具体的设计 PRD）
刚刚经过买东西时的一番思考，小明觉得之前扫码付款和这个新需求似乎有共通的地方。emm.....脑海中似乎又浮现出一幅画面，实现方式放一边，对需求似乎很容易就理解了呢~

3.4. 具体措施-锻炼产品思维能力

3.4.1 画时序图

  网上找了微信扫码支付的时序图（时序图咋画、作用啥的度娘比我知道得多）

3.4.2 对需求尝试自己画原型

画原型的工具有很多，好用的 Axure 需要收费（破解）、墨刀，产品大牛，当然还有好些开源的软件或者在线绘制系统（找度娘）。
一句话，在对需求理解不是很深刻的时候，尝试自己画原型，可以在设计交互的过程中发现需求场景中的各个边边角角，将自己代入到用户的角色中，不同性格、民族、肤色、文化背景、使用目的的人群可能会做不一样的操作，在将自己代入其中进行原型设计的时候，原型run的时候会自然地给自己一个反馈：“这个地方的思考是对/错”。

3.4.3. 尝试理解测试（尤其是功能测试）的工作方式

测试分好几类，白盒、黑盒，单测、接口测试、功能测试、性能测试and so on.
其他的不说，功能测试，会从功能的角度去测试功能的各个应用场景，需要在任何场景下，功能运转结果是确定的、一致的，尝试用这样的测试思维对自己的功能进行反复自测，能保证功能的稳定性；同样的，在开发的过程中就将一个个场景分支与一个个if(){}else{}结合起来理解，会让代码更具象。

3.4.4. 尝试写一些前端页面

作用类同#3.4.2.，其实也是通过这种方式将自己代入到使用者/用户的角色中，深入场景。

四、带着业务的视角开发有什么好处

4.1 优点

• 业务需求理解起来更快速，能快速将需求转换代码逻辑，投入编码实现
• 对业务的理解更具体（因为有业务场景作支撑），能够发现产品设计中的真实“痛点”，先PD(产品设计师)发现问题，提升开发主动权
• 习惯了业务场景的模式切入开发，可能会逐渐具备PD的思维模式，后面转行做PD也貌似会轻松点（这是推测的。。）

4.2. 缺点（可能是）

• 从业务场景出发，进行开发，前提是分析、列举场景的时候要尽可能全面，如果不全面，助益较少（不过这种场景是可以积累的，一开始肯定会考虑不周，时间一长会有所改善）。所以如果你对实际场景的认知较少（比如一个消息发送的场景，发送消息的方式可能会有 text、video、img、url、auto，你能一开始就想到text中带有emoj么？同一个账号在同一时间在多台设备上登录，并且同时发送消息的情况有没有考虑？），一开始用这种方式会感觉没太大用。
• 会有一些朋友用业务的思维开发，业务思维开发带来的利好表象有一定迷惑作用。容易本末倒置，忽略自身技术能力的提升。
• 在实际开发过程中，如果用业务的方式理解需求，需要一定的前端底子（js就行），知道哪个页面的哪个功能的大概实现方式，不然，可能实现起来有点困难

相关文章

1. 带着业务的视角编码