Thoughts and doubts based on the law of modern software engineering construction

First of all, in the view of what I read, the book is more of a large number of scenarios "learn" and "XI", and use a lot of analogy, very lively and interesting. It is easier to understand and read than other subject books.

Second, the textbook also puts higher demands on software engineering teachers because it is not just code that teachers need to teach students.

Finally, I have doubts and thoughts about this book. For example, in the first chapter of the book, page 30, on; The story of Bugs and granulation ", as far as I understand it, is a story of the inconsistency between customer demand and the need and supply of software makers. Software engineers provide the client with a granulation, and the customer thinks it's "disgusting bugs," and sometimes we think it's a good thing, and maybe customers think it's not necessarily good.

Therefore, how to fix this bug well, should be the problem that all C programmers should face. The above is my understanding of the story. At the same time, I also think that there should be a deeper meaning, I hope that teachers and students to publish more opinions, so that we have a more profound understanding between the program and the customer.

In the second chapter, I read the 9 major functions of unit testing, and found that the operation and maintenance of software engineering is far more than we enjoy the simple. A programmer should be responsible for his code. In this chapter, I have a certain understanding of the fundamentals of regression testing, but the actual operation of it some ignorant, I hope someone can guide me. At the same time, I am also the next week the teacher is about to teach us the "unit test" full of expectations, I hope teachers teach us these little white more about the software engineering operations maintenance and other information.

In the third chapter, "Software Engineer's growth", in which I have my own opinion on its content. The book says there are 4 criteria for measuring a software engineer, including: Code volume and Task point, time, quality, and delivery on time.

And I think, the most important of which is the thinking, a software worker on the whole software engineering planning and logical thinking. Just as the code shows a programmer's level is not the number of lines, but its algorithm design and thinking logic. In a very short code to the original should be used in a very long code to express things with thinking to improve the overall efficiency, this is the professional. And in this chapter, there is a problem puzzled me, that is 69 pages of a problem, software development is a project, an art or a so-called. Do you want to keep the rules, or do you pay more attention to innovation or influence?

Finally, I would like to share a paragraph I liked when I read this book:

In football class, the students found that the coach did not bring the ball, so he asked the coach why. The coach asked: "Football matches, there are 22 players on the field, the same time there will usually be a few people touch the ball?" , the trainees answered "1," and the coach said, "Well, today we're going to learn what the other 21 people have to do."

This is an example that is not in the book of another computer. But here is full of wisdom, vision, and teamwork. Although this is a sports level, it is inseparable from what our software engineers need. This should be an example of the vividness and illustrative nature of the book. This, just because it is a good book.

Thoughts and doubts based on the law of modern software engineering construction