标签：代码 业务 研发 做好 涉及 认真负责 监控 做到 提前

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

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

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

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

开发前做好需求评估

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

• 解决了什么问题？

• 提升了什么指标？

• 有什么商业价值？

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

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

提测前做好冒烟测试

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

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

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

上线前做好回滚预案

提前做好上线准备：

• 考虑代码合并是否有冲突，如果有冲突提前做好合并工作。

• 如果涉及到 SQL，提前整理出涉及到的 SQL 语句，不要临时上线出现漏掉的情况，同时还要考虑历史数据是否需要修复。

• 如果涉及到后台管理系统，提前配置好 RBAC 的权限。

• 如果涉及到定时脚本，提前配置好 Job 的执行任务。

• 如果涉及到配置，提前做好准备。

提前做好回滚预案：

• 根据各自的发布系统，提前做好回滚方案，涉及到多端的提前沟通好。

• 如果涉及到改动比较大，必须使用灰度发布，先用小部分流量测试，慢慢再开放全量。

上线后密切观察指标

日志监控：

• 容器性能监控，查看内存、CPU 曲线是否正常；

• 调用次数、响应时长及 HTTP 状态码监控；

• 异常业务状态码告警时，需要输出堆栈信息；

• 对外提供的接口，记录响应时间、入参、出参，需考虑敏感数据脱敏；

• 调用第三方服务，记录响应时间、入参、出参；

数据监控：

• 新增用户数监控；

• 发送短信数监控；

• 使用优惠券订单数监控；

• 退款订单数监控；

• 未支付订单数监控；

• ... 等等

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

业务群反馈

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

加分项

• 需求的分析能力，对产品的了解和掌握；

• 行业知识背景，对行业市场的技术方案把握；

• 技术框架的熟悉、设计能力；

• 努力抽象出跨项目可用的代码库。

• 及时汇报；

小结

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

标签：代码,业务,研发,做好,涉及,认真负责,监控,做到,提前
来源： https://blog.51cto.com/u_15183360/2737260

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。