业务编码心得

413 阅读4分钟

我习惯将所有的业务、所有的需求, 都看作一个问题, 利用解决问题的思考方式, 结合业务编码的特性, 我在下面定义了业务编码的5个关键步骤.

需求评审

首先, 我会先将需求,在我的知识体系里面消化一遍, 进行一些最基本的考量:

  • 它是不是一个需求?
  • 这个需求是给谁用的?
  • 这个需求的最终目的是什么?
  • 现成的功能是否已经满足了这个需求?

之后, 我会重新理解一遍该需求, 重述该需求, 看看双方理解是否有偏差.

以上, 是基于产品思维的简单考量, 当然如果你有更丰富的思维方式, 也可以在这个阶段进行头脑风暴.

接着, 我会以研发的角度, 用程序员思维来审视这个需求, 比如:

  • 该问题是不是研发能解决的范畴?
  • 用面向过程的思维思考该需求是否有致命的漏洞?
  • 用面向关系的数据库设计思维来审视这个需求当中表述的关系是否完整?
  • 用面向对象的编码思维来审视这个需求当中各对象的关系是否清晰?
  • 用面向API的思考方式来审视这个页面(原型、设计图) 是否表述了明确数据需求?

最后, 我会进行可行性分析, 这环节主要是根据自身和自身团队情况进行分析, 判断该需求的可行性是否在容忍范围内.

需求分析

需求评审完毕后, 该需求基本可以被转为待办了, 表示该需求能做, 并且有必要做.

那对于研发来说, 需求分析这一步需要完成什么呢? 我的答案是问题转化: 抽取需求最核心的部分, 把需求背后代表的问题, 转换为研发问题, 比如说:

  • 需求可以视为一个排序问题, 并且要获得Top K大的数据
  • 需求可以视为一个有状态问题, 需要利用一定的存储结构保存某些数据, 再提供读
  • 需求可以视为一个内容管理问题, 类似论坛类的系统
  • 需求可以视为一个发布订阅问题, 有消息发布方, 也有消息接收方
  • 需求可以视为一个即时聊天领域内的问题, 需要建立聊天室这样的概念

实际情况中, 一个需求还可能需要拆分成多个子需求, 子问题, 每个子问题再进行单独分析, 这个过程通常就是模块划分.

开发模型

经过问题分析后, 我们则需要选取一个开发模型来解决我们的问题, 这里从简单到复杂可以包括很多内容:

  • 选取一门语言, Java ? node.js ? Golang ? C++
  • 选取一个中间件, 搜索引擎 ? 消息队列
  • 选取一种存储产品, SQL ? noSQL ?
  • 选取一种编码模式, 面向对象 ? 函数式编程 ? 面向切面 ? 面向事件
  • 找到现成的API

通常, 这个步骤也叫: 技术选型、架构设计、面对对象设计, API设计等等.

当然这个阶段也需要进行一定程度的可行性分析.

最后, 就可以依据自己定义或选取的开发模型进行具体的编码了.

理清依赖

在编码前,或者再编码中, 我还会做一门功课叫: 理清依赖, 这个步骤帮助区分好各个系统、各个模块、各个类的边界, 对依赖进行隔离, 保证代码高内聚、低耦合, 方便快速变更与扩展. 我最常用手段有: 依赖倒置、单一职责原则、分离接口与实现

通常这个步骤下来后, 能够显著提高程序的可测试性

测试验证

这个步骤相对来说心得经验较少. 但通常至少需要做的是进行核心、底层模块的单元测试, 有条件的情况下进行一个较为完整的接口冒烟测试, 再看下测试提高的测试计划与用例, 检验哪个部分的逻辑会有缺漏, 没时间就抛给测试了.

进行单元测试的时候, 有个核心的概念就是: 何为单元?

有一个非常好用的准则就是: 没有依赖的代码逻辑. 没有依赖是相对来说的, 取决于你定义的单元粒度, 一旦确认后, 其他依赖通常会用Mock的手段来获得它们的返回结果, 比如说:

  • 前端对后端API接口的Mock, 对第三方API接口的Mock
  • View层对ViewModel层的Mock, ViewModel层对Model层的Mock
  • Service层对Dao层的Mock
  • 单个类中对其他Bean的Mock