谈谈代码重构
有时候，当一个重要的项目进展不顺利时，就有了重新开始的愿望。有时这来自管理层，但通常来自开发人员自己。他们说，如果他们只有第二次机会，并且可以重新开始，那么他们可以建立正确的系统。
但这几乎从未发生过。从我这拿走。我见过公司多次尝试，我可以毫无例外地说，当一个团队开始用基本相同的方法重建相同的系统时，他们最终会得到大致相同的系统，包括同样的问题只有这个他们必须维持两个系统的时间。
传统代码得到了糟糕的说唱。人们害怕接触它，但它体现了经过时间考验的业务规则和程序，即使最棘手的遗留代码在用于重构系统时仍然具有价值。
重构也很糟糕，因为开发人员和管理人员都不熟悉它。他们不知道有一种安全的方法来重组他们的“泥球”，他们的软件已变成更易于管理的块，这些块可以独立验证，因此维护和扩展的成本更低。
重构遗留代码通常是打破它的过程。它可能已经过程编写并且工作良好多年，但是，为了改进构建并支持持续集成，代码需要分解为可独立验证的部分。
别担心。困难的部分结束了。该软件做了它需要做的事情，所以重构它实际上只是重组它的问题。这并不意味着它不容易或没有风险，但有办法解决出现的问题，而且这些变化带来的好处往往能给公司带来竞争优势。
可以这样想，大多数软件都是程序性编写的，并且采用全局视角。这对于简单的程序来说很好，但随着系统的复杂性不断增加，我们需要一种方法来管理这种复杂性。
面向对象编程为我们提供了一种管理复杂性的方法，它通过采用我们想要创建的行为并将其放在一个“对象”集合中，这些对象可以交互以创建该行为。
通过这样做，我们将系统的不同部分彼此隐藏起来。面向对象程序不是具有一个全局视角，而是由一组对象组成，这些对象相互作用以创建所需的行为。
通过将行为封装到正确的对象中的额外步骤，我们允许我们的系统通过自动化变得更加模块化和独立可测试，这降低了我们生产的软件的变更成本。
在大多数情况下，这绝不是一件容易的事。你的遗留代码从多年的疏忽中得到了这种方式，它可能需要一些努力来清理它，但如果它已经做了正确的事情那么通常是重组和重组代码的问题所以它在不同的地方但功能仍然存在相同。重新组织代码通常比从头重写代码更直接。
————————————————————
推荐阅读：
上一篇： A.Activity planning
下一篇： 谁不下水