Do I need to read the code of the libraries used?

What a great time we live! Here you write the program and you need a library for something - it will definitely be found! Many libraries are in the opensource and even distributed under pleasant licenses such as the LGPL, picked up - and solved the problem. Delov something: the connection method is described in the readme, the library provides beautiful interfaces, there is a demo (it even compiles and works). In general, OOP with all its ideas of abstractions, interfaces, encapsulation of internal data is the most powerful thing ( here without irony ).



But let's think about where and when the "abstraction" begins. Here, for example, I have a car in which I go to the supermarket once a week. In this case, for me, it’s quite an abstraction of the “steering wheel, three pedals and a pair of levers” level, providing the functionality I need. And I can use it for many years, without really thinking about what is under the hood - the engine or the magic gnomes, for some reason, drinking gasoline and spinning wheels. But if I work as a car mechanic, car designer, or simply as a professional driver, I can’t afford to look at the car so "down", knowing its internal structure is my job. A buyer of milk in a store may never even see a live cow in his life, but the farmer who grows this cow simply has to know everything about her health / maintenance / nutrition / care / milking. Well, etc. There is a clear separation into the “users” of the product and its “creators”. The first can afford not to think about the details, the second - no.





If you have read this far up to this place, you are most likely a programmer. Once again, you are a person who professionally develops computer programs. Which, probably, is responsible for the work and, probably, considers itself as the quite good expert. And you consider it possible to take someone else's library and, having read it at the level of its interface, use it in your product?



')

Ambiguous behavior

Let's imagine an interface of such an abstract library in an unidentified language:

interface IInterface { bool Init(); int Calculate(int val); void Release(); } 

Everything is clear, right? We call Init (), then we transfer something to Calculate (), we get the answer, we call Release ().



Elementary? Do not hurry. Answer what will happen if:

1. Call Init () twice? And 1000 times?
2. Call Calculate () without calling Init ()?
3. Do not call release ()? And if you call twice? And if 1000 times? And if before calling Init ()?
4. Call Init (), Calculate (), Release () from different threads?
5. What is the val argument range in general? Whole int? And exactly? And 0 too? And MIN_INT and MAX_INT?
6. And then there are some exceptions?
7. And then some logs are written? Is it somehow configurable?

well, etc.



You will say that these things should be described in the documentation? Yes, it should be. But, firstly, this is not always the case. And secondly, the documentation is a set of letters that are not parsed by the compiler, are not executed at runtime, and cannot be automatically verified by anyone. There may be truth. And maybe the result of knocking a typewriter of monkeys on a typewriter. Or the weather on Mars. Developers do not like to write documentation and even less like to update it. Get over it. Well, or read, finally, the library code.

Library Purpose

So, you have found a function in the library that does "what I need". Do not hurry. You do not know why and how its creator wrote it. No one guarantees that it will work on everything you need input data, on all the platforms you need, with the performance you need, without side effects. At the moment, all you have is the name of the function and a couple of words from a person whom you have never personally seen, with the promise of assuming that everything will be fine.

Tests

There immediately a whole set of nuances. If there are tests in the library - it says a lot, you can read them, start them up, this will significantly add insight into how this library can \ be used. For example, I have repeatedly seen in the tests the lines “TODO: ...”, “possible bug”, commented pieces of tests marked “uncomment after the implementation of the functional”, etc. Even the most elementary test may suddenly find, for example, that the author expects a temperature in Kelvin at the function input, although you were 100% sure that it should be in Celsius.



If there are no tests, this also speaks volumes (first of all, that it would be better to look for another library). Perhaps they should write their own. Or perhaps the library says it is very difficult to write them - then there can be problems using the library.

Qualification library creator

There are exactly two options. With high probability, the creator of the library had a higher qualification than you in the field of problems solved by the library. Well, he would hardly have otherwise decided to write the library. This is quite a significant reason to read its code - perhaps you will learn something, maybe the code shows some “pitfalls” of the problem being solved, which you would like to know or offer even better solutions than you expected. In any case, it is always useful to read the code of a good specialist.



The second (less common) case is when the creator of the library is qualified lower than you. First, it would be good to understand it (and how to do it without reading the code?). Secondly, here, after all, how is the chain - the quality of your product will be no higher than the quality of its worst components, and here you consciously want to create a problem for yourself out of the blue?

Negligence

You do not know how strong the person who wrote the library wanted to make it qualitative. Perhaps he spent an extra hundred hours to “polish” the code, or maybe this library was his last product at a previous job, written during the “last two weeks” before leaving the hated employer. You can imagine how different the quality of the code can be in the first and second cases?

Evil intent

We all know the story of the recent bookmarking of the NSA in the random number generator. Well, about the rumors (or not the rumors) about $ 10 million for this business is also in the know. People are very skeptical and suspicious in everyday life, but in terms of trust in software (and even free software!) They take on completely opposite positions.

Tell me who your friend is and I will tell you who you are

The same is true for the relationship of the product with its libraries. If the library has a bug, it will be in your product. Is there a memory leak in the library? No, now it's a memory leak in your product. Lock? Performance problems? Undefined behavior? Get it, sign it.

Conclusion

Abstraction is not when you do not understand the internal structure of something, it is when you are sure of it so much that you can afford not to think about it.