[Reading notes-code Encyclopedia] Chapter 1th Welcome to the world of software construction

"Construction" is both a noun and a verb, but in real life it is best not to treat it as an adjective, such as "You are really ' building '." (Sorry, can't help but pull the –_-#)

My summary of this chapter is: in the software development process, the building activity is one of the most interesting activities of programmers. As for w-h-y,why, the author uses a chapter to illustrate the problem.

At the beginning of this chapter (1.1 of what is software construction in Page3), it is learned that the researchers acitivity the various activities in the software development process into the following 11 types:

1. Definition problem (problem definition)
2. Demand analysis (Requirements planning)
3. Planning and Construction (construction planning)
4. Software Architecture (software architecture, or high-level designs (high-level design)
5. Detailed designs (Detailed design)
6. Coding and debugging (coding and debugging)
7. Unit Test (Units testing)
8. Integration testing (Integration testing)
9. Integration (integration)
10. Systems Testing (System testing)
11. Guaranteed Maintenance (Corrective maintenance)

In the book's Page5, the author uses the following "Stereoscopic view of the book" to indicate the relationship between the build activity and the above 11 activities:

The gray ellipse in the diagram represents the build activity, thus:

(PAGE5) Building activities focus on coding and debugging, as well as detailed design, unit testing, integration testing, and other activities.

We don't have to rush to figure out what specific tasks are included in the build activity, because the book is clearly written:

To get a complete list of build activities, see the headings in each chapter of the catalogue.

Before you can choose to do something, or before you decide to accept the author's point of view, it's often more important to figure out why to build than how to build. Therefore, the core content of this chapter focuses on "(PAGE6) 1.2 Why software construction is so important". The authors cite 5 major reasons, excerpt as follows:

1. The construction activity is the main component of software development;
2. The construction activity is the core activity in the software development;
3. Focusing on building activities can greatly increase the productivity of programmers;
4. The product of building activity--source code--is often the only accurate description of the software;
5. A build activity is the only work that ensures that it will be done.

For the 1th and 5th, the authors used the column numbers and examples to illustrate why building activities are more important than other activities in software development.

2nd, there is no denying the fact that, of course, we (programmers) do not need to force other members of the project team (such as product managers and test engineers) to accept this view, stressing that the core position of the building activity is not to negate the importance of other activities.

In the 3rd, the "productivity of different programmers (productivity) can vary from 10 to 20 times times", and for a programmer, it should be something that "makes me happy":

• On the other hand, as a programmer, if you are told to learn through continuous learning, personal productivity will be up to several times the increase, how exciting oh;
• The sad side, as a programmer, is that if someone is told that productivity is several times their own, how exciting it is (if this person or someone is around you, maybe you can start paying more attention to Chinahr or Zhaopin).

4th, it's easy to associate the problem of developing documentation, and one might say that since the master has said "the code is the only exact description of the software," it doesn't really matter. I have something to say about the document. I want to read this article most of the people, in the domestic middle school in the ideological and political class, should have learned some of the commodity economy, understand the concept of "laborer" and "commodity" it. If the "laborer" corresponds to the programmer, then what does the "commodity" correspond to? Perhaps this question is not very good answer, in fact I do not care about its answer, I just want to use this analogy to illustrate a point of view, that is: whether the document is important depends on you (the programmer) in the final delivery, not to the "document" as a "product" view.

• Do not need to document the scene of the product has: a QQ client programmer, we create the most direct understanding of the product, is that running on the user's computer QQ, from this point of view, the development of the document does not affect the availability of QQ, so we do not have to be frustrated with the lack of accurate documentation.
• There is a need to take the document as a product delivery scenario, typically: for a class library (for example, Mfc,atl), the document is supposed to be part of the product he eventually delivered, a library with a lack of documentation or a poor quality of the document usually has two consequences, either fewer users, and later eliminated, It is either that other programmers are complaining while they can't choose.

That's what I think about the importance of the document, but then again, although I've never been frustrated by the lack of documentation, I've often had to pay an extra price for missing documents, including:

• Take over the new (here the "new" is mainly the meaning that you have not touched before) function module, because there is no document, you must look at the source code to understand the logic of the whole module, but the original code and write more than that, miserable;
• The development of more complex requirements, in the design stage did not form a document record, entered the coding phase, everywhere stretched, after the submission of testing is more bug;
• When you submit the test, because there is no documentation, you need to test your colleague face to head to explain the process of development implementation, after the test personnel changes, often again to the new test colleague again;
• When my colleague leaves, the handover to me has no documentation except the code. In the future to continue to do development, I feel the pressure of Alexander. "It's probably the experience of having someone who gets her, but not her heart."
• Say more is a tear ...

Because of the loss in these places, it is important that all of the documents written by programmers are valuable, and the difference is only in what documents are more important. This is just as all women in my mind are beautiful, good, their difference is only to reflect their beautiful and good places are different ... (This sensitive sex talk is enough)

"(Page8) 1.3 How to read this book" is mainly the author of the book Reading methods of some suggestions, I certainly choose to "from beginning to end" reading way.

This chapter highlights:

• Software construction is the core activity of software development, and building activities is the only necessary work in every project.
• The main activities of software building include: detailed design, coding, debugging, integration, developer testing (developer testing) (including unit testing and integration testing).
• Construction is also often referred to as "coding" and "programming."
• The quality of the building activities has a substantial impact on the quality of the software.
• Finally, your understanding of how to build determines how good your programmer is-this is the subject of the rest of the book.

[Reading notes-code Encyclopedia] Chapter 1th Welcome to the world of software construction