台风天正好窝在家里写一下本周的总结。上半年的PBC考核结束之后大部分时候还是投入在业务需求中,虽然是日常工作还是有三点值得回顾一下。
开发流程规范
本周开发过程中出现了一个比较严重的问题:我把用于debug的代码合并到master并发布到了线上。
所幸这段代码仅仅是向浏览器的window对象下新增一个属性用于记录debug信息,并不会影响到前端的业务流程。正如上一篇文章说的
在没有刻意去做风险控制之前没出事故确实只能说运气好没踩到雷
除非职业生涯能一直狗屎运爆发,否则总是会因为忽视了风险控制造成重大问题。回顾一下这次问题的经过:
- 在测试环境完成需求功能测试,完成code ewview之后开发流程走到预发环境
- 预发环境页面出现白屏,和测试环境表现不一致
- 后端没有做更改,前端(我)非常确认问题是出在服务端(Node侧或JAVA侧)
- 落地页的服务端渲染(Node工程)没有记录错误日志,JAVA后端否认问题出在JAVA侧,查看JAVA工程的错误日志也看不到相应的报错
- 无奈只好修改Node端的渲染逻辑,将Node端产生的debug信息输出到客户端查看
- 增加debug代码之后JAVA后端发来消息说是一个JAVA的工程没有发布到预发环境,发布完之后白屏问题解决
- 前端工程产生了若干个用于debug的commit,此时可以有多个操作
- 本地删除debug代码生成一个新的commit推送上去
- revert之前若干个用于debug的commit
- reset --hard到debug之前的commit节点然后push -f
那我当然选择reset哈哈哈哈,虽然
reset --hard + push -f
是个非常高危的操作,但因为有流水线帮助控制研发流程,自己也确认过分支上没有别人的提交记录所以放心做了这个操作。
都这么小心翼翼了问题当然没出现在这里 🤣
问题出在提交debug的commit并不是连续的,在我执行reset的节点之前还有两个用于debug的commit没有被reset掉
而我也预判到了这点,害怕带了额外的代码到master上。所以还专门提了feature分支到master的merge request来看一下分支上的改动点
这恰恰就是老马失前蹄的地方了啊!因为这些改动点已经和不同的同事review了太多次,自己再看的时候就没太仔细看,选择性忽视了新增的调试代码,导致这些代码被发布到了生产。
所幸对用户是没感知的代码,下周发布日悄咪咪发布上去就当什么事都没发生过。但这也给我敲响了警钟,对于上过预发之后又产生的改动一定要逐行检查改动点,避免携带需求以外的代码改动。人力安排
本周跟着领导做人力安排,按照需求池整理了两个表格。一个是以需求作为维度建立的:
需求编号/需求名 | 归属工程 | 需求规模 |
另一个是以人力作为维度建立的:
人力 | 进行中需求 | 待排期需求 | 空余人力 | 下周需求 |
小组里一般是固定的人员负责固定的工程,通过两个表格就可以快速把需求归属到相应的人力上。
技术目标制定
上半年PBC考核结束,下半年的PBC制定也要进入日程了。按照上一篇文章归纳的,围绕
- 问题排查:解决已经出现的疑难杂症
- 风险控制:避免可能出现的线上问题
- 性能优化:提供更优质的代码和更好的页面体验
- 团队基建:提升团队的开发效率
- 业务支撑:从技术侧推动业务的进行
5方面进行技术目标的制定。从领导那边传下来的PBC重点是风险控制,具体为下半年无技术侧的资损。
具体到我负责的工程里,目前整理了三点出来:
- 风险控制:增加落地页服务端渲染的错误日志和监控
- 性能优化:落地页增加服务端的DOM构建
- 团队基建:落地页工程引入vite提升开发时的编译速度,整个工程的打包速度优化