2

I'm a contractor at a large Telco where I'm usually working on several different projects at once.

The VCSs I use (mainly git and mercurial) tend to make me keep the code bases for unrelated projects in separate repositories, and I realise many benefits of this approach.

However, there are many little bits of utility code and helper functions I've written which are useful across two or more projects, and I'm well aware of the benefits of keeping my code DRY - for example sometimes I find a better way to implement some piece of code and I don't want to have to update it in every place where I've duplicated the same idea.

What is the best way to refactor out this common functionality (it is not always so simple as copy-and-paste, but sometimes it is..) without creating unnecessary dependencies between unrelated projects, and without adding needless complexity?

Improve this question
1

2 Answers 2

Reset to default
5

Well, "little bits of utility code" are probably best not shared across unrelated projects. Just look at how many implementations of "Hello, World!" are out there. :-)

Seriously, DRY is not an absolute. There is a cost for searching for an existing solution and a relatively high maintenance cost for sharing library code across otherwise independent projects. One project wants to add functionality but another project doesn't, so what do you do? You fork it or add an option, and now you're not really sharing the code anymore. Or worse one project adds a feature but it breaks some other project. The more people use a library the harder it is to change.

You see a very big and practical example of this right now in the Ruby on Rails community. Projects rely on dozens of gems (hefty bits of utility code) and then they are afraid to update them because something will break because "improvements" in one library break the expectations of another. It's managed to a large degree with sensible version numbers that segregate changes by the likelihood of breaking existing code, but still, there's a lot of overhead to versioning and managing those version numbers, and it's just not worth it for 20 lines of code.

As a rule of thumb, if you're the first person to write it, it's not that useful. If Large Telco doesn't already have that functionality in the codebase such then no one else felt it was important. More likely, it's in there somewhere and you can't be bothered to find it because it's easier to just write it yourself. And you're probably right, but so are your colleagues who want to just write it themselves rather than go look for it.

In practice, the best advice I can give is to keep your own personal library of code snippets and carry them around with you. Copy and paste from other projects if you like. As long as the snippets are small and don't contain real secrets, like cryptographic keys or the formula for Coca-Cola, no one is going to bother you about taking code from one company to another let alone from one project to another.

And then when a colleague asks "hey, do you know a good way to do X" you can just copy and paste the code into an email or IM and be the hero of the hour.

Improve this answer
4

Factor the common stuff out into one or more libraries. Put the library in its own repo, and in the individual projects, add a bit of logic to your build script to make sure you have the correct version of the library. You may or may not fancy subrepos for this; matter of taste, really.

Improve this answer
2
  • 2
    without documentation, code examples and unit tests such libraries might do more harm than good (been pressed to use such a crappy "factored library" about a year ago, still suffering recalling pain we had trying to integrate it)
    – gnat
    May 21, 2013 at 8:31
  • If you don't have tests, you're doing it wrong regardless of whether you're writing a library. :)
    – Marnen Laibow-Koser
    Apr 13, 2018 at 3:11

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