Prearchitecture of software (I) -- Opening

A concept, called pre-construction, was learned by chance. In the following time, we will briefly discuss all aspects of the pre-architecture.

First, let's first look at what is software pre-architecture. When I heard the word "software pre-construction", I believe that the first word that many people think of is "software reconstruction", and I am no exception. However, these two words are completely two concepts.

Refactoring is a practical design of a completed project utilization model,Code. The pre-architecture is to develop existing software projects using previous experiences or previous development experiences. In other words, pre-construction is an experience flow. Everyone is in the pre-construction, but they are not touched by this word. That's all. If the preconstruction and refactoring have any relationship. In my summary, the pre-construction experience is obtained from refactoring, which can reduce the number of refactoring times.

Well, I have explained this word. I think I shouldArticleRepeat the introduction. Instead of discussing pre-architecture, I am talking about my different understandings and Thoughts on various processes of software engineering.

So far, the official pre-purchase has started. In my first article, I mainly talk about the core idea of "pre-construction.

From the previous machine code, to assembly, basic, C, C ++, to today's C #, Java, F #, and so on. We can hardly see that the trend and goal of software language development is to develop the best software in the shortest time. Here there are two core words: "good" and "fast "! It is accompanied by the birth of new concepts of Software Engineering: XP eXtreme Programming, fountain model, spiral model and so on. Remember the first project experience in the student age-Online Learning examination system. At that time, we explored software engineering. At the Group meeting, we had to adopt the waterfall model. At that time, the college gave the project five months. The instructor holds a project meeting once a week, which is not so much a project meeting as a constant requirement change. As a result, we kept summing up the requirements. The result of the demand analysis took more than two months and was basically determined. Then I started designing. I spent another two months without any experience. Finally, I started to write code for half a month. Next, we can guess that the design is wrong and the interface design is unreasonable, modules cannot be integrated. Finally, the school made a big splash, And the. NET version rolled out and continued to adopt JSP.

Learn to iterate-increase. The following projects start to become more and more successful. From requirement, design, and even to group member training, the tasks can often be overfulfilled. Till now, I still stick to the following process: requirement --> first design --> code optimization --> Design Reconstruction --> requirement change --> Second Design --> improved design --> code optimization --> Design Reconstruction ...........

In the art of software pre-purchase, we introduced the word ultimate: abstraction to perfection, focus isolation to perfection, and readability to perfection. I do not fully agree with these points. I will only describe my points below:

1. Type abstraction ultimate. I mean, in the initialization design phase, try not to use actual types such as int and double for each data type. For example, it may take some time to describe the object data type. It cannot be too large, too small, or a decimal number. It is not good to focus on these details during initial design. It is better to simply write age. After the overall design is determined, pay attention to these details.

2. Ultimate readability. I don't need to say that. No one loves to see that there is no code standard. I personally do not need to use abbreviations. I 'd rather have a long name. At least I don't seem to have to worry about spelling mistakes.

3. Moderately object-oriented. When you are a beginner in the design model, you are always happy to design it everywhere. However, in actual projects, over-abstraction and over-targeting are not a good thing. Abstraction is for changes. without changes, it is not necessary to abstract them.

Finally, we apply the following sentence: "situation is everything ". Driving a Ferrari sports car on a mountain road will not be envied, but will be scolded as a mental illness. In an excellent software design, architects have the greatest advantage not in their technology, but in their ability to adapt to emergencies, that is, the experience stream, and return to the topic, that is, the "pre-construction" capability!