重用与可维护性和易于测试
每个人都喜欢谈论可重用性。在我工作的地方，每当一些新想法被提出或测试时，可重用性的问题总是会出现。 “我们希望最大化我们在这方面的投资，让我们让它可重复使用。” “可重用性将以更少的工作带来更高的质量。”等等等等。
我发现，当一个可重用的组件或想法被引入时，每个人都会立即害怕它，并将其视为一个坏主意。他们说，一旦应用程序变得依赖于它，它将无法维护，并且任何更改都将导致需要对使用它的所有内容进行回归测试。这里的人们特别指出了一个已经存在很长时间并且有很多依赖者和抱怨的组件，它变得不可能改变，因为我们不知道这些改变会破坏什么。
我对此投诉的回应是：
- 改个组件就好了 有很多家属的速度很慢， 因为它迫使设计师 认真思考这些变化。
- 应该花时间来获得 组件放在第一位。推论：如果您发现需要一直更改它，那么它从一开始就不太可重用，不是吗？
- 软件开发很困难，需要工作。测试也是如此。你必须这么做。
不幸的是，人们在这些回答中听到的是“慢”、“时间”和“努力”。
如果有一个神奇的“使其可重复使用”开关，我会很高兴，我可以打开我构建的东西，以便从管理层那里赢得奖励积分，但事情并非如此。使某些东西可重复使用需要时间和精力，而且您仍然不能保证它是正确的。
当“可重用性”的交付似乎除了抱怨之外什么也没有带来时，你如何处理“可重用性”的要求？
Everyone likes to talk about reusability. Where I work, whenever some new idea is being tossed around or tested out, the question of reusability always comes up. "We want to maximize our investment in this, let's make it reusable." "Reusability will bring higher quality with less work." And so on and so on.
What I've found is that when a reusable component or idea is introduced, everyone is immediately afraid of it and writes it off as a bad idea. Once applications become dependent on it, they say, it won't be maintainable, and any changes will result in the need to do regression testing on everything that uses it. People here point to one component in particular that has been around a long time and has a whole lot of dependents and grouse that it's become impossible to change becuase we don't know what the changes will break.
My responses to this complaint are:
- It's good that change to a component
that has many dependents is slow,
because it forces the designers to
really think through the changes. - Time should be taken to get the
component right in the first place. Corrollary: If you're finding the need to change it all the time, it was never very reusable to begin with, was it? - Software development is hard and requires work. So does testing. You just gotta do it.
Unfortunately, what people hear in these responses are "slow," "time" and "effort."
I would love if there was a magic "make this reusable" switch I could flip on things I build so as to win brownie points from management, but things don't work that way. Making something reusable takes time and effort and you're still not guaranteed to get it right.
How do you deal with the request for "reusability" when delivering on it seems to bring nothing but complaints?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只有当某些东西真正被重用时，可重用性才有价值。在编写可重用的东西之前，请确保您有一些实际的重用案例。
即使可重用库的维护难度比其本身的临时版本高 10 倍，如果在 10 个不同的地方使用可重用库代替临时版本，您仍然可以节省总体维护成本。
Reusability is only worthwhile if something will actually be reused. Make sure you have some practical reuse cases before you write something reusable.
Even if a reusable library is 10x harder to maintain than an ad-hoc version of itself, you're still saving on maintenance overall if the reusable library is used in place of ad-hoc versions in 10 different places.
可重用性是指使代码在类似行为或“IS_A”关系方面可重用。如果您只是想通过一次又一次地使用代码块来重用它们，但它们没有相似的特征，那么您最好让它们保持松散耦合。这样，我们以后修改时就可以有更大的灵活性。
Reusability is to make code reusable in term of similar behavior or "IS_A" relationship. If you just want to reuse code block by seeing them using again and again but they have no similar characteristic, you should better leave them alone to be loosely coupling. By that, we can have more flexibility to modify later.
我们经常做的一件事是使用版本并避免不断的重新测试。仅仅因为通用代码有新版本并不意味着所有内容都必须立即使用新版本。当某些内容因其他原因而更新时，请更新到新版本的公共代码。
One thing that we often do is to use versions and avoid the constant retesting. Just because there is a new version of common code doesn't mean everything has to use the new version right away. When something is getting updated for other reasons, update to the new version of the common code.