Mythical man-month-another aspect

The last chapter is still about the validity of documents and documents. At the beginning, I pointed out that I had worked very diligently to give my software engineers many years of lectures on document necessity and characteristics of outstanding documents, telling them-or even admonishing them with enthusiasm. However, none of these will work. I think they know how to write documents correctly, but lack enthusiasm for work. Therefore, this chapter focuses on how to write documents and what core elements should the documents contain.

Different users need different levels of documents. Some users only occasionally useProgram, Some users must rely on the program, and some users must modify the program according to changes in the environment and purpose.The document section describes how to write documents from three aspects: Application Use, verification, and modification.Which core elements should be included in the document content. Before writing a program, you must clearly describe the program's purpose, scope, scenario, input, output, and other important content. Each released program requires additional verification instructions, that is, preparing the test cases that we often perform. This occurs during the verification test phase. Finally, you need more information to adjust the program or repair program. Obviously, this requires an understanding of all the details, and these details have been recorded in a well-Annotated list.

Flowcharts are the most popular program documentation. In fact, many programs do not even need flowcharts, and few require a single page of flowcharts. In reality, Flowcharts are much more publicized than they actually do.I have never seen an experienced programmer who routinely draws detailed flowcharts before getting started with programming. In some organizations that require flowcharts, Flowcharts are always completed after the event.(Here we need to emphasize that flowcharts and various formal expressions should be applied in the conception and pre-requirement stages, when it comes to the design and development stage, complicated and complete Flowcharts are often not required .)

finally, I talked about the self-document program. What does it mean? The core idea is that the program itself should be self-explanatory. For details, see Source Code , that is, design. There are two important stages here. In most cases, the detailed design can be omitted. Our important design ideas will be reflected in our program annotations, A lot of useless Code annotations should also be removed. the Code itself should be self-explanatory because it has been written. the comments, blank lines, indentation, variable naming, and loops mentioned in the source code writing specifications all have standard writing specifications. If we can also consider code reuse and splitting, the entire code file can be highly readable.