Bug猜想（三）

二等“医师”：重构，预见 Bug。

现在请允许我讲个故事。

从前有座庙，庙里面住着一个老和尚，每天起床、吃斋、念佛、休息。用代码表达老和尚的一天可以是这样的：

GetUp();
Breakfast();
Buddha();
Sleep();

后来，来了一个云游的和尚，在庙里住了下来，一样的生活，起床、吃斋、念佛、休息。当然不可能有完全一样的生活，新来的和尚，年轻，每天会早起做一些杂物，功课念得是金刚经。而且外面兵荒马乱的，年轻的和尚偶尔还会出去做法事，超度亡灵。这些体现在代码里面就是多了很多if else。

一天，年轻的和尚出门做法事，看见要给快要饿死的小孩子，于心不忍，便带回了庙里。就这样庙里多了一个小和尚，小和尚跟着师傅过着一样的生活。不过毕竟是小孩子，好奇心强，做事没什么准则，今天起晚了，明天跑去外面玩了，师傅也没怎么约束，就由着小和尚去了。这些体现在代码里，可能就是又多了许许多多的if else，还是一些经常改动的 if else。

后来。。。。。。

可能故事并没有那么恰当，只是想表达一下自己的不可思议。虽然只再过两家公司，但是都遇见了这样的 if else。一家公司里面是一个2000多行代码的函数，5、6层的if else嵌套在一起；另外一家是交给我负责的“最复杂”的模块，几个相似的业务就这样“错综复杂”的交织在一起，让人想动又不敢动，想去改下结构，又担心看错了哪里的逻辑。

在第二家公司，当我把这个最复杂的模块看明白了之后，就一直在想，学过的那些面向对象都去哪里了？代码怎么会这样发展？可能是这样的：系统刚起步的时候，负责的东西不是很多，只实现了一个稳定的业务，根据这个业务有了初始的架构；当新的业务添加进去的时候，实现的人并没有想太多，if else 就搞定了；当又添加了一个不是很稳定的业务的时候，就变成的一堆改来改去的if else。也许后面来了新人，就更加不愿意去改这些已经可以“稳定”运行的代码，缝缝补补，就变成了这样。就像上面的故事一样。

不禁在想，其它的地方是不是也有着这样的代码。又有多少的bug是因为这些让人理不清的if else造成的；为了修改Bug去一遍一遍的理清这些if else又浪费了多少时间；为了修改一个Bug又造就了多少新的Bug！

敏捷开发的关键是迭代！系统的迭代不是简简单单把后续的功能填鸭式的塞进初始框架中去。迭代的不仅仅是功能的数量，还应该有系统的架构、数据库、界面又或者是其它需要不断修改进步的地方。

敏捷开发是为了更快更好的开发，不是为了给将来造成更多的麻烦。这个责任和这个锅应给都是给程序员来背，因为痛苦的是程序员，一波人造就了下一波人的痛苦，也可能是今天的你造就了你明天的痛苦。