Sharing code between projects
As developers, we often strive to follow the principle of “Don’t Repeat Yourself” (DRY) in our code. While this practice can lead to more maintainable and efficient software, it’s not always a straightforward task. In my experience, I’ve found that several techniques can help us avoid repetition and write better code. I’d like to share some of these methods with you today.
Just repeat yourself
When it comes to implementing a new feature in your project, sometimes the simplest approach is the best. In these cases, simply copying and pasting the code from one project to another can be the most efficient method. This approach works particularly well when you expect the two pieces of code to differ significantly from each other. By repeating yourself in this way, you can save time and effort compared to trying to rewrite the code from scratch.
Pros:
- Very easy to implement
- If the use cases start to differ from each other it is easy to update the functions
Cons:
- You will have to maintain the same code in multiple places
Create a package
Creating a package and sharing it in a distribution is one of the most common ways to share code. If you are working on open source I would say this comes with barely any downsides. However, if you need to work on closed-sourced software you first need to set up your own distribution in order to make this work.
Most developers have already worked with packages so working with your code as a package will be easy to adopt.
Pros:
- Almost every developer will be able to work with it
- The versioning of code is easy
Cons:
- Setting up an internal distribution for closed-sourced software
- Additional boilerplate code to turn your work into a package.
Git submodules
If you’re using Git for your source control, you can utilize Git submodules to add another repository as a folder within your current repository. This allows you to access the full repository of your project. To add a submodule, use git submodule add [GITURL]
.
When cloning a repo for the first time with a submodule, you’ll need to run git submodule update --init --recursive
to populate the submodule, otherwise, it will simply be an empty folder. The submodule will keep track of what commit and branch it is on.
However, in my experience, this solution can be less stable and requires more debugging. Additionally, you may need to explain it to colleagues since it’s not a common practice.
Pros:
- Lots of control of which version
- No additional infrastructure is needed besides git
Cons:
- It does not always work well, and to debug it you need some good git knowledge
- Who receives does need read access to your code to make it work
- Only works for code, not for compiled binaries
- All tests and developers code will also be in the repo
- You need to pull the latest version of the submodule to make sure you are in sync
Conclusion
There are multiple solutions for sharing code, and none of them are the best solution every time. Make sure you understand your situation and realize what will give you the least work in the future.