做业务系统研发如何做到认真负责？

相信大家都有这样的问题，天天写业务代码的程序员，怎么成为技术大牛？下面给大家分享下我对这个问题的看法，仅代表个人看法，比较粗浅，希望大家不要介意。

程序员大部分在做这两种事情，一是通过技术支持业务部门，二是通过技术支持技术部门，我们大部分做的是前者，因为前者的岗位比较多，例如几百人的技术部门，基础平台组也就 20 人左右，还有大部分公司的盈利还是靠业务，所以支持业务部门的程序员非常重要。

业务代码整天做的并不全是对数据库的 CRUD ，它是搭建在各种业务基础框架代码之上的，其实业务的基础框架并没有足够完美到让我们纯粹只做 CRUD 之类的工作，还是有很多需要完善的地方，这都是写业务代码需要考虑的。

接下来基于研发流程角度，分享程序员在业务系统开发中如何做到认真负责。

开发前做好需求评估

需求评估会上，一定要弄清楚这 3 个问题：

• 解决了什么问题？
• 提升了什么指标？
• 有什么商业价值？

需求评估后再进行开发内部技术评审，涉及到 数据库设计、接口设计、第三方接口交互等，同时还要考虑代码的封装性、可维护性、可扩展性等。

开发人员也尽量提供一份功能改动点的文档出来，说清楚改动了哪些点，哪些重要的点被改动了，让测试人员做好评估。

提测前做好冒烟测试

与测试人员过冒烟测试用例时一定要拉上产品经理，主要是为了保证新功能完整性，旧功能回归场景是否全，有无漏掉的场景等。

开发人员需积极主动地推动联调工作，同时对涉及到的主流程进行自测，保证主流程没问题，便于测试人员的工作顺利开展。

如果涉及到 C 端用户的接口，需要对接口进行压测，通过压测发现瓶颈所在，提早优化。

上线前做好回滚预案

提前做好上线准备：

• 考虑代码合并是否有冲突，如果有冲突提前做好合并工作。
• 如果涉及到 SQL，提前整理出涉及到的 SQL 语句，不要临时上线出现漏掉的情况，同时还要考虑历史数据是否需要修复。
• 如果涉及到后台管理系统，提前配置好 RBAC 的权限。
• 如果涉及到定时脚本，提前配置好 Job 的执行任务。
• 如果涉及到配置，提前做好准备。

提前做好回滚预案：

• 根据各自的发布系统，提前做好回滚方案，涉及到多端的提前沟通好。
• 如果涉及到改动比较大，必须使用灰度发布，先用小部分流量测试，慢慢再开放全量。

上线后密切观察指标

日志监控：

• 容器性能监控，查看内存、CPU 曲线是否正常；
• 调用次数、响应时长及 HTTP 状态码监控；
• 异常业务状态码告警时，需要输出堆栈信息；
• 对外提供的接口，记录响应时间、入参、出参，需考虑敏感数据脱敏；
• 调用第三方服务，记录响应时间、入参、出参；

数据监控：

• 新增用户数监控；
• 发送短信数监控；
• 使用优惠券订单数监控；
• 退款订单数监控；
• 未支付订单数监控；
• ... 等等

上线后需要密切关注以上指标，查看有无超预期情况、接口超时情况、接口错误日志等。

业务群反馈

如果上线后，产品/业务在群里反馈一些异常数据，需要排查的，不要每次都通过代码去定位，要考虑做成小工具让产品/业务自己使用，不要每次都反馈到研发处理。

加分项

• 需求的分析能力，对产品的了解和掌握；
• 行业知识背景，对行业市场的技术方案把握；
• 技术框架的熟悉、设计能力；
• 努力抽象出跨项目可用的代码库。
• 及时汇报；

小结

业务是饭碗，业务做不好，其他什么都别谈，业务才是解决用户问题的核心。