Oschina answers the third question: is the architecture clear the problem domain? What is the proportion of each element 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

There are two questions in this article: Is the architecture a clear explanation of the problem domain? What is the proportion of each element of software engineering?

Q:

1. architecture.
I think the architecture is to clarify all aspects of the problem domain and design a solution as simple as possible. The core issue here is to simplify complicated problems, rather than making simple problems or complicated problems more complex. The simplicity here includes simple understanding, simple expansion, and simple communication with the team. The ability to make complex problems simple is the so-called "Quality and thinking of architects". Here, naturally there is a level of problem in it. The higher the complexity of the problem domain, the "Architecture Capability" is stronger. Do you think this is correct? Or do you have a better supplement?
2. About software engineering.
I have always understood it as software engineering = tools + Methods + processes.
I would like to ask about the proportion or regularity of the three in software engineering practice.

A:

Academic Circles, especially domestic academic circles, have always had a problem. It is to discuss something, always saying "What is this thing", rather than "what is this thing ". Sometimes, the text looks like the former, but it is actually the latter. This is also a problem in the View of jazz, that is, you are actually talking about "Simplifying complicated problems, that is, building architecture ". This point of view is essentially the question of "how to do the architecture", but it cannot explain the question of "what is the architecture" and "how to do the architecture.

　
As I often say, when we go to the zoo, we see tigers say "this is an animal", Lions say "this is an animal", and crocodiles say "this is an animal ". So we can say that "tiger + lion + crocodile" is an animal? Obviously, this is a joke. However, when discussing things, we often cannot open this trap. For example, "the problem of solving complexity is the architecture". In this way, we think this is the whole architecture.

Good. Let's go back to the next step. What is the architecture? I didn't talk about it in my previous post, but I only talked about "architecture as a result, it consists of two things ", and "Architecture thinking can come from thinking about these two things ". However, I admit that this is not an explanation of what the architecture is ". However, I cannot directly talk about and give an answer to what architecture is here. Because the answer I can give seems so simple, direct, and meaningless, it will be ignored by anyone relentlessly, and it is just a nonsense. I made a structural analysis and explanation of this answer in "Avenue to Yi. I suggest anyone who is interested in this question study the "Chapter 1 Architecture Principles, skills, art and beauty" in this book ". In the preface of that chapter, I wrote:

My understanding and Thoughts on architecture is only one of the possible understandings and thoughts of architecture, and is one of the possible solutions. I must mention the core guiding principles of this aspect and methods. The correctness of these principles will surely be expressed as: it can provide a basis for other understandings and ideas, it is a basic prerequisite for other effective understandings and ideas that can be discussed. This book only talks about architecture as an example of application under these principles. These principles come from the thinking process of these examples and go beyond the results of this process-the architecture discussed in this book.

Therefore, I hope to discuss this academic topic in a more serious way, that is, "What is architecture ". Instead of "I think this is an architecture", or "I see an architecture doing this ". I don't think that is the answer, and I think that direction is farther away from the answer. As I previously mentioned in the metaphor of "Zoo", we are not the full set or full solution to the problem, but the method of "View" is as follows, it is not the correct solution.

Reply to your last question. Simply put, I think there is no such thing as a "proportion. "Software Engineering" is made up and formed by engineering, because it is a "problem set ". However, in engineering practice, the background of practice determines how we invest in implementation, rather than an academic guide or form of action. I often say that "real managers do not read management technical books." When we regard "Software Engineering" as a technology, attempts to find formulas and rules in technical books are all stuck in the technical thinking, and in the craftsman's thinking of "doing what you want to do is necessary first.

So I often say, "If you think this sentence is correct, it means that you are a 'work '", because this is your work method, status, and basic mode of building knowledge and capabilities. -- From "Avenue to Yi"