一、开发日常
1. 接收到新需求后一定要仔细研读需求文档，先有个大概构思；将功能点划分，拆分成小块；
2. 自己没做过的功能一定要先去学习，调研，尽可能早的暴露问题，千万不要等到最后实现到一半发现有无法解决的坑，那这样往往坑的是自己；
3.尽可能多跟后端交流沟通，有些自己比较难处理的数据可以交给后端大佬们，前端主要集中于页面的渲染，交互，不做过多的数据处理；
4. 多站在测试的思维角度去考虑自己代码要涵盖的场景，这样你会发现自己所写的代码有不少的bug；
5. 有些需求可能产品老师异想天开，但是前端小伙伴可以梳理功能逻辑，提出更好的方案，使系统更易于维护更新，而不是完全按照文档实现，最后甩锅文档就是这样写的。
6. 再小的功能也要新建一个分支，再着急的Fix 也先在自己的分支修改测试再发到测试环境，千万不要直接修改gitlab上的代码或者直接修改测试分支代码，这样很容易造成不一致，测试小伙伴测试没问题，一上线就有问题；
7. 自己解决的bug一定要多积累，弄清楚why？原理, 可以给自己的前端工作来一个小纠错本本，积累的多了也就变成大牛了， 下次就不会写这样的bug；
8. 千万不要试图给测试小伙伴讲原理，他们听不懂，简洁有效的沟通方式：我改！ 不需要我改！ 把问题责任人告诉ta，或者bug指给责任人，也不要告诉开发这不是个bug，可以跟产品老师一起探讨，让产品老师决定要不要修改；
9. 没事真的多看别人写的代码，俗话说三个臭皮匠顶个诸葛亮，看别人的代码你会学到很多，取其精华去其糟粕，看不懂的地方一定要认认真真的啃下来，一旦你啃明白了这块硬骨头你会学到更多的东西，一旦你放弃了，你学到的就只有你已经知道的那部分；
10. 用例评审一定要仔细听，有些case在测试前你就发现是bug，悄无声息的修复，有些case可能本身就有争议，这个时候最好提出来，让测试小伙伴也明白，省的你代码没撸多少，系统缺陷提了一堆，影响最后的KPI；
11. 不要图安逸，勇敢的去做自己没做过的工作，你会发现这样比你天天做一样的工作更有趣，如果你完成了会有成就感，并且在解决问题的过程中也会学到很多，那比你看多少文章，看多少本书都有意义；总之一句话，新项目勇于去参与，新技术勇于去挑战！
12. 有问题尽量自己去百度，去技术群，去技术吧寻求解决方法，不要过多的打扰身边同事，更不要大小问题都请教身边同事，不耻下问已经过时了，问同事太多他们会觉得你技术不行，慢慢的会失去敬畏，会让你失去很多机会，领导对你的印象也会不好，解决问题的能力就是你的技术；
13. 工作日报一定要写的详细，多积累自己的专业术语和词汇，光会撸代码不行呀，你要学会写工作日报，这是你工作的体现；大佬们写的文章技术可以学不会，但专业词汇一定要学习积累，有百利无一害！
加油！今天就到这这里，写的有点累，哪天接着补充
