做开发快 4 年了，还是因为开发过程中有问题没考虑到导致后期出问题，有没有办法解决呢？

开发

bug

沮丧

导致

35 条回复 • 2020-09-01 15:31:45 +08:00

1

kiroter

2020-08-31 11:49:32 +08:00

正常，蛋定

2

takemeaway

2020-08-31 11:52:25 +08:00

同一个错误犯几次，是你的问题。
开发后出问题，是正常的。世界上有没 BUG 的东西吗？

3

sunziren

2020-08-31 12:18:51 +08:00

所以问题是什么？？？

4

karnaugh

2020-08-31 12:36:21 +08:00

只能说多动脑，写代码!=动脑子，有时候只是肌肉记忆码代码而已，当你有意识的去脑补逻辑，完善需求的时候，这种没考虑到的问题会减少

但这中行为本身是“用力气”的，你本能的回去排斥，只能慢慢养成习惯了

5

devHang

2020-08-31 12:37:57 +08:00

TDD 或许可以尝试

6

wzzzx

2020-08-31 12:39:08 +08:00

俺一个一年经验的感觉，这个事不是很正常嘛。。。

7

watzds

2020-08-31 13:02:49 +08:00 via Android

虽然我其他记性很差，不过这个错我不会犯

8

JJstyle

2020-08-31 13:03:52 +08:00 via iPhone

可以分享分享，我也来分享 phper 容易犯的错：1. 取数组元素时没判断 key 是否存在：2. 取对象属性时没判断对象是否存在； 3.并发场景下 select then insert/update 没有使用事务和锁

9

Hanggi

2020-08-31 13:13:21 +08:00

刚觉还是测试写少了，测试覆盖的可能性足够广可以降低 bug 概率，当然依然无法保证 100%无 BUG 。

10

OHyn

2020-08-31 13:19:57 +08:00

把这个问题写到测试用例中。

11

jon

2020-08-31 14:12:03 +08:00

到底啥问题

12

leekafai

2020-08-31 14:12:34 +08:00

逻辑问题可以测试用例规避下，性能问题不遇到特定场景可能浮现不出的。
人尚且可以买保险，代码写的系统服务只能救火

13

kop1989

2020-08-31 14:15:56 +08:00

有问题没考虑到或者说逻辑有缺陷这个很正常。
但关键就是要有自查和快速纠正的机制。
比如楼上说的测试用例。

只有一种情况不应该，就是相同的业务出现两次逻辑不完整，这就需要反省一下了。

14

Nuttertoo1s

2020-08-31 14:31:26 +08:00

今年刚毕业，3 月份入职到现在经常会因为 String 类型忘加空判断，导致经常会有空指针的 bug

15

DJQTDJ

2020-08-31 15:04:24 +08:00

@Nuttertoo1s

这不是你的事，这是 java 的事，他要是里面写了那个判断，你还能判断错了？

16

xuanbg

2020-08-31 15:08:52 +08:00

写文章之前要先谋篇，写代码也一样。

17

wysnylc

2020-08-31 15:11:34 +08:00

先设计画图再开发,如果是编码错误那没救

18

RedBeanIce

2020-08-31 15:20:36 +08:00

暴言：哪怕是 10 年 Java，测试自己的代码也会 NPE ！

19

bsg1992

2020-08-31 15:23:54 +08:00

代码问题还是业务问题。一般这种情况属于后者业务没有吃透和理解导致编码时出现问题。

20

YuTengjing

2020-08-31 15:26:31 +08:00

提交代码前 review 一遍，提交 PR 前再 review 一遍，再让同事 review 一遍...

21

Chenamy2017

2020-08-31 15:28:26 +08:00

多想一下，多测试一下。

22

Chenamy2017

2020-08-31 15:28:58 +08:00

编写代码前多想一下，编写代码后多测试一下。

23

imnpc

2020-08-31 15:32:03 +08:00

微软很厉害吧
win10 曾经一个正式版，将用户非 C 盘我的文档目录清空删除过？
被迫回收版本重发新版

24

redford42

2020-08-31 16:40:01 +08:00

人非圣贤哈
只能说遇到过一次的坑尽量不要踩第二次
如果是当初写的时候连续踩两次
那不是当时还没发现吗
不要沮丧哈，好好售后就行

25

ytmsdy

2020-08-31 16:48:09 +08:00

正常，我还删过生产数据库呢。谁都有脑子瓦特的时候，淡定，淡定。

26

bl

2020-08-31 16:51:03 +08:00

测试团队要好好测试

27

tempask

2020-08-31 17:21:33 +08:00

开始开发前的过程不完善，有欠账，很可能不光是你有问题，你的 leader 也有问题

28

qsnow6

2020-08-31 17:29:46 +08:00

同意不能避免 100%无 Bug，但反对拿 Bug 无法避免当借口，输出的代码质量低下，同一个 Bug 反复出现。

29

as80393313

2020-08-31 17:33:37 +08:00

有历史局限性不很正常吗。

30

leafre

2020-08-31 18:14:50 +08:00

神都不能保证没 bug

31

simo

2020-08-31 18:16:30 +08:00

这样才能从某种程度上保障开发和测试、运维下游人员的就业问题。

32

isnullstring

2020-08-31 23:33:20 +08:00

正常

33

exploreXin

2020-09-01 09:25:34 +08:00

有一个学科叫做 “软件工程”，推荐你了解一下。

34

enjoyCoding

2020-09-01 10:50:20 +08:00

我觉得题主问题应该是
可能最开始你做的时候有 abc 三个解决方案, 由于 a 比较省力或者当时你觉得 b 扩展性比较强,
所以选了 a 或者 b,但是后续来了个需求 x,这个需求只能用 c 才能写这时候应该怎么办
这一般是架构师小公司 CTO 的问题这个需求要么挡掉要么延期拖着要么给时间直接重写用 c 要么暂时用 lowB 方法兼容一下
小锅你背大锅 leader 背背不动离职
另: 产品难道没锅嘛? 我们公司的产品有事没事也聊一聊产品的发展方向后续可能的功能不至于技术选型瞎选

35

qq1004108488

2020-09-01 15:31:45 +08:00

设计开发规范，并执行