大多程序员不会做这件事！

         别轻易“重构代码”。

程序员的工作容错率相对来说已经很低了，自测、测试、产品验收、老板验收...经过多轮的检验，产品才能顺利上线。

尽管如此，日常工作中还是会有很多问题，让人不得不花时间去解决。在这么多问题里，我唯一不会去做的就是：重构代码。

并不是因为这样颠覆了之前对方案的判断，也不是因为专业度受到质疑，更不是因为花更多时间，而是大多数情况下，重构代码意味着落后。

为什么这么说？是有历史依据的，感兴趣的可以自行了解下网景被微软赶超的原因。

很多时候，市场机会就在一瞬，看起来是上线时间慢了一周，但可能你已经失去了一半以上的市场份额。

互联网，唯快不破。这个准则，我希望尤其创业者要牢记！

但话说回来，大部分程序员估计都希望自己的工作结果是相对完美的，没有垃圾代码，又能很好地实现需求。

甚至有些程序员，对于重构代码很兴奋，认为这是个重大的任务，内心异常激动...

程序员之所以想重构代码，大部分情况是因为他们自己真心觉得以前的代码非常垃圾！

有趣的是，经过我这么多年的观察和沟通，发现这样的想法，很多时候是有偏差的。其中有意思的是，我发现他们的看法有时候是错的。

程序员觉得以前的代码不好，是因为一条非常基本的编程法则：读代码比写代码更难。

几乎所有的程序员都不愿意在别人的代码上继续拓展，因为与理解旧代码相比，自己重新写个函数要简单得多！

认为旧代码不如新代码的观点，在我看来并不是完全正确。

旧代码经过测试和应用，已经找出很多bug，并且都进行了修复。

有bug是很正常的，对于大多数bug，修复的代码可能只有一行，甚至只是几个字符，但是这两三个字符却是大量智力劳动和时间的结晶。

如果把旧代码扔掉重写，其实是扔掉了所有经过实践检验的知识。

更致命的是，如果重构的周期特别长，对公司的影响将是巨大的。因为在这么长一段时间内，公司都只能出售旧产品。

竞品可不会放过这么好的空档期，看看如今的互联网，但凡某一领域的大厂业务出现重大问题，其他大厂或者领域内的创业公司能在几天之内迅速推出自己的产品，只盼你没有翻身的机会...

生意场犹如战场，分秒必争。

以上观点，希望对一些身处创业过程或想要创业的程序员有所启发。

商务合作 / 技术交流 / 进技术群