写在前面

今天看到左耳朵耗子在自己博客酷壳上写的一篇文章开发团队的效率，我觉得写得太对了，作为一个在小公司待过的后端程序员来说，我深有体会。

经常听到“先这样”，“先简单实现功能，后面再改”，甚至在相关代码地方写一个TODO，“先一个星期上线，给客户demo”。

每次听到这样的话，感觉跟一群不懂程序的人一起写代码，好痛苦。帮他们review的时候甚至会提出：这样有必要吗？都一样吧？过度封装了吧？先简单实现，下次再改，明天要给客户演示。

当然，有时候我也是别人眼中的不懂程序的程序员，所以要好好学习，提升自己。

这篇文章写的太好了，一针见血，说出了我的心声，大家可以读一读。下面摘抄出两部分。

“WatchDog式”软件开发

什么是WatchDog？就是说——为了解决某个系统的问题，我要用一个新的系统去看着它。

我的系统架构太复杂，出了问题不好查找。咋办？那就搞个专门的特殊的监控系统吧……

我的系统配置太复杂，容易配错了。咋办？那就加一个配置校验系统吧……

我的系统配置和真实的情况有时候可能会不一性。咋办？那就加一个巡检系统吧……

我的系统测试环境和线上环境有时候会搞混了。咋办？那就为线上环境加一个权限控制系统吧……

我的系统有单点，那就加个负载均衡器吧，负载均衡器的单点呢？那就再加个等价路由器吧……

做加法谁不会？就不想去简化一样系统吗？就不能不拆东墙补西墙么？ 这些了系统加的越来越多，我看你以后怎么运维。

一开始没有想清楚就放到线上，然后，出了故障后，也无法重新设计和重新架构，只能以打补丁地方式往上打，这就好像一个本来就有缺陷的楼没有盖好，你要拆了重盖是不可能的，也只能不停地打补丁了。字是一只狗，越描越丑。

【解决方案】

1）设计想好了再做，多评估几个设计没坏处，简化，简化，简化。

2）残酷无情地还债，就算是CEO来了，也无法阻止我还债的脚步。

“故障驱动式”软件开发

WatchDog式的软件开发通常来说都是“故障驱动式”软件开发的产物。这种开发方式其实就是在表明自己智力和能力的不足。以上线为目的，上了线再说，有什么问题出了再改。

上面的老大或是业务方基本上会说，没关系，我们不一开始并不需要一个完美的系统，你先上了再说，先解业务的渴，我们后面有时间再重构再完善。而有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的。

我同意逐步迭代以及架构演化论，但是，我觉得 “系统迭代说”和“架构演化论”被彻彻底底地成为那些能力有限甚至不学无术的人的超级借口。

你们有没有搞错啊？你们知道什么叫迭代，什么叫演化吗？你们知道，要定位一个线上的故障需要花多大的力气吗？你们知道，随随便便去应付局部上你会快，但总体上来说你会慢。

虽然，我看到那些系统在一个又一个的故障后得到一点又一点的改善，但是我想说，为什么一开始不认真不严谨一点呢？我从来就没有见过一个精良的系统是靠一个一个的故障和失败案例给堆出来的，就算是Windows 95/98这样史上最烂的操作系统，如果没有设计精良Windows NT的补位，Windows也早玩完了（看看IE的下场就知道了）。