There are always some methods, classes or helpers you don’t find in your programming language, which would be useful to save boilerplate code or needed a lot in your programme. Now you are confronted to decided whether you implement this particular function yourself ( do-it-yourself ) or use a third party library ( don’t-repeat-yourself). I sometimes have awesome discussions with my boss, which approach we should use. The following is a comparison of both approaches with pros and coins.
DRY | Don’t-Repeat-Yourself
The main question is, why should I invent the wheel again. There are a lot of good libraries out there like Google Guava, Apache Commons and many others for more specialized use cases. Before taking a closer look to the library, we consider the following points
- When was the last source code update? Is the libary still maintained?
- Are there documentations and examples how to use the library
- Is there any kind of community
This part of a list described on Java Code Geeks. If we cannot satisfy at least 2 of the 3 points, we won’t choose the library and look for a different one. Now we would take a closer look at our library, read tutorials and the documentation and use the one function we where missing in our current library/language set. Often we do this by writing tests assuring the library does what we want it to do. This is crucial as if you update the library all your functions will be tested. Joda Datetime for example implements some RFC standards, which is pretty awesome. However you have to read the RFC to know exactly what is going on or you just test the methods you need.
Lets summairze the benefits from using a third party library
- Less development time
- Pretested functionality
- Less maintainance support
DIY | Do-It-Yourself
Sometimes you just need this one little method. However it shippes with a big library with features you never even heard of. This library satisfies every standard you set, but it is too big (no matter if you mean size, features or maintaince overhead). Even if the library isn’t too big, maybe you just don’t like it in case of API or code style. So you start to write it yourself and it will be part of your product.
Summarize
[table colwidth=“100|100|100|200″]Task, DRY,DIY,Description
Development,Learn the API, Write API, The more complex the library and the worse the documentation the harder it’s to learn an API than to write your own
Tests, Test library API you use, Test your own Implementation, Always need them
Maintainance, Community Support, Alone, When you use an 3. party open source library you should give something back
Happiness, a bit, even more, „Developers are lazy, but they don’t want to read API docs. Writing code on their own makes them even more happy *sigh*“
[/table]