分解/重构程序

Question

术语“分解不良”和“重构”程序是什么意思？你能举一个简单的例子来理解基本的区别吗？

Answer 1

重构是一种通用技术，可以涉及许多任务。它通常意味着清理代码、消除冗余、提高代码质量和可读性。

一个非常简单的分解不良代码示例：

do_task1("abc");
do_task2(123);
do_task3(7.43);
...
//100 lines later:
do_task1("abc");
do_task2(123);
do_task3(7.43);
...
//80 lines later:
do_task1("abc");
do_task2(123);
do_task3(7.43);

看看同一组 3 行是如何一遍又一遍地重复的？

重构此代码可能会给出：

procedure do_tasks1to3(x,y,z)
    do_task1(x);
    do_task2(y);
    do_task3(z);
end

do_tasks1to3("abc",123,7.43);
...
//100 lines later:
do_tasks1to3("abc",123,7.43);
...
//80 lines later:
do_tasks1to3("abc",123,7.43);

重构的代码使用过程来执行重复任务，如果需要添加 do_task4，则只需在过程内部完成，而不是在 4 中完成像以前一样分开的地方。

还有其他方法可以重构它，当然，如果您需要对 do_taskn 函数进行更改，这可能行不通，但这通常是您开始的方式...

Answer 2

分解不良意味着包含冗余，或者组织方式使核心依赖关系难以看到。该术语最初来自数学：

Factoring: Finding what to multiply together to get an expression.

有多种方法可以分解表达式，就像有多种方法可以编写实现相同结果的程序一样。众所周知，代数中，找到合适的因式分解可以使整个方程更容易求解。

Answer 3

分解不良的代码是指以难以理解、维护、重用等方式编写的代码。

重构通常意味着改变一段代码/模块/程序的编写方式，而不实际改变其功能。重构的一些目标包括提高可读性、减少耦合和更轻松地重用代码（即修复分解不良的代码的问题）。

Answer 4

考虑不周意味着它的制作不精良。而重构是指审查和改进代码。

Answer 5

重构的方法

Answer 6

代码重构包括：

* Clarity: the meaning of the code should be obvious to anyone reading it.  Comments can be refactored as well for adding additional explaination for hairy code, but one should try to make the code itself clear enough to understand

* Eliminate redundant code:  refactoring is the time to recognize patterns and factor them out of your code.  Similar and redundant classes and code blocks should be combined, and unnecessary functions and variables eliminated.

* Modularity and Scalability:  code should be easy to extend or modify, and be able to scale without adding complexity

* Simplicity: Reduce Unnecessary complexity. Complexity should only be considered if it considerably increases readability or modularity ( hence reducing future efforts)

Answer 7

基本上使您的代码更加优雅：消除重复，使代码更易于维护且更具可读性。

但是，代码重构可能会过度。过多的时间可能会花在清理代码、使其更具可读性、更健壮等上。如果您在紧迫的期限内工作，这可能会很糟糕，例如一周可能会花在重构代码上。结果是一段代码，它可能“功能上”做同样的事情，但只是更具可读性，或者看起来更漂亮一些。

我发现最好是边重构边重构，偶尔重命名变量、方法等，并在以下情况下进行更大的重构方法：
a) 我知道我会有足够的时间。和
b) 通过重构这部分代码，将获得显着的功能/性能优势。 （超过了时间缺点。）

只是我的经验。

我的同事告诉我阅读 Robert Martin 的《清洁代码》：- http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 /ref=sr_1_1?s=books&ie=UTF8&qid=1346277262&sr=1-1

Answer 8

分解不佳意味着它没有经过足够的迭代重构来删除不良的设计模式（即反模式）。

一般来说，这意味着它只是糟糕的代码。

Answer 9

我喜欢将其视为一个数学隐喻（无论它与字面对应有多么接近，我都不需要说）：假设

我在一家名为 504 Industries 的虚构公司工作，我的所有产品都会生成整数 504。我的旗舰产品叫做 Cruncher，每当我的客户运行它时，屏幕上就会打印出数字 504。

有一天，我让审计员检查源代码，发现它有一些技术债务。源代码如下所示： 113+412-(11+9+1)

这确实给出了正确的答案，但我发现很难吸引新人才到我的公司来处理这个源代码代码。我最初对 504 的设想非常简单，那么它是如何实现的呢？

多年来，我的开发人员可以自由地提出这个算法，而无需进行大量的设计监督，并且客户喜欢答案始终是 504。因此，我们不断赚钱，但创建新版本变得更加困难。

最后，我们决定重构我们的代码。因为113+412-(11+9+1)并不直观，而且我们知道原来有一个更简单的过程，我们可以通过一些仔细的发现来重新建立。

当我们的重构完成后，Cruncher 2.0 就准备好了，并且源代码更容易阅读：7*8*9。我们的招聘过程取得了成功，我们甚至创建了一家新公司 3024 Industries，该公司非常巧妙地重用了 504 Industries 的代码。 （我们使用 Cruncher 2.0 的解决方案作为库，将答案乘以 6，并得到我们的新产品 3024，您瞧。我们不需要再发明 7*8*9 代码时间；我们重用它以节省时间和金钱。这是可能的，因为我们可以将任何代码重构为可重用的库，这是今天重构的第二个例子）

正如我们所看到的，尽管我们有一个完全有效的产品，但维护成本却很高。原来是能够以可选的一次性固定工作主体的成本来减少。重构存在着我们可能会失败的风险，因此重构始终是必须谨慎评估的事件。

秉承“越差越好”的理念（或者说，现有且人们可以使用的平庸解决方案优于想象中的完美解决方案），如果我的开发人员愿意的话，我们 504 产品的原始版本实际上可能是更好的解决方案我们永远无法将 113+412-(11+9+1) 重构为 7*8*9。