Is the adviser competent? Problems recommendations “do not reinvent the wheel”
Quite often you have to meet the recommendation "do not reinvent the wheel." Sometimes with pronounced neglect and self-affirmation, sometimes, ostensibly , as good advice. However, even if it was called to be good-natured advice, in a number of contexts it only shows the incompetence of the speaker.
The nested purpose of the phrase is to save you from the useless work, the call to use a ready-made solution for the task, and from the point of view of an outside observer, it really looks reasonable.
But at the same time, a key factor that is characteristic not only for software development, but also for solving any problems is missed : when changing the context in which the task is set, the solution also changes .
To lose sight of this principle is the same as admitting to your own inability to solve applied problems.
Consider a few cases.
API over API
One of the common cases of accusations of cycling is the self-writing API wrapper of some service, the implementation of which is already available.
A case from my practice.
It was necessary to implement the upload of data from Facebook to our service. The mainstream language and the library from Facebook itself got googled in 2 minutes.
The library documentation did not correspond to the current program interface , a lot of unnecessary actions were wrapped around each manipulation. The library turned out to be of very poor quality .
Result: after 1.5 hours of working with it, it was not even possible to log in.
A colleague implemented his own wrapper of the web-api facebook. In total, it took him about an hour to create a wrapper and related functionality on the side of the service. To the question "why are you cycling here," he answered the next few days.
This is especially evident in mainstream languages with a large community: there is an unhealthy tendency to publish API wrappers over another API under the slogans "For humans" and "In a simple way". Such wrappers become obsolete as soon as the wrapped interface is updated, and the authors abandon such "projects", making the code that uses them inoperative.
A good question : and what, each time to write such wrappers manually?
Answer: A much stronger solution for large wrappers would be to use a code generator that interprets the specifications.
Control over the code base and refusal to answer for the mistakes of others
In wannabe circles in the development of computer games, this phrase is addressed to anyone who dares to implement their engine. "Why reinvent the wheel? Take unity!" . Or Game Maker, or, God forbid, Defold.
It would seem that the dviglo \ constructor provides all the necessary tools for development. Many of them are cross-platform and generally simplify life.
How should the context change here so that it becomes necessary to create your own engine?
At a minimum, this is control over the code base and engine functions (for example, on a number of controller models the game maker is consistently buggy, and fixing this can be extremely problematic). That is, it is necessary to reduce the likelihood of encountering a “foreign bug” , which is either impossible or extremely difficult to fix on its own.
This is especially pronounced in games that are not saturated with graphic and / or physical bells and whistles - banal, not so much the conditional engine takes on itself.
In addition, there is no need to increase the total amount of the code base if a small part of its functions is used from the engine / constructor , and all the necessary tools need to be added independently , simultaneously controlling the correctness of their work with the engine.
For example, based on such premises, Tommy Refenes wrote his own engine for Super Meat Boy .
Someone will object: "But in the storehouse \ some other storage, there is a mountain of presets \ tools \ extensions!" .
Yes, it’s wonderful, and gives a couple of points ahead, but in engines with a large active user base, the same “die young” effect described in the previous section is quite observed. Without context and a specific task, it cannot be unequivocally asserted that, de, the abundance of user extensions in the store will play into the hands.
Imaginary identity. Pulling the task by the ears.
Sometimes, having formulated the problem, it turns out that existing solutions that come to mind ... are not suitable. Due to its "fat content" or the dissatisfaction of one of the key conditions of the task ( yes, there are several ).
Good example: CluNet.
Cluster in his article quite fully described the reasons for the decisions made by him when developing the smart home protocol. The example is very revealing and well described, I recommend to disassemble it yourself.
Output
When searching for a solution to a problem , the context and all given conditions must be considered .
Even in simple cases, small details of the context turn the solution upside down, and the skill of solving applied problems is largely based on the ability to see and evaluate the initial premises .
So does the phrase “do not reinvent the wheel” say about the adviser's inability to solve problems? If the adviser mentioned the bikes before thinking it through a few minutes, most likely yes.
Or, in captain's generalization:
Think Before You Decide.
Think before you speak.
And in general - think.