Shulou(Shulou.com)06/03 Report--

Language is just a tool.

I used to be a very persistent developer. I have several days and nights of Coding experience, have spent three or four weeks on a technical issue, causing project delays, and have argued one by one over an implementation detail related to the project.

I used to be as keen as most developers to argue about the merits of languages. I wrote a profile on the Delphi Monopoly Forum, in which my specialty is to be good at TurboPascal, Delphi, and TASM languages, and I hate C _ Monopoly +. (whenever you see valuable C code, read it first, then write it into Pascal/Delphi, and finally scold: C is so stupid! I still keep this passage because it is really a real experience.

Now I no longer focus on language, as I wrote in the first chapter: it is even sad to talk about people who are good or bad all day long.

However, just a year before I wrote this, I was still writing Delphi Source Code Analysis, and I was endlessly delving into the details of the language, the details of the operating system, and the depth. Details of the development.

In March 2004, I accepted an invitation from a friend to go to Beijing to do a special training called "Delphi & Delphi .NET Source Code Analysis". It took me nearly two weeks to make a 50-page slide with a full account of Delphi and Delphi .NET. However, the night before I left, I couldn't sleep over and over again, thinking about a question: what on earth have I done? In other words, what exactly do I want to tell the students?

At 5: 00 in the morning, I inserted a slide at the back of the last page of the slide with the title "language is just a tool", and the content of the slide is such a picture as shown in figure 7-1.

This is a slide that has nothing to do with training. However, this is the first time that I have faced the word "software engineering" squarely since I came into contact with management in 1997 and engineering in 1998. For the first time, I saw the relationship between code, method, process, engineering and organization!

For a programmer, or someone who pretends to be a programmer, the first step to seeing all this is to say, "language is just a tool."

Apes for human beings, "learn to make and use tools" is the most important symbol. Therefore, I do not know whether the phrase "language is just a tool" is a worship of language or a disregard of it.

However, from that moment on, I really knew about the project.

Focus

In the previous model diagram, each vertical line is used to define a point of concern ①. I annotated these concerns in another training, as shown in figure 7-2.

This is named by me as Software Engineering layered Model (EHM,Engineering Hierarchy Model). The EHM model does not describe the relationship between engineering elements, and even tries to separate these elements in order to make the positioning of engineering roles and their respective perspectives more clear.

From this model, we can see that at the "program" and "method" level, it is focused on "(specific) implementation", while at the "process" and "engineering" level, the team problem is the primary consideration. From the perspective of role, the development manager thinks about the implementation plan of the project and manages the specific development behavior, while the project manager ensures the stability and consistency of the team.

program

In the EHM model diagram, in the innermost ring, it is "program = algorithm + structure". This is the original definition of programming, as well as the original state. Any work related to the code will still end up with such a rule.

This is the essence of programming. It has existed since the beginning of the development behavior. Yu Gong practiced programming with similar behaviors thousands of years ago, while Homo sapiens hundreds of thousands of years ago also revolved in the logic of loops and branches.

Method

What drives this logic forward is the emergence of "method" and "methodology". Long-term programming practice, natural deduction and summary, must be precipitated into some kind of (software development) method, so the "process" appears, the "object" appears, and the related methodology also appears.

This is the result of practice. The method is not created by a person or an organization. Melons ripe but fall off, practice accumulation to a certain extent, Microsoft does not propose a certain method, IBM will also propose this method. Even if they don't propose it, you may already be using this method yourself.

The method is not mysterious, because it is what you are doing, doing, and implementing today. Just as "pattern" is a method, and pattern is the behavior in which you wrote the code yesterday. However, GoF induces, extracts and promotes the inherent laws of these behaviors.

You can't see what you're doing, so you can't understand the value of "patterns" as a method. So the masters agree: patterns require a certain amount of programming experience to understand.

Similarly, understanding processes requires programming experience, understanding objects also requires programming experience, and understanding MDA (model-driven architecture) and SOA (service-oriented architecture) still requires programming experience.

This may happen at the moment when you review your last line of code, or the failure of the last project. Experience comes from review, understanding, and analysis, not from the next line of code you are going to write.

Some people get the way by sweeping the fallen leaves all their lives in the temple, while others get the way because of one sentence.

GoF learned from countless code reviews.

Process

The process is accompanied by engineering. The process solves the problem of the relationship between roles in the project.

The process is about how many people (teams) are organized to develop. It first decomposes the links in the project. In this way, with the link, there is a role; with the role, there is communication.

Therefore, the problem in the process is the role, communication and link. Which links are important depends on the specific programming behavior, that is, the specific project.

For example, the product development cycle can be delayed again and again, because for the product, what is more important is the quality and technical barriers. So you can see that Blizzard (Blizzard) games always skip tickets over and over again, and it always puts extensive player testing and developer personality characteristics first. Similarly, the soul of the DOOM and QUAKE series is in the development and design of game engines.

If you use this model to do a project, maybe the software company is not dead, and the demand side of the project is also dragged to death-have you seen the customer looking forward to your vision of the technology? No, you will only see them upset, frustrated, or. Rage.

Looking forward to this kind of thing, it will only happen to those die-hard players.

Not knowing the difference between the player and the customer is terrible for the project manager. This will mean that he cannot clearly know which link is more important.

The determination of roles and the communication between roles are equally important in the project process. Whether the engineering organization is reasonable and whether the mutual cooperation is close or not is the guarantee of the success of this project.

"close cooperation" is usually the wording of a written report. The real "intimate" should be the result of communication. UML, however, may be the first factor in the "alienation" between you and your customers, as well as between project managers and developers.

This article is excerpted from "Avenue to simplicity-- the thoughts of Software Engineering practitioners (Collection Edition)"

Published by Zhou Aimin Electronic Industry Press

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.