The design looks beautiful! -- The first brick of the "Design & pattern" Team

There is no standard in design and the pattern is full of changes. Our discussion of the design and pattern is to hope to experience the pleasure of design from the absence of standard designs, find a solution to the problem from the changing model.

The so-called "no design standards" here is actually not without standards. The reality is that there are too many design standards. We all want to find the best design scheme, but what is the best, everyone has their own "Hamlet ". The best design is to satisfy the customer's needs. I don't think there will be any objection to this conclusion. The premise is, how can we meet the customer's needs through design?

Plan Design and evolution Design

Generally, there are two approaches to software design: Planning Design and evolution design. Many people think that the design of the plan is more engineering. If you want to build a Mouch, you just need to hack it and pile up some thatch on the roof. However, if you want to build a political Park in Suzhou, you must design it in advance. Where the rockery should be stacked, where the pond should be opened, the shape of the pavilion, the distribution of the courtyard, and even the flowers and trees in the garden should be unique. The same is true for software design. When taking over the project, we should consider not coding, but the overall system architecture and major problems in the system as needed. The functions of modules, the relationship between modules, and the hierarchy of system distribution all need to be ingenious and considered from an abstract layer.

The Design of evolution is just the opposite. It is a gradual process. It does not require the perfection of the design in the early stage and the completeness of the implementation requirements. You only need to implement the coding of the problems currently considered. With the development of the evolution, the encoding will also be corrected, and the final design will gradually become full. After a series of methods, the final design will become more perfect.

You may think that the "evolutionary design" is so simple and mediocre. There is no plan, but it will only cause a design group to suffer. But I need to remind you that, even though they are all engineering, software design is not as simple as architectural design. It is difficult for you to consider all the customer needs at the beginning of the design, or even achieve future expansion. At the beginning of design, you can be confident that:

Have you understood the customer's needs?
Are you sure your customer's requirements will not change?
Can the software architecture you designed meet your needs?

Yes, you cannot give a positive answer. In short, I am not here to convince everyone, which design method should be adopted. In fact, I am also faced with difficulties in making choices. So, I hope you can participate in the discussion in "Design & pattern.

Over-design or simple design?

Kent has set four evaluation criteria for a simple system in "Resolution eXtreme Programming-Embracing Change", in sequence (the most important one is at the top ):

Pass all tests;
Reflect all intentions;
Avoid repetition;
The minimum number of classes or methods;

The writing of these standards is simple. It is not that easy to implement according to this standard. I believe that software designers want to make their designs as simple as possible. However, in design, we should not only consider the functions of the software, but also consider the performance and scalability of the software, the coupling relationship between modules, the stability, deployment, and updates of the system, version management, system security, and interface friendliness. How difficult is it to be simple!

Do the simplest thing that cocould possibly work! This is a loud cry from XP people, and I agree with both hands. The problem is that we need to make simple things effective at the same time. Many people are not satisfied with the current functions during design. When they see addition, they may also think of multiplication. Although the current requirement is an integer, they may think that they may expand to real numbers or even plural numbers in the future. They want to use a design to make it more scalable. From the perspective of immediate needs, it may be over-design. Then, for the future, this design is the most perfect solution.

The question is not whether the design is excessive, but the key is the design concept. Are you only doing what you need now, or are you planning for future function expansion? The "Design & pattern" team is looking forward to a beautiful answer. In fact, the goal is not how good this answer is. We hope that, while exploring the answer, we can get the sublimation of our design philosophy.

Do I need a design pattern?

The answer is yes, but do you need to determine whether the application of the model is excessive? I have to admit that there are many talented people in the world.ProgramClerk, he canCodeThere are 6 design patterns, or you can do a good job of design without having. But our goal is to pursue an effective design, and the design model can provide a reference model and design method for this goal. We do not need to set gof's design pattern as the standard, but it is the right choice to make rational use of the design pattern.

Many people have read gof's design patterns and are familiar with these 23 models. But what's important is not how many models you have memorized, but how to use them in practice. It is worthwhile to familiarize yourself with a certain pattern for effective design, because soon you will find that this pattern is really good in design, most of the time it makes your design easier.

In fact, few software designers may abandon the design model, and blindly exaggerate the functions of the design model, but more. You must talk about the "Mode" and cannot become a good architect. Really good designers, know how to judge the timing of using the model.

Another problem is that many people who have entered the software design field are often confused about the design model. For them, the idea of OO has not yet been established because they do not have the practical experience of the project, and the design model is too advanced. In fact, even very experienced programmers do not dare to boast the rational application of various models. Therefore, in "Design & pattern", you may need to talk about the practical application of the Design Pattern in project implementation.

Refactoring is inevitable!

Since we cannot provide a perfect design scheme, because the customer's requirements are always changing, restructuring will become inevitable. The problem is that no function refactoring is added. Are you willing to spend time and energy on this. When the deadline requested by the customer is coming, do you still think your refactoring work is necessary?

Sometimes, software design is often self-defeating. However, from a technical perspective, restructuring is not only inevitable but also important. Since we all understand that complicated is not always good, simple is not necessarily easy. To keep your design as simple as possible, you may need to always use the refactoring tool to "improve your existing code design ".

For refactoring, Martin Fowler provides many terms. These terms are not the dogma of political textbooks, nor the magic Manipulator of "sun, moon, and God". You can guard yourself with them. These terms are really important, but what you need is to learn about him and forget him, just like Zhang Wuji's practice of Taijiquan. I am not confused. In fact, only in this way can the spirit of reconstruction be fully integrated into your design.

Is UML important?

When I look at a design scheme, I want to first look at the UML diagram, and then look at the actual description of the document. If you want me to read a piece of code, I hope to first look at the class diagram, maybe it is easier to understand the meaning of the Code. UML is like a saying in the OO world. It facilitates communication between programmers and makes it easier for others to understand your intentions. At the same time, in the process of designing a UML diagram, it is also a kind of cleaning of ideas, understanding of customer needs, and tracking of design ideas.

UML is a unified object-based modeling language that provides a clear and intuitive design for system design. In the object-oriented world, UML is very important and even called a revolution in software design. For a planned design, the value of UML is fully embodied. If we want to clearly express the functions of the module, the relationship between modules and the hierarchy of system distribution, the use of UML can reduce a lot of trouble for designers and reduce the ambiguity of semantic descriptions. However, is UML so important when we design evolution? We only need to encode, test, and reconstruct the current needs. Maybe we only need to discuss the design scheme in the pair team and discuss the implementation possibilities and details within the predefined technical framework. We can put aside the tedious and Rigid Design of UML. After all, the most loyal embodiment of the design philosophy is not the document, not the use case diagram or class diagram, but the code.

So how many people think so?

TDD, unit testing, and others

"Design & pattern" is not just a design pattern. I hope it can cover all aspects of software design. What is the life of software? quality! The only way to ensure quality is to test. In the traditional software development process, the requirement analysis is emphasized first, and the outline design is abstracted from the requirement analysis, then detailed design is made, code is coded, and finally testing is performed to verify the correctness of the Code. Test-driven development (TDD) changes the coding process. development involves only three activities: writing test cases, coding, and testing, refactoring code to eliminate repeated code makes it simpler, more flexible, and easier to understand. Testing to drive development sounds so outrageous. However, implementation is so reasonable, correct, and simple. The premise is that we cannot get the right design at the beginning! TDD avoids immature design due to incomplete requirements. Through unit tests, code correctness and high quality are ensured. through reconstruction, the design is simpler and more flexible.

The content covered by design & pattern is not limited to this. In the field of software development, technological changes are changing with each passing day, and new technologies, methods, and ideas are constantly emerging. We hope that we can use the "Design & pattern" team to give strong attention to software design and conduct in-depth discussions on design ideas, it is expected to build a bridge between academic research and project applications. In this team, you can talk about your thoughts and express your opinions without fear. Debate can bring a spark of thinking. In software design, there is no eternal truth, only the spirit of truth-seeking and rigorous thinking. "Design & pattern" is coming soon!