Reuse and maintainability and ease of testing

Question

Everyone likes to talk about reusability. Where I work, whenever a new idea is thrown up or tested, the question of reuse always arises. "We want to maximize our investment in this, let them make it reusable." "Reuse will bring higher quality at lower cost." And so on and so forth.

I found that when a reusable component or idea is introduced, everyone is immediately afraid of it and writes it down as a bad idea. As soon as applications become dependent on them, they say that they will not be supported, and any changes will lead to the need for regression testing of everything that uses it. People here point to one component that has been around for a long time, and it has many dependents and grouse, which has become impossible to change because we do not know what will change.

My answers to this complaint:

• It’s good that changing a component that has many dependents is slow, because it makes designers really think through the changes.
• It takes time to get the component first. Corrolla: If you always find the need to change it, it has never been used very much, right?
• Software development is complex and requires work. So is testing. You just have to do it.

Unfortunately, what people hear in these answers is “slow,” “time,” and “effort.”

I would really like it if there was a magical “make this reusable” switch that I could flip over to the things that I collect in order to win brown points from the manual, but that's not it. Creating something reusable takes time and effort, and you still cannot guarantee that everything is correct.

How do you deal with a "reuse" request when delivered to it does not seem to cause anything but complaints?

Answer 1

• Reuse makes sense only if something is really reused. Make sure you have some practical reuse cases before you write something reusable.

• Even if a reusable library is 10 times harder to maintain than the special version itself, you still maintain the overall maintenance if the reuse library is used instead of ad-hoc versions in 10 different places.

Answer 2

One thing we often do is use versions and avoid constant re-testing. Just because there is a new version of regular code does not mean that everyone should immediately use the new version. When something is updated for other reasons, update the new version of the common code.

Answer 3

Repeatability is to make code reusable in terms of similar behavior or the IS_A relationship. If you just want to reuse a block of code, seeing them again and again, but they don’t have the same characteristic, it’s better to leave them alone to communicate freely. Thus, we can modify it more flexibly later.