高效能研发的四个习惯

文章首发于公众号 松花皮蛋的黑板报

做者就任于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深刻的理解

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

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

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

案例三： 测试同事和你对功能影响存在信息误差，测试经过可是上线后其余功能受到牵连。

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

上面说起的四个案例，都是咱们平常工做中容易遇到的问题，这些问题会形成没必要要的时间消耗。那咱们在平常开发中须要注意哪些点，才能避免相似问题，成为一个高效能的研发呢？今天我将分享一些知识和经验，但愿能帮助到你。

第一点，接到需求任务时，须要注意什么呢？

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

第二点，编写一个对外服务前，须要注意什么呢？

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

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

第三点，功能迭代或者缺陷修复时，须要注意什么呢？

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

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

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

第四点，需求提测时，须要注意什么呢？

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

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

文章来源：www.liangsonghua.me

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