【前端工作提效】关于工作提效的一点实践与思考

• 1、测试提的BUG是一个一个提的，如果顺着测试提供的BUG单去一个一个解决问题，那么很容易管中窥豹，就像打补丁一样，缝缝补补，没有办法从根源去解决问题。所以我们需要尽量去了解代码的业务情况，并尽可能将一些场景覆盖查看一次。争取做到能够从根源上解决一个问题引起的多种现象。
• 2、开发需求前，要将需求仔仔细细的过一遍，尽量将需求逐一了解清楚，开发过程中遇到的一些疑惑或者有矛盾的点，及时找到相关人员进行沟通解决。
• 3、开发人员之间没有充分沟通，容易造成信息不同步，比如开发分支从dev切到test，再从test切到uat，再从uat至release线上分支，如果不同步，可能会造成代码管理提交混乱。并且会影响测试部署，因为如果分支不对，部署的就没办法看到修复的BUG，又进行了返工沟通。
  同样的，测试与开发的沟通也是有必要的，也会遇到类似的问题，来来回回的浪费了不少时间。
• 4、需要兼做开发以外的事情，比如，团队有2项任务，其中某一项提测，另外一项就必须开始看需求了，不能仅仅局限于解决提测的问题bug，这样子会让自己陷入被动，应该随时掌握主动权，了解需求的好处是：（1）可以相对准确的评估工时（2）可以把握住项目刚开始的黄金时期，驳回不合理的需求，避免后期扯皮和重做，节约开发时间（3）项管的日常任务就是分配任务和评估工时，以及项目进度管控和向上汇报，沟通协调资源，跨部门协同解决或者协商困难问题的归属等等。以上都需要我们主动承担起来，才能慢慢的走向这条路，
• 5、入职一家新公司后，应该把握住黄金的3天时间，将git、项目架构运行和业务、产品原型url、ui视觉稿url、说明文档wiki url、前端组件库核心库url、前端镜像源地址url、前端代码编写的eslint规范 & ts规范、汇集bug的平台url、集成一体化部署平台(CD)如jekins、开发的安全限制有哪些，必须将这些搞清楚。

未完，持续补充中…