写代码之前应该做的几件事

开发 开发工具
作为程序员,刚刚开始学会写代码,常常是接过需求就开始撸代码。有时候发现,写完代码,需求变了。更多时候,觉得写业务代码枯燥无聊,没有技术含量。另外一边的事实却是,项目里面研发人数变多了,项目的质量缺却变低了,多人开发也不过是一个个单打独斗的组合而已。

 [[333522]]

作者:borisyang,腾讯 WXG 应用开发工程师

作为程序员,刚刚开始学会写代码,常常是接过需求就开始撸代码。有时候发现,写完代码,需求变了。更多时候,觉得写业务代码枯燥无聊,没有技术含量。另外一边的事实却是,项目里面研发人数变多了,项目的质量缺却变低了,多人开发也不过是一个个单打独斗的组合而已。

1 研发环境日益成熟

经历过 PC 互联网的不断深入发展,移动互联网的蓬勃生长,互联网进入了成熟繁荣期,研发环境也发生了巨大变化;从原来一个人,一把键盘,写完代码就上线,变成了更加规范的研发体系和更多人参与的共同协作。

研发流程不断加速

为了尽可能提高需求交付速度,跟上市场的变化,我们通过不断提搞软件交付的速度,尽可能的,从需求,编码实现,测试,发布的流程中不断优化,利用 CICD,加速迭代。


多人协作无处不在

现在的软件开发团队,即使再小,也有 2-3 人一起研发,更别提测试,运维,运营,产品人员。一方面是软件产品的竞争日趋激烈,需求日益复杂,堆砌人力成了必然;另外一方面是专业性的要求,精密的行业自然要求精细化的职业划分。

2 困局

研发流程的速度提上去了,团队的人也变多了,但是,需求变更依旧让广大研发同学感到痛苦,项目质量还在日益变差。

需求变更之痛

需求变更的痛苦为难了广大研发同学,前脚刚为了优化性能,采用了 kv 存储,后脚需求就变成了要支持模糊查询;这是一种典型的架构设计不合理,导致业务需求的实现方式受限。

更令人痛苦的,还有产品需求变动多,今天简单实现下,上线看看效果,明天用户脾气很大提了个诉求,再加一个功能上线,产品功能变成补丁加补丁。一方面是研发同学渴望一个完整又严谨的需求,提完需求进入研发阶段就不许改;另一方面是产品同学受到各方面的压力,只希望先把主要问题解决下,细枝末节以后再说。

项目质量变差

项目质量变差,一部分归功于补丁代码的产生,迫于时间受限,先上一个补丁,却打开了破窗的先锋,下一次,下一个同学就更敢于加补丁代码。一个个临时的 if else 不断堆砌,最终导致了整个项目的代码腐烂。我曾经维护过一个代码片段,超过 20 个 if else,中间还有些过时的错误注释夹杂其中,维护起来令人苦不堪言。

项目代码腐烂的另外一个原因是多人协作,团队的人越多,代码反而变得越烂似乎成为了趋势;为什么多人协作没有提高代码质量呢?一方面,多人协作实际上只是分摊的需求实现而已,大多数需求实现的分配中,反而尽可能将协作变少,避免实现受阻。另外一方面是,不同人的代码模块,设计意图和代码风格也截然不同。维护前人代码,如果没有全局视角,了解设计意图,也只能是往里面加补丁代码了。

项目代码腐烂容易导致程序员出现错觉,一是业务代码没什么料在里面,不如搞基础建设;二是业务需求不可能完整又严谨,最终也会变来变去的,最终质量低下的锅,一大半要给提需求的人。

3 怎么办

在写代码之前要进行设计和建模。相比历史短暂的 IT 行业,很多工业,建筑行业的精密性,都离不开前期的设计,在分析设计之后,按照图纸规划施工,写代码也应当如此。


设计建模的有效性源于,一,重新回到业务的跑道,跟业务一致;二,设计建模才能让协作真实有效;

为什么研发实现需求跟业务一致很重要呢?研发和业务需求的摩擦,本质是研发实现跟实际需求不一致,无论是研发走偏了,没有理解需求,还是需求本身不能满足涉众的利益,都会使得最终上线的功能需要回炉重造,折磨项目组的成员。业务项目,需求很重要,是整个项目质量的源头,源头的问题不处理好,会一直发散扩大,问题传递到尾部,甚至到了产品上线,对整体造成的损耗越大。从设计的语言上看,设计的层次有所不同,不仅仅有代码细节上的设计,也有业务上高层次的设计,高层次的设计是用业务的术语去表达,最贴近业务实际情况,也能帮助研发同学发现业务中不合理的点。

设计建模为何能让协作真实有效?我早先体验的协作流程,无非就是各自工作在自己的领域内部,彼此尽量减少要协作的内容,避免过多阻塞。研发侧的协作,因为缺乏设计,不好分工,另外一方面,多人写同一个模块,也会引发冲突,所以更多将协作放在在 code review 上。但 code review 作用范围也有限,一方面,review 成本较高,逐行阅读代码来厘清设计对代码质量要求很高,另一方面,review 时间节点往往发生较晚,临近发布的时候,调整设计也不大可能。进行设计建模能够让协作变得有效,一方面,设计建模前期是沟通和信息对齐,将协作的内容提前,一方面,采用合适的图形化工具,review 的成本是相对较低的。

4 怎么设计和建模

设计和建模分为好几个部分

业务建模,关注业务,不关注具体的实现

系统建模,关注所建设系统的边界,找准在业务中的系统的职责和约束

分析与设计,定位核心领域,找到实际的类,厘清类的职责和类之间的关系,通过设计使得代码抽象复用

业务建模

总体上来说,业务建模主要聚焦于分析涉众利益,厘清业务流程。从工具上来说,主要是用例图,流程图;从内容上来说,主要是找人(利益涉众,系统执行者),找业务实体(其余系统,相关的重要对象)。

分析涉众利益

分析涉众利益之前,需要找到涉众,一般要经历以下步骤:

找到软件产品的愿景,愿景表达了软件产品带来的核心意义

找到利益相关的的涉众和其利益诉求

表格是一个很好的表达方式,我负责的一个商户从第三方商城采购刷脸设备,由仓配系统配送设备的业务,可以表达如下:

愿景:将设备更多更快且准确无误成本低地卖给商户。

涉众 利益诉求
物料组老板 在准确无误的情形下,更多更快成本低地将设备卖给商户
设备渠道商 准确无误且快速地配送设备给商户
商户 更快地获得自己购买的设备
物料运营 更加准确的配送设备给商户

一般而言,涉众的利益是否被满足直接决定了软件产品的成功与否。而分析涉众利益需要进行详细的调研,研发同学可以根据产品的调研看到对应的涉众,及其利益。

业务用例图

知道了涉众的利益之后,就要分析业务流程,并对现有的流程进行改进。软件产品没诞生之前,业务是如何被处理的,找到原来业务的处理方式则可以梳理出业务用例。

笔者负责的一个业务是向购买设备的商户配送设备,对于业务团队的实际业务来说,用户购买设备有业务价值,业务用例如下:

 

 

物流公司和设备渠道商都是辅助购买设备的执行者,因此放到右边。值得注意的是,业务用例要体现价值,虽然在实际业务流程中,商户同时做了很多事情,比如签收设备,但签收设备不能反映业务价值,故而只有一个购买设备的用例。

业务流程分析

了解了涉众的利益并且画出用例之后,需要分析业务流程,找到我们软件系统能够改进的流程片段;完整的业务流程图可能很庞大,需要关注的是其中最有可能影响涉众利益的流程片段,如下为购买设备业务流程中配送设备的流程片段,该片段不大符合涉众利益;

 

配送设备的业务流程

可以看到,在原来的业务流程中,配送设备的流程是在全部业务流程中较为繁重,人肉工作量大的流程片段,不符合涉众利益;

  1. 收集商城订单信息不及时,导致配送不及时,影响涉众的利益
  2. 人作为节点参与处理,成本高,耗时长,也是不符合涉众利益的

所以很明显,我们的系统需要改进流程,替代人的部分工作

 

 

新的流程有效地满足了涉众“将设备更多更快且准确无误成本低地卖给商户”的利益诉求。

业务序列图中,每一个箭头代表的是职责,在业务序列图中,需要考虑的是职责的层次问题,过于小的职责放入流程图中,会导致信息过载,忽略最有价值的职责。在上图中,运营核对设备的配送信息是一个很重要的职责,在原来的需求中体现比较弱,研发同学可以借助业务流程的分析来分析需求中不合理的地方,完善需求,避免后期的改动,前期越是完善,后期的损失成本越低。

业务流程分析是一件很复杂的事情,研发同学可以利用需求中的信息,同时加上自己跟涉众的日常沟通和调研,把握核心的涉众利益,业务用例和业务流程,就可以解决大部分在需求上的理解偏差问题。

系统建模

系统建模关注的是系统与外部的边界和系统自身的职责

系统建模需要做的事情

  1. 画出系统用例
  2. 写出用例规约

系统用例图

系统用例图是业务流程中,系统执行者与系统发生的有价值的交互。系统执行者可以是人,可以是外部系统,甚至可以是时间。系统用例要体现系统的价值,系统会做很多事情来实现业务价值,我们应当关注业务价值。有些是低层次的职责,没有体系具体价值,如:“获取商城订单信息”是为了配送订单中的设备而发生,应当关注“配送设备”。

如下是仓配系统的系统用例图:

 


系统用例规约

有了业务流程图和系统用例图,需要根据进一步细化系统边界上的约束,保证系统的稳定性。系统执行者与系统的交互细化了详细的约束,系统的稳定性才能提高,如果没有仔细列出约束,有可能会忽略一些边界条件,导致系统的故障;如:仓配系统不考虑来自第三方商城订单要配送的设备数量限制,则会因为第三方商城出现的错误,导致资产损失。

系统约束来源于系统用例,根据业务的规则,详细地描述了业务流程中的基本路径,扩展路径和约束。

配送设备:

  1. 系统每小时向第三方商城查询待配送的订单
  2. 系统验证订单是否已经配送
  3. 系统验证订单要配送的 SKU 是否合法
  4. 验证订单中配送的设备数量是否超过最大限制 1000 笔
  5. 系统向物流系统请求给订单中的用户配送订单中的设备

因为步骤 2,3,4 还有其余可能的路径,称之为扩展路径。

  1. 订单已经配送
  2. 系统忽略该订单

这里的约束不是告诉研发同学如何实现功能,这里的约束是业务规则,厘清系统执行者与系统之间的边界,以及边界上的约束。设计评审的时候,可以关注关键路径上的安全规则是否到位,这么做对提高系统的安全稳定有极大的帮助。

类的分析与设计

这可能是大多数研发同学比较熟悉的领域,经典的设计模式,类之间的关系,泛化,组合等。但是类从哪里来呢?是从需求之中凭空产生?又或者突然灵光一闪,有了类的雏形?对类的进行设计与分析之前,需要做的是找到他

识别类

经历过业务流程,系统建模,我们终于来到了系统里面,来寻找类。我们所熟知的类有三种,边界类,控制类和实体类。边界类是外部系统在系统内部的映射,借由边界类,系统和外部系统交互。所以一些接口请求,输入输出都属于边界类的职责。在仓配系统中,商城就是一个边界类,将外部系统转移到内部系统来,屏蔽了接口请求相关的细节。控制类往往是体现用例流程,一般而言,一个用例就是一个控制类。实体类则是系统的核心,实体类良好设计能够提高系统的复用程度,减低系统的复杂性。

找实体名词

知道了有这三个类还是不足够我们识别具体的类,识别具体的类需要去业务流程,系统流程,系统规约中经常出现的名词。在上面的流程图中,订单,商城,设备,物流,用户是反复出现的名称,说明这些类必然存在。

 

 

找到这些业务实体,就是找到类的第一步。

找到属性

类的属性也不是凭空产生的,需要对业务实现有价值,用户不一定有姓名,在物流上下文中,用户的属性就只有 ID,收货地址。找到那些对于系统实现必不可少的属性,放到正确的类中。如仓配系统中的订单,包含订单号,商品,用户。用户则有收件地址。

 

 

在仓配系统中,用户只有一个地址,在商城的系统中,用户则有多个地址,充分说明了,不同的上下文中,类的属性不是固定的。

找职责

从业务规则和约束中,可以找到一些实体应当有的职责,如订单,就有验证合法性的职责。

 

 

有时候,有些对象看起来信息很富裕,但是却没有什么职责,说明他是一个值对象,像上图中的用户和收件地址,我们不关心他的 id,只关心收件地址,收件地址就代表着这个用户。

状态机

找到类和对应的职责,对于一些主要的实体类,还需要设计出他的状态机,清晰的状态机能有效地厘清系统内的一些事件和状态,增强系统整体的健壮性。

仓配中的订单,从用户购买的待发货状态,到通知物流发货,再到实际发货,物流签收有一些列状态的演变。

 

 

5 总结

在多人协作的项目中,不断提高项目质量,除了依靠代码之外的工程手段,还要依靠设计建模。

从具体实践的角度来看,设计建模在不同的环境中,调整具体的流程和侧重具体的节点,也能够实现快速高效,不会导致繁琐和低效能的现象。

在写代码之前应该做的几件事情:

找准涉众利益(越是新的项目,越是要分析好,如果是小功能的迭代,则可以从产品需求文档中寻找);

画出原来的业务流程图,和改进之后的业务流程图(业务流程图是对业务理解是有极大帮助,在绝大部分场景中都不应该省略);

分析系统的职责边界,画出系统用例(往系统中添加较小的功能可以考虑不画出来,心中有数即可);

写出具体的用例路径和约束(对系统安全和稳定越是关注,越应该去写出具体路径和约束);

识别主要的类,属性和职责,画出重要实体的状态机(简单功能则直接用代码来表达即可)。

 

责任编辑:武晓燕 来源: 腾讯技术工程
相关推荐

2011-06-30 15:06:19

SEO

2012-05-22 09:41:12

Python

2011-05-10 12:25:24

反向链接

2021-08-17 08:11:21

勒索软件攻击数据泄露

2015-08-19 14:09:46

Android手机切忌

2021-09-05 08:46:29

CSPM网络安全网络攻击

2016-04-11 11:24:55

Windows 10Linux注意事项

2013-01-15 11:44:10

VMware

2014-07-24 13:41:36

程序员

2020-06-04 13:52:00

CRM选型

2011-06-14 14:04:11

测试用例

2013-08-05 10:37:18

Aerohive802.11ac千兆WiFi

2012-05-30 09:24:52

存储虚拟化

2013-12-02 14:07:02

Hadoop大数据集群

2010-05-10 11:08:28

IPv6

2010-09-16 08:38:19

数据库索引

2009-12-08 19:39:16

PHP开发人员

2015-09-16 14:13:53

应用集成应用开发企业架构

2021-01-04 21:20:11

数据分析数据大数据

2020-09-30 10:25:38

IT工具技术
点赞
收藏

51CTO技术栈公众号