Thinking when introducing a new library
This article is the 17th day of 2019 New Graduate Engineer Advent Calendar 2019.
TL;DR --Let's see if it can be solved without the library --If you can't solve it, first look for it in the installed library. ――It may be a bad idea to immediately introduce the library that came out in the search. ――If you want to introduce it, choose a library based on the criteria.
Preface
I started working as an engineer on October 1, 2018. I'm a 19-year-old person, so I'll post it on this Advent calendar.
In this article, I will summarize the "ideas when introducing a new library" that I gained during development for over a year.
I will aim for general content as much as possible, but the language is Java / Kotlin (= JVM system), use ʻIntellij system ʻIDE, and use some framework (eg SpringBoot). I will write on the premise.
Also, since this article is a conclusion drawn from my own experience, please comment if you have any opinions.
Think if you need to look
The first is the decision to look for someone else's implementation or write it by hand. If I am stuck in the following three points, I try to find another person's implementation.
--Easy and its implementation can appear in large numbers in the project (= you can expect someone to make ʻUtil`) --A solid standard has been set for the process you want to do (= easy to create a library) ――It's a pain to write by yourself (= ~~ I don't want to work ~~)
Check if the library needs to be installed
If I decide to look for someone else's implementation, I try to see if I need to install the library next.
Check if it is in the function attached to the language
You should look for the features that accompany the language (standard library) first.
The functions that accompany the language are extremely stable and reliable, and there are almost no situations in which they cannot be used.
Also, especially in Java, various functions are defined under the java package, so there are many situations where it can be used.
However, considering the situation, it will be necessary to make an appropriate decision such as "You can do it without installing the library, but you dare to install it" (eg "Java8-> Java11` has packages that disappear, so there are packages that disappear". Making updates easier by using a library ").
Search from the installed library
If you come to the conclusion that it is not among the features that come with the language, then it's a good idea to look for the feature in the libraries you have installed. The reasons are the following three points.
- The project should be close to the minimum configuration
- The library itself and the dependencies it uses are considered reliable (especially the libraries that the framework depends on).
- Even useful libraries do not always come out by searching
As for 1, I experienced a situation where something changes depending on the compatibility between dependencies, so in order to avoid such deep troubles, I do not introduce anything new as much as possible, and the one closer to the minimum configuration is in the state The idea is that it is better to finish it.
The second is that the framework has so many features that it can be reused in some situations, or the libraries that the framework depends on may contain useful ones. Also, since it is unlikely that the framework will change and the libraries that the framework depends on will change, it is considered safe to use the features contained within it.
Regarding 3, there were occasional occasions when I regretted the information that came out even after searching, such as being out of date or not being the best, so it would be better to look inside my project first. Because it's easy. In an extreme example, there was a scene such as "Although it is a library that is adopted by a super famous framework and is actually useful, it does not appear even if you search for it. Qiita has only 4 articles."
How to find
Even if you say "it may be usable", it is inefficient to read the full source code or search for all the dependent packages, so it is recommended to use the search function of ʻIDE`. I will.
As an example, in the ʻIntellij series ʻIDE, you can perform an ambiguous search from the entire project by pressing Shift twice.
At this time, by checking ʻinclude non-project items`, you can also search from dependent packages.
The image is the result of actually doing an ambiguous search with an appropriate word. You can see that the contents of various packages have been extracted.
If you can't find it, it's a good idea to try searching by introducing the vocabulary that came up by google.
Which dependency is appropriate to install the library from
There is also a scene where "when I searched for it, there were equivalent implementations in multiple libraries". In such cases, I choose the following priorities.
- Included in the framework body
- Related to framework dependencies
- Less likely to throw away the library
Find / select a library
If you haven't found it so far, consider installing a new library.
In most cases, you will find a library that you can use at the time of your search. However, I think you should carefully decide whether to install the library.
After confirming that it is published on Maven Central etc., I check at least the following 3 points [^ doc] before installing the library.
--License
- Usage situation --Maintenance status
[^ doc]: The richness of the documentation may be an important factor, but I'm ignoring it because there are probably other documentation if you can find it by searching. In addition, in my case, I can manage by searching for ʻidea` and reading the code by myself, so I don't have much trouble because I don't have the documentation.
license
First, about the library license.
Some licenses require the release of software source code using that library. Regardless of whether you understand and accept that obligation, it is not a good idea for commercial software to be suddenly required to publish the entire source code.
To avoid such unnecessary risks, you should check the license first.
Articles that I used as a reference
Usage situation
Next is the usage status of the library.
No matter how useful a library may seem, if the library is underused or has a short history, you can expect bugs and sudden drastic changes. Therefore, if you want stability, you should not use a library whose usage status cannot be confirmed.
Confirmation method
As an example, here's how to check from the Maven library page.
You can check the history of the library from Date, how much the project is used from ʻUsages, and from which project it is used. The image is the result of a library called ʻunbescape.
You can see that it has a long history and is used by well-known frameworks like Thymeleaf.
Maintenance status
Some libraries may not be currently maintained. You should avoid using such libraries as they may not fix bugs or leave vulnerabilities untouched.
Also, libraries that are developed by individuals have the risk of not knowing when the update will stop, and sudden drastic changes will occur with the update, so it is safe to avoid this as well.
Vulnerability
Libraries are often vulnerable, and some can have a number of serious vulnerabilities in a few months (e.g. Jackson).
If the library you are using is found to be seriously vulnerable and it is not easy to fix it, you will have to put a lot of effort into discarding it somewhere.
To avoid this situation, I think that you should choose a library with good maintenance.
(Bonus) Recommended library
Although it is limited to JVM, if you cannot find a library that can meet the criteria so far, or if you find more than one and get lost, we recommend the ʻapache type library. There are various libraries such as ʻapache commons, and all the items introduced so far are satisfied.
Summary
In this article, I have summarized the ideas for introducing a new library.
I wrote it in a mess, but in summary, it means, "Let's search from a place where there is a low probability that the situation of" I want to change this "will occur later."
It may be an exaggeration, but if you introduce something new, it's best to judge whether it will survive in a span of 3 years and 4 years. The more important and difficult to replace, the more carefully the risk should be judged.
I feel like I've lost my hold, but I hope this article has helped you.
Recommended Posts