@
konakona 我估计都不是 bug，就是写的时候自己都搞不清写的是什么东西，程序结构混乱不清晰，只图实现需求，写完之后自己不能确定程序是有问题还是没问题，自己在调试的时候就能感觉到这个代码的杂乱臃肿，即使测试通过了心里还是觉得没底，认为这是个定时炸弹随时可能爆炸。
原因也很简单，太菜了。比如：
1、需求开始的时候因为上线压力、与策划人员的沟通等问题没时间好好理解需求，没法设计好程序架构；
2、需求进行的时候随着对需求的理解的深入，以及策划人员对需求的变更，表结构数据结构甚至程序流程一直在随之变化，写代码就成了抗洪救灾式哪里不对改哪里，代码结构很混乱，类方法分工不清晰，各种耦合和重复，最后只能保证能实现需求的要求，不能保证没有副作用，具体会有什么副作用不好说，要测试出来才知道...
3、需求上线之后只要程序能用就基本不能修改或重构，因为一段时间之后，其他依赖于这个功能的需求会一层层地添加进来，任何对老程序的修改都可能会引起其他功能的问题，重构的成本太高，需要测试所有跟这个程序影响的数据相关的功能
这样做的结果也很简单：
上线后如果真的没问题那就是万幸，没有必要一定不再去碰这些代码；上线就出 bug 也很幸运，可以马上修改，然后就可以睡踏实觉了；过了两三个月半年，有一天突然谁谁谁吼了一句这里的数据怎么不对，一路查下来发现是这个代码造成的那简直就是噩梦，可以两三天不用睡觉了。长期下来心理压力就会过大，对工作的态度变得消极厌倦，产生辞职重来的思想（类似于系统越来越卡实在受不了了就会选择重装系统）
唯一的好的方面是会驱使人自发地去了解怎样才能做出好的程序设计，会开始阅读 代码大全、程序员的修炼之道、重构、代码整洁之道 等书，开始追求清晰明了的代码风格
不要问我是怎么写出这些的