怎样用三条线画一只老虎?

看看这本书 马丁·福勒和他的 http://www.refactoring.com/ 网站。

干净的代码 是降低代码复杂性的另一个好资源。

看看这本书 Anti-Patterns Refactoring 作为重要的第二步。

结账, Working Effectively with Legacy Code

• 了解软件变更的机制:添加特性、修复缺陷、改进设计、优化性能
• 编写测试以防止引入新问题
• 可用于任何语言或平台的技术,包括爪哇、C++、C和C中的示例
• 准确地确定需要在哪里进行代码更改
• 处理似乎没有任何结构的应用程序

虽然在智力上很刺激,但细节去除的概念并不能很好地(至少是现在)应用到软件程序中。原因是,绘图是由具有接受模糊输入能力的人重新评估的,而程序是由一个“填空”能力很差的CPU重新评估的。另一个更微妙的原因是程序传达了 叙事,而绘画本质上是空间的。

因此,对于软件来说,近似和彻底删除特定代码部分的空间要小得多。无论怎样, 是可操作的关键字,有时甚至适用于最尴尬的遗留件。然而,这门学科既是艺术又是科学,我所知道的“快速技巧”并不多。

编辑

这是一个很难回答的问题:-)

首先,我们如何衡量“复杂性”?如果没有事先确定的衡量标准,可能很难证明任何“削减”项目是合理的。

第二,这个选择完全是你的吗?如果我们可以举一个例子,假设在一些代码库中,“继承”的锤子被用来解决其他问题。虽然使用继承在某些情况下是完全正确的,但它可能并不适用于所有情况。在这种情况下你怎么办?

第三,可以证明程序的行为/功能没有因为重构而改变吗(当代码是装运产品的一部分时,这会变得更加复杂。)

最后,以我的拙见,我认为任何这样的重构项目更多的是人的问题而不是技术问题。所有的程序员都想写出好的代码,但是对好代码和坏代码的看法是非常主观的,而且在同一个团队中的不同成员之间是不同的。我建议为这个项目建立一个“设计惯例”(比如 C++ Coding Standards ). 如果你能做到这一点,你就基本完成了。剩下的部分是 修改代码中不符合设计约定的部分