这是一个创建于 1734 天前的主题，其中的信息可能已经有所发展或是发生改变。
lz 工作一年半以来，自我感觉可以说是尽自己所能的工作了。但是就像一句话说的：如果你的错误率是 10%，那么你做的越多，错的越多。
各种各样不同的错误方式，有的是因为漏调用了某个方法，有的是因为处事上出现问题：比如测试反馈了某个 bug，潜意识里就觉得是别人改的，定位问题后才发现是自己的问题，非常的尴尬。
考虑到自己工作了那么久，自己每天可能都得接个自己之前写的 bug，我回想了一下：我差不多有大半年的时间没有天天快乐的了，每天都是被这样的事情搞的烦心。
所以想请教 V 友们几个问题，现在真的非常迷茫：
- 1、你们有遇到过我这样的情况吗？你们是怎么处理的呢
- 2、到底怎么能降低因为粗心写出来的 bug ？我现在提交的代码基本是自审了 3 遍才合入的，但是偶尔还是会出现问题；
- 3、如果真是写的代码越多，bug 越多，那么你们又是怎么处理这关系的呢？
 |
1
lhx2008 2020-03-03 16:04:00 +08:00 via Android
单元测试，合理的面向对象编程，找同事 code review
|
 |
2
coderluan 2020-03-03 16:06:12 +08:00
1. 不处理。
2. 做不到。 3. 只看错误率和修正率结合起来看。谁单拿 bug 数来找我，我能怼的他怀疑人生。 |
 |
3
Jooooooooo 2020-03-03 16:08:11 +08:00
聚焦问题，逐个分析解决，不要尝试去解决那种虚无缥缈的问题
具体到你说的这个，漏调用方法。那是方案上就漏了还是代码漏写了，如果是方案上漏了，那方案的 review 怎么去改进呢？代码也是类似的。 测试反馈 bug，如果是自己的系统，就算是别人的改动，也可以多上心 |
 |
4
Goalonez 2020-03-03 16:24:28 +08:00
不断的改正犯下的错误,从而更接近你想要的完美状态,未尝不是一个有趣的过程.关键是尽量不要犯同样的错误.每一次处理都能意识到一些什么,那这个错误也是有意义的.
|
 |
5
lnsoso 2020-03-03 16:34:45 +08:00
我要说的是一种处理事情的方法论，把事情分开来说，有 Bug 不是问题，Bug 多也不是问题，但是 Bug 如果一直多，并且趋势没有随着工作时间收敛，这就是问题了，特别是以前出现的 Bug，以后尽量不要再出现。
1、总出错，可能是专注不够，或者说是不用心或者说是不过脑子。解决的办法就是先把遇到需求然后你响应的速度降下来，给自己留时间去用脑子想一想。也就是遇到需求先去动脑想架构和解决方案、流程、逻辑、潜在风险、所需物料，然后再 Coding。 2、磨刀不误砍材功，一些低级错误，比如手误之类是可以通过 IDE 和 Snippets 来解决。其它的比如沟通上有什么工具能加快双方对问一问题理解的效率，脑图？视频会议？ 3、把自己定位搞清楚，自己到底是聪明人还是笨一点的人（非贬义），如果 Bug 不可避免，是不是可以把提交的代码分成更小的片断多次提交，或者在性能和资源可以接受的情况下，采用一些防御性的编程方法，把一些条件判断写得更严格。 我遇到过你类似的情况，前提是我当时很“高产”，当时所在团队我的沟通能力还算好，和 QA 和 PM 沟通都比较顺畅，多一起吃午饭，一起抽烟（我并不会抽烟），来让大家了解 Bug 这么多确实非我本意，我也在努力解决，需要其它人帮忙。同时和组里更资深的老大哥人请教，自己业务时间也是看书和不断的对自己已经写完的代码去优化性能和逻辑，哪怕是已经通过 QA 测试并上线的。空余的时间都会来公司，当时的情况是部门助理统计部门加班时间，除公司安排加班外，我每均每月加班时间就大概在 120 小时左右（自愿加班，无加班费），后面大概几个月后的第二个项目就好了很多，Bug 数量大减。 |
 |
6
ayase252 2020-03-03 16:39:06 +08:00
自动化测试用起来。接到不熟悉的需求先完善之前的测试用例
|
 |
7
msg7086 2020-03-04 01:11:54 +08:00 via Android
测试验证开发。如果你们没有自动化测试的惯例那就别想了。有错是正常的，否则你们的测试小姐姐都要下岗了。
|
Select Language