最近看到组内的开发同学有一种倾向，不敢也不愿重构，喜欢贴膏药或者另起炉灶再搞一套。分析和猜测下原因如下：
1，这是历史代码和历史原因，不归我管；
2，原来这块业务我不了解，重构有风险，不如贴下膏药，又快又安全；
3，原来的代码搞的太复杂了，再独立搞一套，既有成就感又不用去理原来的逻辑；
4，我的目标是完成需求，重构的事做不做无所谓
5，进度紧，来不及重构。
对修改原有代码有强烈的恐惧，对4PL的订单的主干流程完全不敢动，有时你静下心来，甚至能听到4PL在不断腐烂的声音。
为什么要重构？
martin fowler的《重构》这本书里讲的已非常清楚了。我这边只从我们的实际情况来说下，作为互联网公司，我们做的产品是不断变化，不断完善和调整的；相应的，我们的技术架构和设计，肯定也要不断的变化和调整来适合新的业务和需求。去年9月，我们的产品刚上线，Web和Task还是一个war，任务执行间有干扰，订单得不到良好的监控，但是重要的是，当时的系统能完成当前的邀请；慢慢的随着业务的发展，我们web,task分离了，订单流程又进行了一次大重构，良监控、监控面板上线，任务框架上线，历史订单归档等；到现在结算应用上线，开发平台也即将上线，干仓库体系。
我想当初设计的很多方面，4PL的各个模块的架构和设计都面临挑战，站在当前时间点，我想我们没有理由和权利去责怪当初为什么没考虑到，我们能做的拿出勇气，去不断重构和升级，让系统能健康和良好的发展。
关于重构的时机
重构是一个常态，在需求和项目过程中，如果当前的设计不能很好和很自然的添加你的功能时，建议你先重构掉原有的代码，再添加新的代码。
系统不下线，重构不停止。
重构需要勇气
光抱怨是没用的，需要鼓起勇气去面对重构。好的Coder敢于直面腐烂的代码。加油！