什么时候反思不再值得呢？

Question

我刚刚使用反射来重构一个脚本，其中包含大约十二个，几乎相同的单行，一个使用反射将静态方法动态绑定到类。

重构版本can be found here。 并before refactoring here。

我的问题是：这看起来过于设计吗？我是否在追逐一些实际的学术优雅，比明显的方式更糟糕？重构的形式更短（约70行），更“美丽”（对于一些定义的美的概念），但新手程序员可能根本不理解它。

Answer 1

“天真”方法的一个问题是可维护性 - 您有12倍的维护，调试和测试方法。想象一下，你需要为它们添加一个额外的参数......随着时间的推移，方法将变得非常相似但不完全相同。因此，“复杂”的方法可能会随着时间的推移而获益。

顺便说一下，28个“幼稚”方法中的一个有一个错误，其余的27个都没有出现:)

Answer 2

代码应该易于阅读并且易于编写（unbuggy）。简短的一个很容易写，更难理解。

如果你必须选择一个，我会选择较短的一个，因为它不太可能发现错误。在很大程度上评论它是如何工作的，也许是关于它应该返回的例子。如果可能，尽量减少重复。

Answer 3

通常我会避免回答这些问题，因为我在你提到的新手级别的低端，但是因为你提到它......：）

我发现更多＆＃39;工程＆＃39;版本更容易消化，特别是因为它提到的单行更少。理解第二版中发生的事情的概念性飞跃只需要像我这样的人（再次，超级新手），但一旦这部分渗入，设计的相对简洁/优雅（以及更明显的分组）要宣传的方法远远超过理解这个概念的任何额外时间。

同样，我的意见是最后一个真正重要的，但如果我发现自己正在阅读其他人的代码（或我自己的代码），并且经过一分钟的思考，那么，现在这是一个好方法做事＆＃34; （而不是＆＃34;好吧，现在当我写这篇文章的时候我在想什么呢？它又如何运作？＆＃34;），我觉得它是在正确的位置（这是我与你的结束） 。

Answer 4

我的意见是，保持代码尽可能简单和直接。这意味着新手和专家都应该理解这一点。

如果您的代码保持到点，即使是新手或中级程序员也很容易修改和扩展。修改能力演变了“解决方案”。一个进化的解决方案是一个很好的解决方案的例子:-)。

顺便说一句，我认为这个问题属于Code Review.SE，但我可能错了。

Answer 5