“推倒重来”的讲究
上个月，有个以前的同事问我：“你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊”。
我说：“我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”
他说：“对，但我还是想知道，你为什么不把系统重做了呢？”
于是我问：“我离职之后，后来似乎多投了不少人重做系统？结果怎么样呢？”
他说：“结果，结果就是做业务要同时操作三四套系统……”
就我所见，把原有系统“推倒重来”的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头，来个干脆的彻底解决。
这种心情可以理解，但在我任内“重做系统”一直没有被提上日程，整个技术团队所做的都是“改良”的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然“推倒重来”，我未必能比继任者做得更好，甚至可能更糟糕，因为“推倒重来”绝不是那么简单的事情。