Design theory: Making documents for front-end development of web pages

The document developed on the front end believes that in most cases there is no backend service description detail, and most tests are only in black box testing, so there are many cases where the document is very.

Why front-end documents are missing

The document developed on the front end believes that in most cases there is no backend service description detail, and most tests are only in black box testing, so there are many cases where the document is very.

* Front-End development of code decentralization-no normalization, no good design, most people still in the business-oriented development approach.
* Testers are still in black box testing on the front end, and there are no documents that affect their test process.
* Once the business stereotypes, the traditional way of document mode, it is difficult to copy to the front-end development. --changing the way of development (from workshop to normalization) makes it difficult to adapt.

Try the right remedy

Questions about code fragmentation need to be addressed from the source. Starting from the standardization, the pilot used to wear standardized, mandatory conventions, to improve the quality of code.
This piece needs to vigorously gas, the middle joins the design Review, the code review and so on link. Attention is the granularity of control, that is, what is necessary, what is optional, what is agreed to and so there is consensus.

* Functional Description-pre-development work, for the coder must collect requirements. For the user, you can know what the purpose of writing the code is, what the problem is, what problems have not been resolved, or need to improve.
* Design Description-Share your thoughts, it is important that a mature developer to look at the code often is not to see how you achieve, but to see your design.
* API Description-users to quickly start. Interface is the eye of the code. The name should be rigorous, can not say that can be so, but also that. Experience tells us that the interface does not do well, historical reasons will be more.
* demo/snippets--to the use of the people copy/paste nothing bad.
* Use guidelines-for example, manuals for library usage guidelines. Or a simple hands-on tutorial,

Who should write the document?

In theory, documents should be written by coders, but they are not. The cycle of a software can be divided into: before development, development, when used, when testing, maintenance.
Then there should be different people to take part in each time period. To narrow down the scope, you should see

* Pre-development collection needs to be attended by everyone. The implementation is collected and archived in the document. This is for development purposes and expectations.
* Development of the API description, design description is mainly by the coder to implement.
* After development/maintenance of the demo and snippets can be improved by the user.

is the design document automated to generate

Code comments (now commonly used in Java DOC) can generate interface documents.
In the past, you must draw your own design drawings, with a description. So theoretically this piece should also be able to add the design description through the annotation, automatically generate the design drawing through the tool of the document generation. This should be more convenient.