自己写的 bug，自己都不想改，今天竟然萌生了离职的念头

[z21victor]

我得多嫌弃自己啊，水平也够差劲的！！！

[twtww]

自己写的bug，哭着也要改好。

[moult]

自己约的炮，含着泪也要打完。

[niboy]

不会改就多请教人

[hyt7212]

@moult 就是，既然是自己搞的，就必须搞完

[kurtrossel]

为什么看到这个标题，笑的完全停不下来啊！！！！！！！

[shippo7]

甩锅走人吗

[cheng007]

业务代码上线后确实不怎么好重构。

[Gonster]

我们不搬运锅 我们是锅的生产者

[MaiCong]

自己挖的坑，熬着夜也要把它填完

[kingme]

我已经离职了。。还要远程帮忙填坑。。。

[asj]

这还好啦，我曾经追bug看到一段写得shit一样的代码，一通骂。然后追提交历史记录，最后发现是自己提交的

[Septembers]

@asj 我经常写完提交发现有问题改提交又发现问题改又提交反复循环

[243205964]

看来大家都有过一段不堪回首的经历啊。

[xixijun]

自己拉的屎 跪着也要吃完 （奇怪我都说了些什么

[kn007]

@asj ...我也曾有过类似经历

[xylitolLin]

说出了我目前状况，共勉吧

[konakona]

@twtww 9494.
楼主不如说一说啥bug？

[exuxu]

自己的代碼，跪着也要修改．T ＡＴ

[feiyuanqiu]

@konakona 我估计都不是 bug，就是写的时候自己都搞不清写的是什么东西，程序结构混乱不清晰，只图实现需求，写完之后自己不能确定程序是有问题还是没问题，自己在调试的时候就能感觉到这个代码的杂乱臃肿，即使测试通过了心里还是觉得没底，认为这是个定时炸弹随时可能爆炸。

原因也很简单，太菜了。比如：
1、需求开始的时候因为上线压力、与策划人员的沟通等问题没时间好好理解需求，没法设计好程序架构；
2、需求进行的时候随着对需求的理解的深入，以及策划人员对需求的变更，表结构数据结构甚至程序流程一直在随之变化，写代码就成了抗洪救灾式哪里不对改哪里，代码结构很混乱，类方法分工不清晰，各种耦合和重复，最后只能保证能实现需求的要求，不能保证没有副作用，具体会有什么副作用不好说，要测试出来才知道...
3、需求上线之后只要程序能用就基本不能修改或重构，因为一段时间之后，其他依赖于这个功能的需求会一层层地添加进来，任何对老程序的修改都可能会引起其他功能的问题，重构的成本太高，需要测试所有跟这个程序影响的数据相关的功能

这样做的结果也很简单：
上线后如果真的没问题那就是万幸，没有必要一定不再去碰这些代码；上线就出 bug 也很幸运，可以马上修改，然后就可以睡踏实觉了；过了两三个月半年，有一天突然谁谁谁吼了一句这里的数据怎么不对，一路查下来发现是这个代码造成的那简直就是噩梦，可以两三天不用睡觉了。长期下来心理压力就会过大，对工作的态度变得消极厌倦，产生辞职重来的思想（类似于系统越来越卡实在受不了了就会选择重装系统）
唯一的好的方面是会驱使人自发地去了解怎样才能做出好的程序设计，会开始阅读 代码大全、程序员的修炼之道、重构、代码整洁之道 等书，开始追求清晰明了的代码风格

不要问我是怎么写出这些的

[z21victor]

@feiyuanqiu 你的说对，多方面因素造成的，时间紧，第一次接触这类项目，二次开发，预言型开发，支持少，沟通问题，水平问题等等。。。很大一部分是自己问题，当时真的心存侥幸的心理。没有办法，现在睡觉都能想起bug，然后醒了。给自己点教训吧，之后的部分就好多了。

[z21victor]

@konakona 嵌入式开发，不算是bug，类似于结构问题，后续添加某些功能有点难度，主要是麻烦。

[z21victor]

看来大家了解。。。