高效能研发的四个习惯

110
文章首发于公众号 松花皮蛋的黑板报
作者就职于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深入的理解


不知道读者有没有下面的这些体验。

案例一: 产品需求预评审、正式评审时,一些看似简单的需求,我们习惯简单思考后就答复,实现是没问题的,保证能按时按质完成任务,然而在开发过程或者测试过程还会拉上产品沟通困惑点,甚至验收时无法达到一致。

案件二: 和服务使用方联调时,别人觉得你的参数不合理,或者对他来说过于麻烦,最后不得不再去修改代码、发布、自测。

案例三: 测试同事和你对功能影响存在信息偏差,测试通过但是上线后其他功能受到牵连。

案例四: 你新接手一个项目, 但是时间很快被新需求给占用了,对旧功能实现和演进过程了解甚微,最后自己一边制造雷区一边掉进前人的坑。

上面提及的四个案例,都是我们日常工作中容易遇到的问题,这些问题会造成不必要的时间消耗。那我们在日常开发中需要注意哪些点,才能避免类似问题,成为一个高效能的研发呢?今天我将分享一些知识和经验,希望能帮助到你。

第一点,接到需求任务时,需要注意什么呢?

你可能首先想到的是技术方案调研或者确定技术方案,不过直觉多数是错的。当接到需求任务时,我们应该先定好验收标准,包括正常的和异常的流程,避免对”需求完成”的定义产生分歧。如果对描述有异议,尽早和各方充分沟通,达成一致,然后让产品更新PRD,并且将信息及时同步给所有需求任务参与者。也就是说,不管产品修改的只是关于前端的还是只关于后端的,都应该全量同步,而不是只通知一方,避免修改了逻辑之后只有一方知道。

第二点,编写一个对外服务前,需要注意什么呢?

编写对外服务时是先写文档还是先开发再写文档呢?我之前提了一个需求给别人,要求触发某个逻辑时,发送一个消息MQ给我,消息体需要包括业务信息。联调时,我无法对消息体进行正常的反序列化,因为包括了编程语言中的关键字,但是他们编写使用的是其他编程语言,对他们来说,那根本不算关键字。说到这,前面的问题答案已经很明显了。开发对外服务时,我们要先定义好接口(服务)文档,并且要求使用方对接口(服务)文档进行确认,达成一致再进行开发,避免联调时造成字段缺失或者字段名不合适问题。

刚说到的接口文档也是有规范可言的,通常包括功能说明、使用场景说明、协议规范、请求规范、响应规范、服务字段描述、响应字段描述、示例,通常还会包括文档的编写维护人、产品人员信息、测试人员信息,方便其他人反馈或者提需,甚至还会包括脱敏后的业务背景、业务规则说明、调用方信息。消息MQ规范其实和接口规范相似,不过需要注意提醒使用方做好兼容性测试,同时确保后续新增字段不受影响。

第三点,功能迭代或者缺陷修复时,需要注意什么呢?

大部分情况下,你为什么要修改这个功能、修改的逻辑是什么、需要注意什么地方,只有你清楚而已。换一个人来修改其周边逻辑,他得花时间确定修改影响范围,同时你碰到的坑,他可能还会陷进去一次。前者有可能是注释没写好,后者有可能是没有将过程数据化。

针对前者,我们写好注释就行。但是,总有人在注释中长篇大论,描述这个功能是怎么实现的,而不是描述做什么的。最后,功能确确实实在迭代,文字注释却原地不动,注释成了撒谎机,成了误导性的文字。业内有个经典名言,最好的注释是没有注释,用代码表达意图。要达到这点,必须保证每一次修改,代码都比之前更干净。换言之,好读、好懂、好改的高质量代码才能促进生产力。

针对后者,我们可以使用代码仓库GIT中的ISSUE管理功能迭代和缺陷管理,然后及时更新状态,同时描述解决过程的思路、尝试过的解决方案等等。这种方式能促进团队透明,方便事后回顾总结。还能让我们通过数据来衡量效率,跟踪进度,也能方便其他人了解功能实现和演进过程。

第四点,需求提测时,需要注意什么呢?

测试同事和你对需求的理解肯定是有偏差的,这也是为什么人们慢慢开始接受测试驱动开发理念,不过距离落地还有一定距离。我比较推荐的做法是,开发前编写好涉及到的场景步骤、直观结果、影响范围,并且将其同步给测试人员,作为提测模板,当功能完成后补充信息提测即可。这样做的好处,一来是能提前校验大家对需求的理解是否是一致的,二来是避免修改非本次需求而是其他人想顺便修改的逻辑,我们内部称之为接私活,这是绝对禁止的。

总结一下今天的重点,想清楚、对齐清楚再做,做的过程多记录,往往不会有坏处,毕竟磨刀不误砍柴功。好,今天的分享就到这里,如果有帮助到你,欢迎分享给你的朋友们或者点击在看。

文章来源:www.liangsonghua.me

作者介绍:京东资深工程师-梁松华,在稳定性保障、敏捷开发、JAVA高级、微服务架构方面有深入的理解