We have a website with a lot of functionality, and we now start another one, which should have a lot of common code with the first one.

What would be the best approach to avoid code duplication?

Possible solutions we consider:

  • put these projects within one parent directory (but in separate git repositories), and just use components of the first project from the second one
  • move common functionality to separate repository (this would require for us the rewrite a lot of code)
  • just copy code from one project to another
  • do everything inside one directory and check Host http-header to separate logic for each site
  • (maybe there are other variants)

What are the best practices for this situation?

  • 4
    Either way you slice it, this is going to be a big rewrite, since you're basically going from maintaining a "website" project to a "website generator/template" project. Refactoring will almost certainly eventually pay off, but up-front cost will be higher than usual with refactoring questions. Therefore the question what is right for you in this situation depends much more on your organisational set-up than on details of the project, and will be hard to answer in this format. Dec 14, 2018 at 10:08
  • You have to do it at least three times before you really know where to place the API cuts. So, resist the urge to create libraries until you reach the fourth website. Feb 28, 2023 at 19:46

2 Answers 2


Best practice is to put your common code in a library, compile it and distribute the binary to both projects via a package manager.

However, If the first website is end of life, you probably dont want to change it. Just copy the code across to libraries so that you can reuse them properly next time around


First of all, code duplication is not as bad as most of us engineers think. I've seen more damage done by creating abstractions and frameworks enabling reuse than from real duplication.

Not all code is equal and I'd review the code and focus only on the parts that have potential for business-harming bugs and security issues. Anything else that's scaffolding or relevantly trivial I'd leave as-is.

The language and build pipeline you use will inform if it's better to create library or have shared repo.

If using library keep in mind there will be version drift — not all projects will be using the same version all the time. This may or may not create host of new problems, depends on the type of software we have.

  • Too true! While in most cases its good to have common libraries for frequently used functions sometimes the effort involved in making a function handle every edge case in every project just creates an un-maintainable mess Dec 19, 2018 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.