这是一个创建于 1972 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天有是同样的原因导致了 bug，有点沮丧，开始自我怀疑了
 |
1
kiroter 2020 年 8 月 31 日
正常，蛋定
|
 |
2
takemeaway 2020 年 8 月 31 日
同一个错误犯几次，是你的问题。
开发后出问题，是正常的。世界上有没 BUG 的东西吗？ |
 |
3
sunziren 2020 年 8 月 31 日
所以问题是什么？ ？？
|
 |
4
karnaugh 2020 年 8 月 31 日
只能说多动脑，写代码!=动脑子，有时候只是肌肉记忆码代码而已，当你有意识的去脑补逻辑，完善需求的时候，这种没考虑到的问题会减少
但这中行为本身是“用力气”的，你本能的回去排斥，只能慢慢养成习惯了 |
 |
5
devHang 2020 年 8 月 31 日
TDD 或许可以尝试
|
 |
6
wzzzx 2020 年 8 月 31 日
俺一个一年经验的感觉，这个事不是很正常嘛。。。
|
 |
7
watzds 2020 年 8 月 31 日 via Android
虽然我其他记性很差，不过这个错我不会犯
|
 |
8
JJstyle 2020 年 8 月 31 日 via iPhone
可以分享分享，我也来分享 phper 容易犯的错：1. 取数组元素时没判断 key 是否存在：2. 取对象属性时没判断对象是否存在； 3.并发场景下 select then insert/update 没有使用事务和锁
|
 |
9
Hanggi 2020 年 8 月 31 日
刚觉还是测试写少了，测试覆盖的可能性足够广可以降低 bug 概率，当然依然无法保证 100%无 BUG 。
|
 |
10
OHyn 2020 年 8 月 31 日
把这个问题写到测试用例中。
|
 |
11
jon 2020 年 8 月 31 日
到底啥问题
|
 |
12
leekafai 2020 年 8 月 31 日
逻辑问题可以测试用例规避下，性能问题不遇到特定场景可能浮现不出的。
人尚且可以买保险，代码写的系统服务只能救火 |
 |
13
kop1989 2020 年 8 月 31 日
有问题没考虑到或者说逻辑有缺陷这个很正常。
但关键就是要有自查和快速纠正的机制。 比如楼上说的测试用例。 只有一种情况不应该，就是相同的业务出现两次逻辑不完整，这就需要反省一下了。 |
 |
14
Nuttertoo1s 2020 年 8 月 31 日
今年刚毕业，3 月份入职到现在经常会因为 String 类型忘加空判断，导致经常会有空指针的 bug
|
 |
15
DJQTDJ 2020 年 8 月 31 日
|
 |
16
xuanbg 2020 年 8 月 31 日
写文章之前要先谋篇，写代码也一样。
|
 |
17
wysnylc 2020 年 8 月 31 日
先设计画图再开发,如果是编码错误那没救
|
 |
18
RedBeanIce 2020 年 8 月 31 日
暴言：哪怕是 10 年 Java，测试自己的代码也会 NPE ！
|
 |
19
bsg1992 2020 年 8 月 31 日
代码问题 还是业务问题。 一般这种情况属于后者业务没有吃透和理解导致编码时出现问题。
|
 |
20
YuTengjing 2020 年 8 月 31 日
提交代码前 review 一遍，提交 PR 前再 review 一遍，再让同事 review 一遍...
|
 |
21
Chenamy2017 2020 年 8 月 31 日
多想一下，多测试一下。
|
|
22
Chenamy2017 2020 年 8 月 31 日
编写代码前多想一下，编写代码后多测试一下。
|
 |
23
imnpc 2020 年 8 月 31 日
微软很厉害吧
win10 曾经一个 正式版，将用户非 C 盘我的文档目录清空删除过？ 被迫回收版本重发新版 |
 |
24
redford42 2020 年 8 月 31 日
人非圣贤哈
只能说遇到过一次的坑尽量不要踩第二次 如果是当初写的时候连续踩两次 那不是当时还没发现吗 不要沮丧哈，好好售后就行 |
 |
25
ytmsdy 2020 年 8 月 31 日
正常，我还删过生产数据库呢。谁都有脑子瓦特的时候，淡定，淡定。
|
 |
26
bl 2020 年 8 月 31 日
测试团队要好好测试
|
 |
27
tempask 2020 年 8 月 31 日
开始开发前的过程不完善，有欠账，很可能不光是你有问题，你的 leader 也有问题
|
 |
28
qsnow6 2020 年 8 月 31 日
同意不能避免 100%无 Bug，但反对拿 Bug 无法避免当借口，输出的代码质量低下，同一个 Bug 反复出现。
|
 |
29
as80393313 2020 年 8 月 31 日
有历史局限性不很正常吗。
|
 |
30
leafre 2020 年 8 月 31 日
神都不能保证没 bug
|
 |
31
simo 2020 年 8 月 31 日
这样才能从某种程度上保障开发和测试、运维下游人员的就业问题。
|
 |
32
isnullstring 2020 年 8 月 31 日
正常
|
 |
33
exploreXin 2020 年 9 月 1 日
有一个学科叫做 “软件工程”，推荐你了解一下。
|
 |
34
enjoyCoding 2020 年 9 月 1 日
我觉得题主问题应该是
可能最开始你做的时候有 abc 三个解决方案, 由于 a 比较省力或者当时你觉得 b 扩展性比较强, 所以选了 a 或者 b,但是后续来了个需求 x,这个需求只能用 c 才能写这时候应该怎么办 这一般是架构师小公司 CTO 的问题 这个需求要么挡掉要么延期拖着 要么给时间直接重写用 c 要么暂时用 lowB 方法兼容一下 小锅你背大锅 leader 背 背不动离职 另: 产品难道没锅嘛? 我们公司的产品有事没事也聊一聊产品的发展方向 后续可能的功能 不至于技术选型瞎选 |
 |
35
qq1004108488 2020 年 9 月 1 日
设计开发规范，并执行
|
Select Language