重用与可维护性和易于测试答案

【问题标题】：Reuse vs. maintainability and ease of testing重用与可维护性和易于测试
【发布时间】：2011-02-21 00:30:00
【问题描述】：

每个人都喜欢谈论可重用性。在我工作的地方，每当有一些新想法被抛出或测试时，可重用性的问题总是会出现。 “我们希望最大化我们在这方面的投资，让它可重复使用。” “可重用性将以更少的工作带来更高的质量。”以此类推。

我发现，当一个可重用的组件或想法被引入时，每个人都会立即害怕它，并认为它是一个坏主意。他们说，一旦应用程序依赖它，它就无法维护，任何更改都将导致需要对使用它的所有东西进行回归测试。这里的人们特别指出了一个组件，它已经存在了很长时间并且有很多依赖项和抱怨，因为我们不知道这些更改会破坏什么，所以它变得不可能改变。

我对此投诉的回应是：

改成组件就好了有很多家属很慢，因为它迫使设计师认真考虑这些变化。
应该花时间来获得首先是组件。推论：如果您发现需要一直更改它，那么它一开始就不是非常可重用的，是吗？
软件开发很难，需要工作。测试也是如此。你必须这样做。

不幸的是，人们在这些回答中听到的是“缓慢”、“时间”和“努力”。

如果有一个神奇的“使这个可重复使用”的开关我可以翻转我构建的东西以便从管理层赢得布朗尼积分，我会很高兴，但事情不是这样工作的。制作可重复使用的东西需要时间和精力，但仍不能保证一定能做好。

当交付它似乎只会带来抱怨时，您如何处理“可重用性”请求？

【问题讨论】：

标签： reusability regression-testing

【解决方案1】：

我们经常做的一件事是使用版本并避免不断的重新测试。仅仅因为有新版本的通用代码并不意味着一切都必须立即使用新版本。当由于其他原因更新某些内容时，请更新到新版本的通用代码。

【讨论】：

【解决方案2】：

只有当某些东西真正被重用时，重用性才有价值。在编写可重用的东西之前，请确保您有一些实际的重用案例。
即使可重用库的维护难度是其自身的 ad-hoc 版本的 10 倍，如果在 10 个不同的地方使用可重用库代替 ad-hoc 版本，您仍然可以节省总体维护成本.

【讨论】：

【解决方案3】：

可重用性是使代码在类似行为或“IS_A”关系方面可重用。如果您只是想通过反复使用代码块来重用代码块，但它们没有相似的特性，您最好不要管它们，以保持松散耦合。这样，我们以后可以更灵活地进行修改。

【讨论】：