重用与可维护性和易测性

Question

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

我发现，当引入可重用的组件或想法时，每个人都会立即害怕它并将其写下来作为一个坏主意。他们说，一旦应用程序依赖于应用程序，它将无法维护，任何更改都将导致需要对使用它的所有内容进行回归测试。这里的人们指的是一个特别是已经存在很长时间并且有很多家属和松鸡的组成部分，因为我们不知道这些变化将会发生什么变化，因此无法改变。

我对此投诉的回复是：

1. 改变组件是件好事 有很多家属很慢， 因为它迫使设计师 真的想一想这些变化。
2. 应该花时间来获得 组件就在第一位。 Corrollary：如果你发现需要一直改变它，那么从一开始就不会重复使用，是吗？
3. 软件开发很难，需要工作。测试也是如此。你必须这样做。

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

我很乐意，如果有一个神奇的“让这个可重复使用的”开关，我可以翻转我建立的东西，以便从管理层获得布朗尼积分，但事情不会这样。制作可重复使用的东西需要花费时间和精力，而你仍然无法保证能够做到正确。

在交付时，您如何处理“可重用性”请求似乎只会带来投诉？

Answer 1

1. 如果实际可以重复使用某些内容，那么可重用性是值得的。在编写可重用的内容之前，请确保您有一些实际的重用案例。

2. 即使可重用库比其自身的ad-hoc版本难以维护10倍，如果使用可重用库代替10个不同位置的临时版本，您仍然可以节省整体维护

Answer 2

可重用性是指使代码在类似行为或“IS_A”关系中可重用。如果您只是想通过一次又一次地使用它们来重用代码块，但它们没有相似的特性，那么最好不要让它们单独进行松散耦合。通过这种方式，我们可以更灵活地稍后进行修改。

Answer 3

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