1
James369 OP 我应该说出了很多程序员的心声,哈
|
2
jasonyang9 2021-08-11 15:54:49 +08:00
|
3
chendy 2021-08-11 16:10:38 +08:00
但是市面上少说一半程序员做不到楼主说的这些。。。
|
4
masterclock 2021-08-11 16:53:43 +08:00
- 传入的参数控制好边界,非法值的判断:
第一个就无法认同: 一个测试工程师走进一家酒吧…… |
5
sadfQED2 2021-08-11 17:14:00 +08:00 via Android
我每次都写了各种 case 的单元测试,我代码提交后 qa 还会 review 代码,然后 qa 会写各种情况的功能测试用例。
然后,依旧经常出 bug,根本原因就是,屎山太大,总会出现各种根本意料不到的反人类情况 |
6
jones2000 2021-08-11 18:28:07 +08:00
上线以后 bug 多不多, 还是要看你的 test case 覆盖是否够, Code coverage 是否够了.
|
7
IvanLi127 2021-08-11 18:31:05 +08:00
@masterclock 测试工程师走进一家酒吧后点的东西不就是在测入参嘛?
|
9
MiketsuSmasher 2021-08-11 22:16:09 +08:00 1
@IvanLi127 酒吧开业了,顾客点了一份炒饭——测试工程师压根没往这方面想过——然后酒吧炸了
|
10
sutra 2021-08-11 22:27:21 +08:00 1
“我写的 bug 是过去的 /未来的 feature,但它却是现在的 bug 。”
|
11
kkbblzq 2021-08-11 23:44:56 +08:00
一颗钻石被丢上了屎山,很快它就被屎山淹没了。
|
12
janxin 2021-08-12 00:10:43 +08:00 via iPhone
为什么是“我”而不是我
|
13
imbushuo 2021-08-12 04:09:13 +08:00 2
实际上 Spec 写的不严谨,实现的人对 Spec 的理解有误差也会导致问题:Leslie Lamport 来我们这里做 tech talk 的时候提到过他发明 Paxos 的时候写了一份英文说明和一份数学证明,结果没人看后者,大家都看着前者实现;直到几年前 MSR 有个实习生提醒他原版英文说明里有一句话有歧义,理解错了那句话会导致实现有一个潜在的 bug,然后他们发现很多开源 Paxos 实现全部理解错了那句话,导致它们都有这个共有的 bug
他举这个例子说明 Spec 要用 formal 的东西写,比如说用 TLA+ 描述软件的行为 |
14
Rocketer 2021-08-12 04:28:40 +08:00 via iPhone
@MiketsuSmasher 酒吧点炒饭那个深有同感。
我曾经写过一段代码,需要根据数据库类型做不同处理。当时我们只有 MySQL 和 MongoDB,所以我写的 if…else... 结果一年以后有人在一个新模块中用了 Oracle,崩了…… |
16
jorneyr 2021-08-12 08:03:46 +08:00
我们小公司,去年产生了 6000 多个 Bug,大多数都是开发人员写出的 Bug 。
|
17
xuanbg 2021-08-12 08:21:08 +08:00
我从来不会因为需求混乱造成 bug 。不吹牛地说,任何混乱的需求只要上我手,就不会混乱了。
然鹅,经常会有一些因为复制粘贴后忘记修改造成的小问题。这种 bug 一般自测一轮就都排除掉了。所以最终交付的产品基本没有 bug 。 |
18
xuanbg 2021-08-12 08:23:25 +08:00
@masterclock 是的,只靠严谨没用,只有抽象才能解决。管你几路来,我只一路去,就不会有一个测试工程师走进一家酒吧的各种问题发生了。
|
19
Qseven 2021-08-12 09:14:26 +08:00 1
当一个程序员有了足够的责任心和敬畏心,那么他写出的代码会少很多 BUG 。
|
21
jslang 2021-08-12 09:22:33 +08:00
测试的时候不是很到位
|
22
jslang 2021-08-12 09:22:47 +08:00
或者没有经过测试
|
23
JaguarJack 2021-08-12 09:22:56 +08:00
没时间!!!
|
24
raaaaaar 2021-08-12 09:42:02 +08:00 via Android
首先要有意识,再有能力,最后还要有足够的时间。太过于理想化,很多时候只能说有这个意识就够了,慢慢迭代就好,不可能一劳永逸的。
|
25
imnpc 2021-08-12 09:43:00 +08:00
很多时间是没有足够的时间测试 忙的时候 只能先开发完功能 让客户配合测试
|
26
kop1989 2021-08-12 09:47:04 +08:00
与其说是需求太复杂,不如说是覆盖不住处理需求的成本。
而且成本不能 100%覆盖需求,是软件工程的常态。 所以我们能做的,就是尽量的高效利用成本。(这里的成本包括但不限于时间、人力、项目风险等等) 所以必然程序中充满着面向效率的妥协。 bug 也就因此产生。 |
27
kop1989 2021-08-12 09:48:48 +08:00
这就像是,造一个一千年不倒塌的房子不难,难在你要在有限的成本以内造。
|
28
wolfie 2021-08-12 09:51:40 +08:00
项目管理问题 高于 需求变更
|
29
liuidetmks 2021-08-12 09:58:05 +08:00
@Rocketer 哈哈,这个锅是不是甩到你头上了。老代码为新需求造成的 bug 负责
|
30
chanchan 2021-08-12 09:59:34 +08:00
需求混乱?经常整个工作过程都很混乱其实
|
31
liuidetmks 2021-08-12 10:02:13 +08:00
|
32
User9901 2021-08-12 10:16:46 +08:00
甩锅 101
好好看好好学,圈起来要考的 |
33
wat4me 2021-08-12 10:18:46 +08:00
需求太多,时间太少。
|
35
duhb 2021-08-12 13:01:55 +08:00 via iPhone
时间够怎样都行,最主要的是时间不够问题。
|
36
jack778 2021-08-12 13:43:50 +08:00
技术层面避免 bug 相对简单,但是业务逻辑很多是有坑的,稍微理解不透彻就出 bug 了。你永远不知道你的用户会怎么使用你的系统。
|
37
jack778 2021-08-12 13:45:12 +08:00
@masterclock 只要让我看到你的源码,我就有办法让你的边界防御失效
|
38
desdouble 2021-08-12 13:49:21 +08:00
talk is cheap, show me the code.
|
39
clf 2021-08-12 14:01:12 +08:00
还有就是对业务理解的偏差导致的。后端接口按业务逻辑实现了,前端以为按 UI 写好就行了,结果调接口的时候能给你整出一堆花活。
|
40
sexyback 2021-08-12 14:04:43 +08:00
刚参加工作没多久,因为公司的项目经常做实验,效果好了就规模化,有时候需求不能很明确,经常改动,现在真心理解楼主的话
|
41
suotm 2021-08-12 15:38:17 +08:00 1
哈哈,这个我晓得,多和 Rust 的编译器斗争,然后去写脚本语言( JavaScript/Python).
|
42
macha 2021-08-12 15:38:35 +08:00
业务一旦复杂起来就很难全部覆盖到,所以有时候我都是先和所有人谈好我的代码能覆盖的场景,让大家一起 review 。
只要把所有场景 cover 住了,至少出去的产品是符合设计预期的。 所以有时候不是追求无 bug,而是追求产品是符合设计预期的。 |
44
dinjufen 2021-08-12 19:09:53 +08:00
我也想写出逻辑缜密、bug 少的代码,无奈经常加班太疲惫。996 的情况下你还能写出好代码么?很多公司把技术看得并不重,很多人认为只要增加工作时间,功能就一定会做得更快更好。
|
45
rekulas 2021-08-12 22:19:44 +08:00
如果说第一条多花点时间还勉强可以做到
第二条 "所有的异常情况考虑周全,捕获到位。" 永远做不到,如果你做到了,那一定是系统不够复杂 |
46
Myprajna 2021-08-13 08:47:10 +08:00
老板,来一份酒吧炒饭!
|
47
lulu7 2021-08-13 09:41:28 +08:00
佩服楼主的责任心,如果程序员都是你这样的,那项目的效率会提高很多吧。之前看过一个尽早崩溃的贴子,现在有点分不清到底是尽早崩溃,还是用防御性编程了。一个死掉的程序不是比一个瘫痪的程序造成的损失要小得多吗?所以在没有瘫痪时要用防御式编程吗?
贴子: https://www.zentao.net/redirect-index-19377.html |