hellogithub.com
获得徽章 0
- Morning! 今天推荐一个项目：vscode-leetcode。它可以让你在 VS Code 中练习全球极客挚爱的技术成长平台— LeetCode 上的各种习题，你可以在上面查看高票解答、提交答案、测试答案等，大大提高了刷题效率，更重要的是它可以作为你【上班摸鱼】的神器，帮助你节约时间，助你跳槽一臂之力！一般人我可不告诉他，sei叫咱们关系好呢？喜迎周四！再提周五！上班快乐~
hellogithub.com 展开17125 - 关于修 bug 的一点想法：
1. 如果你面对的是多个测试，反馈来的问题往往有可能是重复的。很多人拿到 buglist 之后就马上挨个修，其实正确的姿势应该是先把这些 bug 进行分类，比如归类到某个页面，或者是某个 service。这个过程也是你理清思路，保持冷静的一步；
2. 分类完之后按类别进行修复，然后最重要的一点来了：修复完之后把这个部分的 test case 过一遍！很多人都是修完一个 bug 之后就验证下这个 bug 是不是没了就不管了，最后往往导致这个 bug 修完了，又搞出来其他 bug；
3. 给 bug 分类的时候一定要识别出 bug 的优先级，一般来说，阻断性的 bug（导致主流程不通的 bug）一定是要马上修复并提供新包给测试的，因为等你把所有 bug 修完再给测试打包可能往往已经是半天之后了，测试呢，卡在这个地方，半天时间什么也干不了，极其浪费时间；
4. 多和测试沟通。如果阻断性 bug 修复的时间比较长，一定要提前告知测试，并给一个预期的完成时间点给他，很多人可能会沉浸在修复 bug 这件事件中，觉得最重要的事情就是把手里的 bug 修完，但是换位思考下，你在修 bug 的时候测试对你的情况一无所知，测试这个时候是什么感受？（如果条件允许建议坐到测试旁边修 bug，相信我，无比丝滑）
5. 注意：并不是所有的 bug 都是可以“修”好的！适当时候你要砸碎重来！比如某个方案设计的时候存在比较大的缺陷，导致最后加再多的 if-else 也修不好，那就要考虑重新理清思路，重写，虽然看上去会花费时间比较多，但是从反反复复修 bug 这个角度来说，绝对值得！
6. 最后一点：测试就是上帝！好好跪舔！展开828
