"Code Encyclopedia" after reading thoughts

It was in order to complete the work of the Software engineering course, only to open such a voluminous book. Although this week only read a few chapters, but feel that the first time such a serious difference between the software and code, but also for the first time in engineering to consider the software. Although the "software engineering" such a course, but a class is not serious, and the course content often tangled in local problems, so no feeling. The teacher who wanted to come to this course knew the situation, so the first lesson was that we should find some books on this subject. However... Still failed to attract our attention.

It was not until this time last week that he said he wanted to check the blog to think about it. Originally wanted to casually find a thin book to see, but also think, to see or see some classics, so found the "code Daquan." Read five or six chapters, now it seems, the author uses coding to describe software programing very reasonable, the software writing process, in the final analysis is the process of coding, all preparation, documentation, and finally for the correct coding. The correctness of this is certainly not a grammatical error, but a logical, functional, maintainable, and so on, from the entire software perspective.

Reading such a widely acclaimed book, The first feeling is a lot of examples, but also the author repeatedly referred to the "analogy" good use. Reading these chapters, the following statements make me feel quite deep:

"In incremental development, we first make a version of the software system that is as simple as possible, but can run." It does not have to accept the actual output, and does not need to do real processing of the data, not to produce real output, only need a strong skeleton, to support the future development of the entire system.
For each part of the feature that you mark, you may need to invoke only the pseudo-class.
After the skeleton is formed, each false class is replaced with a real class, and instead of pretending to accept the input, it joins the code that accepts the actual input, and no longer pretends to produce the output, but adds the code that produces the actual output. ”

The idea is that I should have no feeling about six months ago, but since this semester involved in some of the projects in the lab, I started to know the meaning of such a development process, and this process is well suited for use when the entire software architecture is not well understood, and is responsible for the entire framework version by a programmer who is very clear about the entire software. Then, several programmers are responsible for the implementation of a part of the code. Facilitates the connection of the entire system while also accelerating the development speed of the software.

"It's usually pointless to write those ready-made code yourself. ”

After the C language, the C # language is contacted, in which many commonly used algorithms are encapsulated into functions that can be called directly. At first I had some doubts as to whether there would be problems that could not be seen, and then discussed with my classmates the many packages in Python, the Toolbox in MATLAB. Found that a lot of tools are in fact ready-made, and is written by very experienced programmers in a very refined low-level language, after a long history of proof to become the current package. For these widely used, long-term tools, we can use them in software development, improve efficiency, and the ready-made code is often better than temporary writing code.

Tests cannot detect defects such as "manufacturing a faulty product", "manufacturing with the wrong method". Such a flaw must be resolved before testing-more specifically before the build activity.

Although we stress the testing process after the software is completed, testing, as stated above, cannot detect errors in the direction, which is most deadly. Before you start building an activity, even before you encode it.

Some programmers do know how to prepare for the preparatory work, but they don't do it because they can't resist the urge to start coding as soon as possible.

This is often the difference between a programmer and a software engineer, and we have to resist the urge to write code as soon as possible, to be fully prepared to build a truly correct piece of software.

If your boss orders you to start writing code right away, the second less plausible approach is to put an old list of programs in your desk corner and then go into the development of requirements and architectures.

Such a similar tone of the sentence is often visible, thus, the author is also an experienced programmer, and stand in the programmer's perspective, for our new generation of programmers to guide the maze. And from such a playful tone of voice, "demand and architecture" is essential, even if your boss does not understand, we still need to do this work, or the final problem is we.

Programmers are the last link in the software food chain. The architect eats the demand, the designer eats the architecture, and the programmer digests the design.

This is probably a lot of the programmer's heart, but also shows a correct "requirements and architecture" for the programmer's important significance.

The development process can help the customer to better understand their own needs, which is the main source of demand.

The author's remark made me realize that, until then, I had always thought that what we had to do was to identify requirements as much as possible before we started development. But it seems to be true, as the author says, "It's impossible." Think about it if we're clients, where Ken can say what it's all about when it doesn't have anything. We need to actively in the development process demonstration, so that customers more specific needs, this is the main source of demand!!

In the face of changes in demand: "I will tidy up a revised schedule and cost estimates so you can decide whether to do it now or to say it again."

However, the author's approach is very effective at times when the demands of the customer are sometimes difficult to achieve or have a huge impact on the entire project. Tidy up the revised schedule and cost table, these two words most can let the user sober to consider whether the demand really needs!!!

"Code Encyclopedia", there are many things to find out, hoping to understand the process of software construction, understanding the need for software to become "engineering".

"Code Encyclopedia" after reading thoughts