DEV Community

loading...

Discussion on: The Demise of Reuse

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

I think generally a company is either in the business of making general purpose solutions (reusable code) or client solutions (non-reusable code). It's not really possible, probably not even recommended, to try and mix the two models within a company (or at least within a division).

Collapse
silwing profile image
Silwing

But even though you make client solutions you surely run into small scale situations where code reuse seems appropriate.
You don't want to make the same business validation rules in multiple places. Or maybe your client has multiple applications and you want a consistent user interface across the apps. That all leads to wanting to reuse code.
I feel the article has a good point though. Code which is reused a lot quickly becomes difficult to manage. Especially if you are missing automated testing to reassure you that nothing goes wrong when you refactor or change common code.

Collapse
rmorschel profile image
Robert Morschel Author

Reuse in a team is good, and cheap. Reuse across teams is hard. Reuse across the enterprise needs to be deliberated, and managed, and is costly.

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

I don't have a problem with reusing code so much as sharing code, that's when the problem starts. Each client should just get a fork of the code and then you start modifications. If a client wishes to upgrade their project you can look at merging in changes then. If they just need minor changes then you stick with the old version. That is, treat it like software with a distinct release for each client, and don't attempt to actually share one version of the code.