API technology vision document management tools reflects the

# What is the technical vision line to see a lot of discussion on how to enhance the technical vision, but no one gives definitions, in the end what is the technical vision? ** called technical field of view, is different angles (dimensions) can be viewed problem of handover. ** Here's to API management tool (hereinafter referred to as "Administrative Tools"), for example, to explore hidden behind the technology vision. # API ## to zero once the perspective of management tools in a small start-up companies had used the simplest management tools, is an open source document management tools, interface functions like wiki (Wikipedia). Such tools do not meet the core needs of --API online documentation and support for user management. But think deep layer for user management tools - engineers, operators and friendly enough, comprehensive enough? In many cases the use of such management tools will appear inconsistent documentation and code that case, that engineers are not willing to maintain this document. Because writing modify the document is time-consuming thing, in the short term, ** safeguard the interests of neither, no maintenance and no harm ~ ** So sometimes change the interface of negotiation rather than through verbal consultation document. > Summary: In fact, far from zero viewing angle field of view, is the way most engineers thought the most likely to form, the feature is only concerned with function / problem itself. ## single perspective at that time in order to solve the above problem, and in order to practice what they have learned Node.js hand, I wrote the first version of the management tool, and participated in the Salon share the line. In fact, it seems the original writing of the project is quite rough, in addition to showing the interface more beautiful than compared to the wiki, Mock joined the main function. Better, there are many open source projects, such as Ali `RAP` and abroad` APIDOC`. The reason why they are classified as a class discussion, it is because they embody a single developer's perspective. `RAP` is a typical front-end engineers stand point of view of development. For example, the first version of the page is the interface to be grouped, this grouping is clearly unreasonable, service calls between the rear end does not involve the page how to do it? Therefore, this second edition has been modified. Another example MockJS depth and bindings, providing Mock functionality for front-end engineers. MockJS really good, not only supports analog data, also supports data validation, the back end is the use of front-end engineers are familiar with Node. Write js. Comparative analysis again talking about other management tools disadvantages when it later. `APIDOC` is standing on the perspective of the back-end engineers to write, adding the ability to generate documents by code comments. > Summary: Building from the perspective of qualitative change means 0-1, technological vision began to form. This vision engineers no longer focus only on function implementation or problem solving. ## multiview happened to read an article Martin Fowler Great God on contract testing very enlightening, this paper presents a concept to be verified by the front and rear end management tools to guarantee consistent documentation and code. So the development of Version 2 of management tools. This version of the design while the rear end of the front two angles. Mock support not only to the front end service, while checking the request parameters, even in response to abnormal simulation server. A similar increase to the rear end postman debug interface function, because the use JSON-Schema specification, the schema can be directly transplanted to the back-end code as validation rules to validate parameters. ( `RAP` limitations also here, MockJS check only for Node.js and browser-side, server written in other languages ​​can not be used. At the same time for the back-end server is also not as good as Mock with debugging features.) of course, it and some well-known management tool `Swagger`,` RAML` still some gaps, such as tool chain rich enough, can not comment generate code. > Summary: establish a multi-perspective is from 1 to N, quantitative, and this process needs more experience, and ultimately the formation of a global vision. # Summary often see some companies in the recruitment of senior front-end engineers will be required to master the time after the end of more than one language or to master the language as a back-end bonus items, the real intention is not necessarily front-end engineers will be asked to write back-end code, but to master the language of the front-end back-end engineers will be more a thinking dimension, which is more abundant technical perspective. Many engineers think that the gap between themselves and God is great technology, but this gap is only appearance, but the gap is the essence of thinking and technology vision. Technical field of vision is not the same engineer, even doing the same thing, achievements will be different, which is why I will focus on helping readers improve the technology vision when writing the book ~ * an engineer to do things only if you always consider things complete, zero angle of view to solve the problem, can only become a mid-level engineers. * Be able to jump out of the thing itself, stood a reasonable point of view to think, for a long time accumulated will be able to reach the level of senior engineer. * Consider the circumstances surrounding the matter and a variety of relationships where the linkage system, already is field of vision of the architect.