2021-7月第三周:开发流程规范,人力安排,技术目标制定

2021-7月第三周:开发流程规范,人力安排,技术目标制定

Tags
前端
工作心得
Published
August 8, 2021
Author
LIAOKUN
台风天正好窝在家里写一下本周的总结。上半年的PBC考核结束之后大部分时候还是投入在业务需求中,虽然是日常工作还是有三点值得回顾一下。

开发流程规范

本周开发过程中出现了一个比较严重的问题:我把用于debug的代码合并到master并发布到了线上。 所幸这段代码仅仅是向浏览器的window对象下新增一个属性用于记录debug信息,并不会影响到前端的业务流程。正如上一篇文章说的
在没有刻意去做风险控制之前没出事故确实只能说运气好没踩到雷
除非职业生涯能一直狗屎运爆发,否则总是会因为忽视了风险控制造成重大问题。回顾一下这次问题的经过:
  1. 在测试环境完成需求功能测试,完成code ewview之后开发流程走到预发环境
  1. 预发环境页面出现白屏,和测试环境表现不一致
  1. 后端没有做更改,前端(我)非常确认问题是出在服务端(Node侧或JAVA侧)
  1. 落地页的服务端渲染(Node工程)没有记录错误日志,JAVA后端否认问题出在JAVA侧,查看JAVA工程的错误日志也看不到相应的报错
  1. 无奈只好修改Node端的渲染逻辑,将Node端产生的debug信息输出到客户端查看
  1. 增加debug代码之后JAVA后端发来消息说是一个JAVA的工程没有发布到预发环境,发布完之后白屏问题解决
  1. 前端工程产生了若干个用于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重点是风险控制,具体为下半年无技术侧的资损。 具体到我负责的工程里,目前整理了三点出来:
  1. 风险控制:增加落地页服务端渲染的错误日志和监控
  1. 性能优化:落地页增加服务端的DOM构建
  1. 团队基建:落地页工程引入vite提升开发时的编译速度,整个工程的打包速度优化