I constantly find myself thinking about code reuse when starting a new project.
To what extent should I make my code reusable?
Should I limit it to the application scope or should I make it reusable outside of the project?
Sometimes, I feel like code reusability may stand in the way of a simple design. Please, share your own understanding and approach of code re-usability.
1
The code has to work before it can be reused. So that implies design and (primary) function should come before consideration of code reuse.
It’s good to be thinking of reuse, and reusing components you’ve already written. But it can sometimes be just as fast, if not faster, just to write the code and get it working. After you have solved the original problem, you can refactor the code to make it more reusable.
2
Remember the KISS and YAGNI:
Code re-usability better to be considered once you have your design document ready. This will allow you to see the section/parts of code that are going to be potentially duplicated.
Thus, when you don’t have clear design then apply KISS and YAGNI approach in your work !
This is from my experience, but still believe it can be applied and goes along the lines of what GlenH7 mentioned.
I work between 3 companies doing various projects. The companies are sisters of each other with some standard practices and work methodology, but are also unique in a lot of ways. With that said, I generally begin each project fresh and want to just get it done or show progress. Then if I run in to a scenario where I remember a piece of code or functionality that I wrote for a previous project, I’ll do one of two things (time dependent):
- Fastest Method
Copy the previous code from the the other project (don’t have a lot of time) in to my current project. -
Second-Fastest Method
Copy the previous code and place it in to a common library, then include that library in the current project (to make moving forward easier).2b. If I make changes to the other (original) project, I’ll refactor it to use the new library [but generally won’t do so unless I have to re-touch that project].
Just be warned, test the heck out of the common libraries. Common libraries mean creating dependencies. Dependencies create points of failure. Although you may need something tweaked slightly for your current implementation, you don’t know how it will change anything else using that library.
2
Sometimes I find that copy & pasting few lines of code is a better solution. Even in human language, when you wanna say a sentence you said before just with a slight variation, you’ll repeat it with the variation, because it makes less trouble for anyone.
However, if your large module needs to be used in a slightly different way that it doesn’t support, don’t clone it just to modify few lines because it’s very probable that you will want to extend the functionality that both the base and the clone share in the future. Instead, just make it configurable or export the functionality that both the base and the clone share into another module that they will both use.
Don’t overdo it. And if you’re not sure, stick to application scope until you’ve written enough projects to see where you can reuse what.