I saw a lot of discussions on how to improve the technical horizon on the Internet, but no one gave a definition. What exactly is a technical horizon?
The so-called technical perspective is the different angles (dimensions) that can be switched when looking at a problem.
The following takes API management tools (hereinafter referred to as “management tools”) as an example to explore the technical perspective hidden behind.
API management tools
The simplest management tool I’ve ever used in a small startup is an open source document management tool with an interface similar to a wiki (Wikipedia).
Such tools can indeed meet the core needs-API online documentation, and support user management.
But think deeply about it. For the user of the management tool-engineer, is the operation friendly enough and the functions complete enough?
Many times when using this type of management tool, the document is inconsistent with the code, which means that engineers are unwilling to maintain this document.
Because it is a time-consuming task to write and modify documents, in the short term, maintenance is neither profitable nor harmful.
So sometimes interface changes are negotiated verbally rather than through documents.
Summary: Zero perspectives is not a vision. It is the easiest way of thinking for most engineers. It is characterized by focusing only on the function/problem.
At that time, in order to solve the above problems, and at the same time to practice the Node.js I learned, I wrote the first version of the management tool and participated in offline salon sharing.
It seems that in fact, the original project was relatively rough. In addition to showing a more beautiful interface than the wiki, it mainly added the Mock function.
There are also many better open-source projects, such as Ali’s RAP and foreign APIDOC.
The reason why they are classified as a type of discussion is that they all reflect a single perspective of the developer.
RAP is typically developed from the perspective of a front-end engineer.
For example, in the first version, the interfaces were grouped by pages. This grouping is obviously unreasonable. What should I do if the service calls between the backends do not involve pages? So the second edition has modified this.
Another example is deep binding with MockJS, which provides Mock functionality for front-end engineers.
MockJS is really good. Not only does it support data simulation, it also supports data verification. The back end is also written in Node.js, which is familiar to front-end engineers.
The disadvantages are compared and analyzed later when talking about other management tools.
APIDOC is written from the perspective of a back-end engineer, adding the ability to generate documentation through code comments.
Summary: The establishment of a perspective means a qualitative change from 0 to 1, and a technical vision begins to form. Engineers in this field no longer focus on function implementation or problem solving.
Occasionally I read an article about contract testing by the great Martin Fowler. This article proposed an idea to verify the front-end and back-end through management tools to ensure the consistency of documents and code.
So the second version of the management tool was developed. This version is designed from both front and rear angles.
For the front end, not only Mock services are supported, but also the request parameters can be verified, and even the server responds abnormally.
For the back end, a similar postman debugging interface function is added. At the same time, because the JSON-Schema specification is used, the schema can be directly ported to the back end code as a verification rule to verify parameters. (The limitation of RAP is also here. MockJS verification can only be used on Node.js and browsers, and servers written in other languages cannot be used. At the same time, it is not as easy to use as a mock server for the backend Debug function.)
Of course, it still has some gaps with some well-known management tools Swagger and RAML. For example, the tool chain is not rich enough to generate code through comments.
Summary: The establishment of multi-view is a quantitative change from 1 to N, and this process needs to accumulate more experience, and eventually form a global perspective.
to sum up
It is often seen that when hiring senior front-end engineers, some companies will require mastering more than one back-end language, or mastering the back-end language as a plus. The real intention may not require front-end engineers to write back-end code, but master The front-end engineer of the back-end language will have one more dimension of thinking, which means that the technical vision is richer.
Many engineers think that the gap between themselves and the Great God is technology, but this gap is only appearance, and the actual gap is thinking mode and technical vision.
The technical vision is different. Even if you do the same thing, the achievements will be different. This is why I pay attention to help readers improve the technical vision when writing a book ~
If an engineer is always thinking about getting things done and solving problems from a zero perspective, he can only become an intermediate engineer at best.
Be able to think outside the matter and think from a reasonable angle, and you can reach the level of a senior engineer over a long period of time.