由于最近换了新工作，新公司的代码在结构和规范上都不是很好，于是希望后续通过重构来优化代码。
但是重构的标准是什么？什么才叫好的代码呢，如果单凭经验，容易陷入个人喜好主义，那和之前的代码有何区别呢？也许别人看你重构的代码也和你现在看别人代码一样呢，这样不就变成一个死循环了吗。
因此，在重构前，我觉得有必要阅读相关资料，寻找理论依据去支撑我的行动。业界评价度颇高的一本叫《重构》的经典著作里面的观点，应该是大家达成共识最好途径。
下面摘录了部分阅读中感触比较深的段落。
《重构—改善既有代码的设计》
何时重构
最近跟同事经常的对话是：
我：小明，你知道那块代码是什么意思吗，代码有点混乱，我没法弄懂。
小明：那块代码很复杂的，现在已经能跑，你就别动它了。
下面是书上提到何时应该重构，看下面的场景，是不是和我目前的状况非常相似呢。
你的态度也许倾向于尽量少修改程序：不管怎么说，它还运行得很好。你心里牢牢记住那句古老的工程谚语：“如果它没坏，就不要动它。”这个程序业务还没坏掉，但它造成了伤害。它让你的生活比较难过，因为你发现很难完成客户所需的修改。这时候，重构技术就该粉墨登场了。
怎么跟经理讲重构
最近跟产品经理讨论，我们需要抽取时间进行代码重构，产品经理的观点是以完成工作为优先，重构工作其实没那么重要。但是我是不同意他的观点的，今天刚好读到了这一个话题，给我提供了一个完整的理论基础。
很多经理嘴巴上说自己“质量驱动”，其实更多是“进度驱动”。这种情况下我会给他们一个较有争议的建议：不要告诉经理！
软件开发者都是专业认识，我们的工作就是尽可能快速创造出高效软件。对于创造软件，重构可带来巨大帮助，如果需要添加新功能，而原本设计却又使我无法方便地修改，先重构再添加新功能会更快些。受进度驱动的经理要我尽可能快速完事，至于怎么完成，那就是我的事了。
关于技术债务
我以前理解的技术债务只是有不良的代码，需要抽时间进行偿还。书上说，债务是会产生利息的，确实是这样，不良的代码就像债务，会产生利息，时间越长，利息越高，最后将会无法偿还，直到破产。
“技术债务”：把未完成的重构形容为“债务”，很多公司都需要借债来使自己更有效的运转，但是借债就得付利息，过于复杂的代码所造成的维护和扩展的额外成本就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。
