二等“医师”:重构,预见 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!
敏捷开发的关键是迭代!系统的迭代不是简简单单把后续的功能填鸭式的塞进初始框架中去。迭代的不仅仅是功能的数量,还应该有系统的架构、数据库、界面又或者是其它需要不断修改进步的地方。
敏捷开发是为了更快更好的开发,不是为了给将来造成更多的麻烦。这个责任和这个锅应给都是给程序员来背,因为痛苦的是程序员,一波人造就了下一波人的痛苦,也可能是今天的你造就了你明天的痛苦。