其实过完年回来，我们的项目也一直在强调重构，在实践重构中，但是到目前为止，基本没啥进度。关于项目的重构，我说：基本上大部分都是骗人的。你们信不信？那你可能会问：为什么一开始不把代码写的更好一些，逻辑更严密一些呢？那欢迎大家看我写的这篇文章《代码质量差，bug多？我们都是被逼的 》，看完你会深有同感的。
关于项目重构的问题，为什么一直做不完呢？直到我在浏览微博时，看到了一个非常好玩的对话，可谓是：感同身受，深有同感。知道真相的我，眼泪都快笑出来了，估计看到下面的对话，你们也会感同身受的，身临其境都有可能。对话如下：
A：重构80%都会失败，因为业务线的需求永远都不会停，资源有限，所以不花大代价，轻易不重构，宁可开发的慢一点，写好。B：其实以业界大部分产品经理的水平99%的项目都活不到重构的那天，所以业务量上来再重构更省资源。对话内容来自于@Easy的微博
看到第一句话A说的，一看就是深受其害的程序员说的，是不是说到你心坎里了。中招的同学请举手，作为我们有责任的程序员只能仰天长啸：有心写码，无力高效。bug其多，痛哉痛哉！下次你们老板和产品经理再催你赶进度，你就大喊：时间不够，代码瞎凑，毁了软件，完了项目。上线以后，如果用户体验不好，老板来找你谈话或者训你，你就说：这个锅我们程序员不背。B说的话，眼光很长远，要这么说的话，确实更省资源。要是产品经理和老板看到的话，估计不开森了。
其实项目重构是一个非常锻炼程序员能力的活，而且重构是一个不断优化和学习的过程。项目重构的重要性更不用说了，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。可能你会问：为什么不一开始就把项目做好，代码质量写的更好呢？话虽说可能是时间问题引起的代码质量差，程序员为了赶工期，但是即使是给程序员充足的时间，他也不可能预见未来的需求的变化， 可扩展性和可维护性就无从谈起，今天你想好了代码这些，明天估计需求就又变化了。所以一个持久的好的项目也不可能避免重构的发生，写代码的高手和大神也一样，都得经历这个阶段。
那何时才能触发重构呢？答案其实很简单，你是在忍受不了混乱的代码的时候或者感觉可读性很差的时候。你的忍耐力决定重构的时机。当然如果你写的程序一直在崩溃的话，估计你得被迫去重构和优化了。其实代码重构的出发条件应该是一下几点：
牵一发而动全身的修改
代码中存在过多的重复代码
过渡的耦合
过长的方法和类（过长的代码，逻辑复杂，bug可能几率上升）
太多代码无注释，你已看不明白
如果中了上述几条，你该想想代码重构了。不要被动的去重构，主动去重构还是非常有必要的，可以避免很多问题的发生。
代码重构其实最重要，最应该注意的两点，也是应该达到的目的就是：代码的简洁，逻辑严密和性能的优化。这就是重构的意义所在和内涵。
写到这里，你们可能会问我：那该如何重构呢？是啊，我一本正经的写了这么多，你们肯定想知道这个问题的答案，到底该如何重构？那我就一本正经的告诉你们答案：如果老板和产品经理不好好对待程序员，你们基本到不了项目重构的那一天。A和B说的就是真理，你们服不服？
如果不服的话，我怕你们打我，我还是再一本正经的说两句吧，如何重构：在不改变软件系统外部行为的前提下，改善它的内部结构即可。也可以借助工具完成，重构工具能够修改代码同时修改所有引用该代码的地方。
请大家把这篇文章转发到朋友圈，让你们的老板和产品经理看看吧，让他们认识到问题的严重性，给自己争取更多的开发时间。下次如果产品经理再催你们进度，你们一定要记着一起大喊：时间不够，代码瞎凑，毁了软件，完了项目。
