reusability - 重用与可维护性和易于测试

Question

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

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

我对这个投诉的回应是：

1. 对具有许多依赖项的组件进行更改缓慢是件好事，因为它迫使设计人员真正考虑更改。
2. 首先应该花时间让组件正确。推论：如果您发现需要一直更改它，那么它从一开始就不是非常可重用的，是吗？
3. 软件开发很困难，需要工作。测试也是如此。你只需要这样做。

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

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

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

Answer 1

1. 只有当某些东西真正被重用时，可重用性才有价值。在编写可重用的东西之前，请确保您有一些实际的重用案例。

2. 即使可重用库的维护难度是其自身的 ad-hoc 版本的 10 倍，如果在 10 个不同的地方使用可重用库代替 ad-hoc 版本，您仍然可以节省总体维护成本。

Answer 2

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

Answer 3

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