这是一个创建于 2016 天前的主题，其中的信息可能已经有所发展或是发生改变。
入新公司一年了吗，出过好几次 bug，都是低级问题导致一些功能受影响，几乎都被老大知道了，还有好几次是老大发现的，老大一般没说啥，但能感受到他很失望，我也感觉很操蛋，感觉不应该啊，想请教下大家，五年猿不论技术掌握，开发 bug 率是多少，如何提升质量呢
第 1 条附言 · 2019-05-16 23:37:18 +08:00
谢谢各位的批评指正，结合大家说的和我的实际情况总结了一下
1. 良好的编码习惯，复制粘贴的时候尤其注意
2. 良好的测试习惯，不侥幸
3. 掌握更丰富的测试工具和方法，目前只会 junit 一遍撸
4. 需求控制和分析能力，不能轻易接私活，预先分析好受影响点和坑，开发的时候避免天马行空
5. 即使上线了，也要作数据观察
1. 良好的编码习惯，复制粘贴的时候尤其注意
2. 良好的测试习惯，不侥幸
3. 掌握更丰富的测试工具和方法，目前只会 junit 一遍撸
4. 需求控制和分析能力，不能轻易接私活，预先分析好受影响点和坑，开发的时候避免天马行空
5. 即使上线了，也要作数据观察
 |
1
ranwu 2019-05-16 21:10:03 +08:00  2
单元测试，功能测试，集成测试走起
|
 |
2
Vegetable 2019-05-16 21:14:00 +08:00 2
估计低级 bug 出现的概率无限接近于 0 吧，还没到五年，但是现在已经基本不会出了。
方法就是拿出一半时间写单元测试。 |
 |
3
billlee 2019-05-16 21:54:08 +08:00
1. 用强类型的语言
2. 写单元测试 3. 上 lint |
 |
4
smdbh 2019-05-16 22:06:35 +08:00 via iPhone
什么类型的，贴来看看
|
 |
6
mcfog 2019-05-16 22:07:57 +08:00 2
你知道怎么避免的才能说是低级 bug
那么你知道怎么避免吗？知道还重复出，那是态度问题，端正态度先 如果你不知道怎么避免，那这个 bug 对你来说就不低级，学会怎么避免，你的能力就有提升了，你可以等一个段落以后去请教老大怎么避免，或者是这里或别的地方提问，记得提问的智慧，也可以去补相关的基础也好理论也好，方法论也好（如果你知道什么是相关的，应该补的东西） |
 |
7
ArthurRen 2019-05-16 22:08:51 +08:00 via Android
没有测试人员吗
|
 |
8
season8 OP @smdbh 第一次是导数据，创建时间没强制赋值被刷成了 now, 第二次是取错证字段，修改很小，测试特别麻烦，我就直接发了线上了😰
|
 |
9
liprais 2019-05-16 22:56:37 +08:00 2
写完不测就发布
我是你 leader 这次你就吃不了兜着走了 你 leader 真是个好人 |
 |
10
wc951 2019-05-16 23:02:36 +08:00 via Android
这是你们流程有问题
|
 |
11
tomlee0201 2019-05-16 23:11:08 +08:00 1
写代码之前先要考虑好各种异常情况，写完代码要自测，然后找人 review，上线再有 QA 做上线测试
都五年了，还没有养成一个正确的开发习惯。。。 |
|
12
season8 OP @mcfog 首先感谢你的点拨，我也说不上来，感觉每天上班状态不太好，之前出过一次 bug，其实是前人的锅，但我也犯了，我都不知道怎么反驳，后来有一次给产品做一个小工具统计数据，本来是说每周要的，但她用来弄历史数据，各种不对，老是找我，还说我坑她，但我当时没意识到我本来就没给他提供这个功能。。。我也是够昏，刚好老大听到了，说我这不行，下班路过我旁边还调侃我写 bug。。感觉真心无力解释，像狡辩一样。然后另外一个领导总说 kpi，裁员。。感觉压力好大，
我的却不太喜欢测试，但大部分我都测试了，先本地，再测试，再线上，但我没有定期观察数据的习惯，如果有的话，这些问题都能及早发现而不是被领导发现。其他的，感觉还是代码量少了，我觉得这么多年应该有的基本逻辑是不用测试也没大毛病的那种程度。。。 还有一个，复制粘贴的时候总是容易漏改注释，有时打断一下还会漏改代码，这个怎么破 |
 |
13
kuber 2019-05-16 23:13:55 +08:00 1
@season8 写完代码不（好好）测试就提交，这不是技术问题，是责任心问题。我要是你 leader 肯定要开骂了。
要养成习惯，写代码前想一下怎么测试。不管是单元测试还是手工测试，先想清楚有哪些分支需要测试，怎么测试，才能说你清楚了需求，然后才能写出合格的代码。 |
 |
14
zhuawadao 2019-05-16 23:14:36 +08:00 1
@season8 对于我个人，一般有的地方，隐隐约约感觉可能没问题吧，或者是这个地方好像有不清晰的地方，但又说不出来哪个地方。以上的情况，基本到后来都会出现问题。所以我就格外注意
|
|
15
season8 OP @tomlee0201 谢谢指正，我也发现我开发习惯很不好。你说的提前考虑好各种异常，这个确实很重要，总是开发过程中冒出各种念头🙉，有时候会很影响效率，我有时候总觉得自己想太多
|
 |
16
feiyuanqiu 2019-05-16 23:18:16 +08:00 via Android 1
低级问题靠语言、靠好的 IDE、靠经验来减少犯错的几率，但最主要还是要靠认真的态度，不说单元测试，至少写完了要自己跑几遍，单步调试走完所有逻辑，不忽略任何预期外的情况。
要尽可能把自己负责的业务相关都摸清，不懂或不清晰的一定要搞清楚再动手。我最近一次事故，第三方提供了一个有副作用的接口，文档上就一行字模模糊糊说了一下，也没仔细读，对于接口参数里有个看起来跟上下文没什么关系的参数也没多想…结果上周修复数据修到吐血 |
|
18
feiyuanqiu 2019-05-16 23:28:52 +08:00 via Android 1
@season8 复制粘贴是种 bad smell，在提醒你该抽象提炼代码逻辑了
|
|
19
season8 OP @feiyuanqiu 是哈，😱，野猿
|
 |
20
ChristopherWu 2019-05-17 00:25:44 +08:00
首先，你应该整理一下你犯过的错，分析一下原因，贴上来，我们才知道你出了什么错。
|
 |
21
persistz 2019-05-17 00:28:33 +08:00 via Android 1
这种逻辑错误用全自动手段避免不了的
目前只能自己想办法设计好用例了 搞个弱一点的 tdd 写代码前先把单元测试想好 |
 |
22
WhoMercy 2019-05-17 08:05:27 +08:00 via Android 1
你对代码的掌控，可能还了解得不够。
一般来说写了一个逻辑就要考虑到可能遇到的各种情况，要确保自己写的代码都能正确处理，也就是要确定好边界，如果边界很模糊，就要让写出来的代码逻辑尽量完全覆盖。 还有，犯错人人都会，只是对待的态度不同，就会决定以后是否还会继续犯错。 要对自己更严格一些，对自己的代码负责，工作上做到事无小事，错无小错。 |
 |
23
dajj 2019-05-17 09:04:37 +08:00 1
正常。 其实就是缺少测试。 其它什么强类型，代码风格，评审都是次要的， 只有测试用例才能保证质量。
通常测试都挺弱的，他们也不会帮忙构造测试环境，测试数据，想要提高质量，只能花更多时间自己测试。 |
 |
24
mamahaha 2019-05-17 09:09:45 +08:00 2
经常犯错证明工作内容是以创造为主，设计师的能力是体现在创造力上。过去设计院出图纸，都会有审核、校核、确认。。好几道把关，看似是人力成本增加了，但极大减小了出错造成的灾难性损失。
有了正确的认识，你就会明白不是你不合格，而是你的领导不合格。 |
 |
25
lil460982475 2019-05-17 10:42:53 +08:00
我认为最大的问题是公司上线流程不规范，比如编码规范，测试，代码审查等等。如果必须在集成测试通过才能上生产，起码不会出现你描述的时间赋值等问题
当然，个人的编码习惯很重要 |
 |
26
HansCathy 2019-05-17 10:44:18 +08:00
有 bug 很正常，review 代码 + 单元测试 + 集成测试 基本能发现大部分的问题
|
 |
27
ninechapter 2019-05-17 10:49:46 +08:00 1
两个建议减少低级 bug:
1. 养成良好的 coding style，这个可以看看 google、facebook 这些大厂的 coding style guide book。https://google.github.io/styleguide/javaguide.html 2. 养成良好的 debug 流程和习惯。这里有一份 debug 基本步骤： https://www.jiuzhang.com/qa/3815/ |
|
28
season8 OP @ninechapter 谢谢，有心了
@mamahaha 跟领导没关系吧，主要责任还是对自己，因为很多后端内容只能后端人员才能测出来，虽然没有完整体系，但这个是很多公司的通病吧 @dajj 切合实际来说，我很赞同 @HansCathy 谢谢鼓励，所以加强测试是关键 |
 |
29
526326991 2019-05-17 15:21:26 +08:00
coding 五分钟，测试两小时~
coding 五分钟，review 两小时~ |
Select Language