台风天正好窝在家里写一下本周的总结。上半年的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提升开发时的编译速度，整个工程的打包速度优化