DEV Community

Cover image for Sharing code between projects
Tom Nijhof
Tom Nijhof

Posted on

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 [URL2GITREPO].
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

An example of ai-writer-assistant.github.io added as a submodule to a project

An example of ai-writer-assistant.github.io added as a submodule to a project

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.

Top comments (0)