Oschina answers one of the reader's questions: Learning and usage of "Software Engineering"

I used to give oschina an award-winning Q & A related to "software engineering practice" (the prize was for the questioner, haha). Now, many questions are still readable, therefore, you can organize the text to enjoy the crowd.

Original posted here: http://www.oschina.net/question/12_78459

The question in this article is: how to learn software engineering, how to use it?

A:

First, software engineering cannot be learned. It is the so-called "cannot learn". Through dead learning, there is nothing valuable. We must raise some questions ourselves and then solve them. Through this process, we can learn and understand them. The first question I want to ask is "What is engineering ". Why should we score this score when studying engineering, science, and liberal arts? Why is engineering part of "engineering? The more interesting question is, why is there no so-called "literary engineering?

　　
The project is intended to point to "producing something ". Engineering is also biased towards "actually doing something ". You cannot find people in theoretical mathematics or theoretical physics to make practical achievements. Engineering, and the project mentioned here, is to "make something ". Software Engineering is nothing more than discussing the practice of "building a software.

　　
But we need to see that we need to determine the practice of "doing one thing", so we need to talk about "Software Development", so we have a code worker who writes software, techniques and methods for writing software. However, this issue is not discussed in software engineering. It is attributed to the scope of "Tools. Similarly, "doing one thing" involves "people", but it is not discussed in software engineering, but in management. And so on, all these things are divided out because of their respective disciplines. The "Software Engineering" course itself, there is only one "pure academic" thing left. It only discusses the question of "How to Do software, instead, he gave up the specific persons, specific technologies, and specific R & D targets in specific practices. The question of "How to Do software" is a simple model used by the idea of "engineering", namely: Software Engineering = (to build a software development-oriented project) process + method + tool.

But the interesting thing is that whenever an engineering department is "doing something", it is necessary to engineer this thing, as if its conclusion would be "using a process, finding some methods and using some tools, ". Therefore, there is no essential difference between software engineering and anything engineering. From the beginning of the industrial revolution to the present, the predecessors have done this. In theory alone, this is the case with all models. In other words, the above formula/model can also be simply described as "Software Engineering = using engineering methods for software ".

Let's look at the book "Software Engineering". It's useless. This is simply not necessary. I understand that "engineering one thing is just the above method ", the entire book becomes a reference manual-checking what processes, methods, and tools are used by others, and what results are there.

Learning "Software Engineering" and understanding the above is enough. In engineering, the rest is "practice. In the same process, it is impossible to practice three or five times ~ 50 times is always a line. The same is true for learning "Software Engineering". A set of processes, methods, and tools have been used, but they have done their best and are skillful.

For a specific project (such as a specific project), the above is almost useless. Why? As we have said before, a discipline such as software engineering cleans up "what", "who", and "What technology, it becomes a pure "engineering ". In fact, a specific project is actually included in these things, people, and technology. Therefore, for specific projects, we need to talk about management when encountering human problems. "I learned Software Engineering" does not mean that I will manage them. When encountering problems with something, we need to talk about products, "I learned Software Engineering" does not mean that I would design products; and so on. Our specific project does not necessarily have a "All-in-One" team. Therefore, when implementing the project, there are always some shortcomings in this aspect. The problems we encounter are not always in the book.

However, let's take a look at the problem you are facing, the project, and the specific project. In terms of the solution to the problem, it is just "finding a process and using some methods, just use some tools. Therefore, people who really understand software engineering know this principle-the core principle in the software engineering book is enough. Others, see God and kill God. See Buddha and kill Buddha. Do it yourself. Which of the following statements about a specific project? What about RUP and XP? It seems that you are already in the army, and you are playing from the beginning of Tai Chi! Joke! See one cut, one cut, the wrong y bad luck, that's it.

Is there a routine? Are there any principles? There are still some, as said in "the greatest truths to Jane", do not cut down the swords in the army, the swords are used to block the swords, and the swords are used to stab and kill, use the most effective method. These are some basic principles. In a specific project, I have to whisper to Employee A. I have to knock on employee B. The test of employee C must be retested ...... Wait, just summarize it in the project. One-on-one response from people, events, environment, and target objects, then you will succeed, and you will be able to become an elite in the project, and you will be in your 50 s.

Practice. Without practice, how can we achieve this? Software Engineering only focuses on one core principle. It is actually a project, a group of people, and a product goal. There are three things that can't be taken care of. They can find their methods, processes, and tools, and work together to get the results.

I have never believed the person who finished the software engineering project.