高效能研发的四个习惯
文章首发于公众号松花皮蛋的黑板报
不知道读者有没有下面的这些体验。
案例一: 产品需求预评审、正式评审时，一些看似简单的需求，我们习惯简单思考后就答复，实现是没问题的，保证能按时按质完成任务，然而在开发过程或者测试过程还会拉上产品沟通困惑点，甚至验收时无法达到一致。
案件二： 和服务使用方联调时，别人觉得你的参数不合理，或者对他来说过于麻烦，最后不得不再去修改代码、发布、自测。
案例三： 测试同事和你对功能影响存在信息偏差，测试通过但是上线后其他功能受到牵连。
案例四： 你新接手一个项目， 但是时间很快被新需求给占用了，对旧功能实现和演进过程了解甚微，最后自己一边制造雷区一边掉进前人的坑。
上面提及的四个案例，都是我们日常工作中容易遇到的问题，这些问题会造成不必要的时间消耗。那我们在日常开发中需要注意哪些点，才能避免类似问题，成为一个高效能的研发呢？今天我将分享一些知识和经验，希望能帮助到你。
第一点，接到需求任务时，需要注意什么呢？
你可能首先想到的是技术方案调研或者确定技术方案，不过直觉多数是错的。当接到需求任务时，我们应该先定好验收标准，包括正常的和异常的流程，避免对”需求完成”的定义产生分歧。如果对描述有异议，尽早和各方充分沟通，达成一致，然后让产品更新PRD，并且将信息及时同步给所有需求任务参与者。也就是说，不管产品修改的只是关于前端的还是只关于后端的，都应该全量同步，而不是只通知一方，避免修改了逻辑之后只有一方知道。
第二点，编写一个对外服务前，需要注意什么呢？
编写对外服务时是先写文档还是先开发再写文档呢？我之前提了一个需求给别人，要求触发某个逻辑时，发送一个消息MQ给我，消息体需要包括业务信息。联调时，我无法对消息体进行正常的反序列化，因为包括了编程语言中的关键字，但是他们编写使用的是其他编程语言，对他们来说，那根本不算关键字。说到这，前面的问题答案已经很明显了。开发对外服务时，我们要先定义好接口(服务)文档，并且要求使用方对接口(服务)文档进行确认，达成一致再进行开发，避免联调时造成字段缺失或者字段名不合适问题。
刚说到的接口文档也是有规范可言的，通常包括功能说明、使用场景说明、协议规范、请求规范、响应规范、服务字段描述、响应字段描述、示例，通常还会包括文档的编写维护人、产品人员信息、测试人员信息，方便其他人反馈或者提需，甚至还会包括脱敏后的业务背景、业务规则说明、调用方信息。消息MQ规范其实和接口规范相似，不过需要注意提醒使用方做好兼容性测试，同时确保后续新增字段不受影响。
第三点，功能迭代或者缺陷修复时，需要注意什么呢？
大部分情况下，你为什么要修改这个功能、修改的逻辑是什么、需要注意什么地方，只有你清楚而已。换一个人来修改其周边逻辑，他得花时间确定修改影响范围，同时你碰到的坑，他可能还会陷进去一次。前者有可能是注释没写好，后者有可能是没有将过程数据化。
针对前者，我们写好注释就行。但是，总有人在注释中长篇大论，描述这个功能是怎么实现的，而不是描述做什么的。最后，功能确确实实在迭代，文字注释却原地不动，注释成了撒谎机，成了误导性的文字。业内有个经典名言，最好的注释是没有注释，用代码表达意图。要达到这点，必须保证每一次修改，代码都比之前更干净。换言之，好读、好懂、好改的高质量代码才能促进生产力。
针对后者，我们可以使用代码仓库GIT中的ISSUE管理功能迭代和缺陷管理，然后及时更新状态，同时描述解决过程的思路、尝试过的解决方案等等。这种方式能促进团队透明，方便事后回顾总结。还能让我们通过数据来衡量效率，跟踪进度，也能方便其他人了解功能实现和演进过程。
第四点，需求提测时，需要注意什么呢？
测试同事和你对需求的理解肯定是有偏差的，这也是为什么人们慢慢开始接受测试驱动开发理念，不过距离落地还有一定距离。我比较推荐的做法是，开发前编写好涉及到的场景步骤、直观结果、影响范围，并且将其同步给测试人员，作为提测模板，当功能完成后补充信息提测即可。这样做的好处，一来是能提前校验大家对需求的理解是否是一致的，二来是避免修改非本次需求而是其他人想顺便修改的逻辑，我们内部称之为接私活，这是绝对禁止的。
总结一下今天的重点，想清楚、对齐清楚再做，做的过程多记录，往往不会有坏处，毕竟磨刀不误砍柴功。好，今天的分享就到这里，如果有帮助到你，欢迎分享给你的朋友们或者点击在看。
