#yyds干货盘点#关于梳理前端业务的探索和实践

前言

业务是我们日常工作围绕的主体内容和背后逻辑, 对于前端工程师来说业务的形态相较于后端会有所差异, 比如我们有可见的页面, 我们会谈用户交互, 更贴近用户的日常操作和行为习惯. 任何一个软件经过一段时间的开发后, 业务都会开始变得复杂, 由于现代软件的开发迭代速度非常快, 短则数日, 长也不过月余, 这就导致软件背后的业务逻辑呈现出错综复杂的形态, 可能对于用户来说看到的是一个日益成熟完善的好用的软件, 但对于工程师而言, 好用的背后却不一定是好维护的代码, 日积月累之下, 不合理的甚至的错误代码就会越来越多, 为此我们需要进行工程化的治理, 周期性的保证代码和业务之间的匹配度。

正文

业务和代码的匹配度

所以什么是业务和代码的匹配度, 此处的匹配主要指的是业务的抽象和代码之间抽象的对应程度, 比如可能一开始我们为业务开发了 2 个页面, 但经过一段时间, 业务上已经把其中一个的内容合并到了另一个页面, 并且做了功能整合, 但我们的代码还是两个 page, 这种就是匹配度低的表现.

由此可见, 高匹配度的代码可以很好的关联到当前的业务形态和业务功能, 而低匹配度的代码则无法分析出具体的业务逻辑, 往往需要花精力从更直观的业务形态再联系到具体的代码. 这显然会花费不少维护成本. 但如何做到代码和业务的高匹配度呢?

这关键在于首先得把梳理清楚, 只有把业务梳理清楚, 我们才知道业务是如何变化的, 才能做相应的代码修改以匹配业务的变更.

过犹不及, 业务梳理的适度性

如果你有一辆车, 想要保养的特别好, 你可能需要每天都擦擦洗洗, 即使清理每一粒灰尘, 但我们都知道大部分车子都是出了 4s 店就打七折, 而且随着时间推移车辆的折旧率会越来越高, 一辆即便看起来几乎是新车的二手车和一辆还凑合的二手车价格相差并没有那么大, 至少和你投入的保养成本相比.

为此我们需要寻求保养成本的适度性, 这在业务梳理这件事上也是成立的.

甚至可以简单的说, 依靠人力, 我们是做不到对业务文档的实时维护, 就更不要提同时保障代码的匹配度, 这么做你几乎可能要投入一个研发的大部分时间和精力. 所以在业务文档的梳理和维护上, 我们可以采取周期性的方式, 在维护成本上寻求一个可持续的平衡, 以我们公司按月迭代的速度为例, 我们通常每季度会对业务文档进行一次较为全面的检查更新. 差不多是 3 个迭代的样子.

前端业务文档梳理的内容

根据前端业务形态的差异可能会有所不同, 此处以 PC 形态的业务为例.

PC 形态的业务包括

• 页面 (功能的集合)

• 首页
• 子页面 (不包括 404 之类的通用功能页, 此类页面除非和业务有耦合, 不然可不做梳理)

• 子页面的子页面...

• 可交互组件 (功能)
• 不可交互组件 (往往是后端数据操作的结果)

我们采用的梳理流程基本上也遵循, 从页面(或者叫功能模块) → 可交互组件(行动点) → 不可交互组件, 一般采用泳道图和功能使用链路来串联整个业务流程。

对于这种业务梳理和画图有个原则是各位必须遵守的, 即不能业务绘图中加入和思考技术性的细节, 比如请求服务端, 因为那样就脱离页面的范畴了, 又比如体现异步特征, 或者加入一些功能化的内容, 像 Loading, 错误页面等等.

画图抽象最忌讳的事情就是抽象的范围和粒度不一致, 这是抽象思考的大忌, 很多人经常会有一种不切实际的想法, 就是把他想体现的内容都画到一张图里去, 对于这种想法, 我想说, 首先这很难难到几乎不可能, 其次会很乱, 任何一张图都会有一个主题, 这个主题限制了你的内容表达和抽象层次, 当你试图打破这个主题的时候, 就会导致表达上的混乱, 这其实和摄影很像.

摄影初哥经常犯的毛病就是, 啊景色好美, 我要都拍下来, 拍完之后, 一看照片, 我草, 这什么鬼.

因此对于业务梳理来说, 一般主题都是围绕业务这两个字, 所以什么是业务, 大家都有的那就不叫业务了, 至少不是你的业务, 你自己特有的, 或者说只有你知道的和你们团队关心的那就是狭义上的业务.

也只有把这个狭义上的业务理清楚, 弄明白了才是对日常工作最有帮助的东西.

对于这种业务梳理和画图有个原则是各位必须遵守的, 即不能业务绘图中加入和思考技术性的细节, 比如请求服务端, 因为那样就脱离页面的范畴了, 又比如体现异步特征, 或者加入一些功能化的内容, 像 Loading, 错误页面等等.

画图抽象最忌讳的事情就是抽象的范围和粒度不一致, 这是抽象思考的大忌, 很多人经常会有一种不切实际的想法, 就是把他想体现的内容都画到一张图里去, 对于这种想法, 我想说, 首先这很难难到几乎不可能, 其次会很乱, 任何一张图都会有一个主题, 这个主题限制了你的内容表达和抽象层次, 当你试图打破这个主题的时候, 就会导致表达上的混乱, 这其实和摄影很像.

摄影初哥经常犯的毛病就是, 啊景色好美, 我要都拍下来, 拍完之后, 一看照片, 我草, 这什么鬼.

因此对于业务梳理来说, 一般主题都是围绕业务这两个字, 所以什么是业务, 大家都有的那就不叫业务了, 至少不是你的业务, 你自己特有的, 或者说只有你知道的和你们团队关心的那就是狭义上的业务.

也只有把这个狭义上的业务理清楚, 弄明白了才是对日常工作最有帮助的东西.

已经是共识的业务并没有梳理的价值

我在上面的图例放了一个和简单的业务, 大致上就类似, 你打开外卖 APP, 有个按钮叫吃啥好, 你一点跳到一个页面, 一排优选的商家列出来了, 这个业务流程就这么简单, 对于大多数人来说体感是很强的.

就好比一说网上购物, 你脑子里就会冒出一整个从找东西, 到购物车, 下单, 支付的流程, 这个业务流程几乎人人都知晓, 因为大家日常就是这么做的, 而对于前端来说, 在 2C 领域里大多数业务其实没有梳理的价值. 原因就在于我前面说的一句话, 什么是业务, 是你特有的, 你有, 我有大家都有的业务已经是一种共识了, 将共识梳理出来, 就好比我们把自己一天的作息写下来, 就跟流水账的日记一样是没有意义的. 因为这流水账并不能帮你改善些什么.

所以我以前在 2C 领域里看到的前端团队但凡提到梳理业务这件事, 最后都不了了之, 因为大家做到最后发现这业务其实并没有什么可梳理的. 因为整个业务流程已经被抽象的很好了, 对应的我们甚至能闭着眼睛把代码的结构设计出来, 有几个页面, 搞几个组件, 组件之间怎么交互, 数据怎么流转等等.

这里彦衍生出一个业务梳理的前提 特定领域的业务, 非共识化的业务, 且持续不断变化的

如果你们团队要搞业务梳理, 要写业务文档, 可以看看是否符合这 3 点. 如果都沾不上边, 我觉得可以就省去这道工序了.

而我们之所以做这件事, 也是因为我们所做的业务基本符合这 3 点. 对于财税软件来说.

• 财税属于特定领域
• 关于如何管理财务, 怎么申报税才是最好是没有共识的
• 国家的财税政策变化日益频繁, 且不断持续深化改革之下, 财税的内容和规则变得日趋复杂.

而正是如此, 对于身处我们这个行业的前端来说, 一份好的业务文档就显得格外重要.