本周工作思考
线上bug修复的思考
1 线上问题经过漏斗处理，到研发这边的一般被确认为是需要代码修改或者需要开发人员分析排查的；所以到了开发侧的bug上，虽然被定级为P0，P1，P2，P3， 本质上讲都是比较严重的线上问题，因为都影响到了用户使用，损害客户既得利益和公司的商誉，进而影响续购率和订单率等公司经营核心指标；
2 截止到23年3月前端的线上问题数量上较多，最近半年的Bug总数如下，
月份
22-10
22-11
22-12
23-01
23-02
23-03（截止26日）
web端bug数
78
84
52
67
124
89
总数据上看，bug反馈数与单月用户工作天数成正比，也和用户使用频度成正比；
累计平均每人每月人的bug数是11.76，换句话说，Web组平均每人每月在完成项目交付的同时，也交付了12个线上bug，这么评价很扎心，但是作为Web负责人我不得不面对这样的惨痛的事实，而且还不是一蹴而就就能解决的，这个事实也不断在我的脑海里酝酿盘桓，也是我们Web组的心头大患：我们要如何系统性的根除这个大问题
3 按照 bug原因给这些bug分类，我们大概能分出20个左右的分类，包括，逻辑判断错误，逻辑实现不严谨，样式误用，样式被覆盖，功能补全等等，这也从侧面说明Web前端的现阶段工作面临的复杂性和挑战性，要兼顾的因素较多，功能的实现也是要考虑周全，这也从侧面说明为什么我们十分重视人才和团队的建设。我们追求C端的极致的用户体验，也必须追求B端的高附加的业务价值，这个要求不是我们给自己定的，这个要求是市场给我们的定，我们不这么做，我们就会死掉，就这么简单。
4 根据web前端22年，23年的路线图，质量部分的相应的规划和目标，也根据公司和团队的优先级灵活安排，也逐步有了一些落地效果和改善，虽然距离我们远景目标还差很远，不积跬步何以至千里，跬步已行，何忧不至千里呢； 在质量方向，未来2年内我们会坚定的有步骤有计划的推进以下四件事：
(1)搭建开发质量评估和优化体系
(2)完善并利用好前端可用的监控体系
(3)建议基于重点项目的质量跟踪及改进体系
(4)持续提升团队整体的技术水平和业务水平
5 近半年以来，在Web组伙伴们的共同努力下
(1) 我们逐渐开始建设bug分配流转等流程机制，逐渐提高bug的单月修复率， 季度修复率，单月达成85%的修复率的目标的月份也在不断增加，增加疑难问题Review，针对疑难的bug，定期和有关伙伴做专项的Review，加速技术性解决和方案性解决，尽量给客户以及时的反馈
(2) 不断完善bug统计机制，尝试从多维度去理解和分析bug产生的根本原因，推动对消除bug有影响的工程化和研发流程的完善
(3)尝试使用多种监控，提前发现功能bug和线上bug
(4)有意识的建立bug修复流程的Master doc，在排期，项目并行安排，提测代码合并，业务学习等方面做一些梳理和明确
6 未来六个月，我们专项系统性的解决线上bug问题，从开发理念，代码编写，工程化角度等以渐进的方式逐步做一些改进和提升，
（1）继续坚持执行和完善之前形成的最佳实践，
（2）执行技术路线图的规划，往深里走，往细处看，重点关注开发质量评估和优化体系的建设，特别是代码质量提升和bug原因分析；
以逐步解决以下我们的问题：
1 客户直接反馈的多
2 提前发现的少
3 内部发现的少
4 客户反馈问题的修复闭环不完善
5 bug溯源和分析粗浅，bug修复后没有明确的改进措施
6 重复性问题较多
7 部分系统问题没有及时的根本性解决
8 修复线上bug的研发侧附加收益不大
9 bug解决指南和流程不完善
10 解决紧急问题的流程不完善
11 线上问题修复及时性不高