V. Simple design
XP high emphasizes a simple design principle: the functions that can be implemented with array will never use the list. In other Agile methods, simple principles are also repeatedly emphasized. In this chapter, we make a comprehensive understanding of simplicity.
Context
What level should the architecture be designed?
Problem
Software architecture is very complex, with a lot of documents and charts. Developers are spending the time that the architecture itself or even exceeds the realization of the architecture. In the previous article, we mentioned some reasons for opposition to the imaginary architecture, and one of the reasons is that the designers of the ivory tower are often more experienced in design, not strictly. Demand for design.
In the field of software development, the most common design is the design of "Code and FIX", and the design increases with the software development process. Alternatively, we can think that this way is not a design, which holds a ship to the bridge. It is naturally straight to the bridge, but after the design is constantly changed, the code becomes bloated and it is difficult to understand, and it is full of repeated code. In this case, the design of the architecture will not talk, the software is like a broken house in the wind and rain, which is on the verge of collapse.
For this situation, the new design is in the new design, and Martin Fowler said this approach is "Planned Design". Similar to architectural design, it emphasizes strict design before encoding. This is the typical practice of architect designers we talked in team design. Designers usually will not be programmed, the reason is in civil engineering, you can't see a designer to brick.
"Planuned Design" has improved many more "Code and FIX", but there will be many problems. In addition to the problems we talk in team design, demand changes will lead to greater trouble. Therefore, we will find "elastic design" for granted: Elastic design can meet the changes of demand. The price paid by the elastic design is complex design.
Exterior:
Here we talk about some of the questions attached to "Planned Design", there is no meaning of this way. "Planned Design" still has a lot of option, but there are many places that need to be improved. In fact, the architecture design method we discussed herein is essentially "Planned Design" mode. The way to "Planned Design" is the "evolutionary design" mode advocated by XP, but this way is still waiting for the practice, and it is not easy to say that he must be advanced or backward than "Planned Design". But it is certain that there are many ideas and techniques in the "Evolutionary Design" mode to be "Planned Design".
Solution
There are two very loud slogans in XP: "Do The SimpleSt Thing That Could Possibly Work" and "You Aren't going to need it" (usually called YAGNI). Their core thinking is not to consider the future, and the functionality that does not need to be added to the software.
Under rough, there will be many developers think this is unrealistic slogan. I can understand this idea. In fact, when I am passionate, I can re-use component technology, I have a simple slogan to advocate XP. But in practice, some software I re-thinking this problem because of the development cost of development, and I found that simple design is reasonable.
Reduce the cost of development
Whether it is mode, reusable components, or framework technology, the purpose is to reduce the cost of development. But their way is to make a lot of investment, then save subsequent development costs. Therefore, many ideas in architectural design are surrounded by this idea, which may also lead to the general thinking of architectural design.
The way XP is exactly the opposite. When processing the first problem, it is not necessary to design a flexible, almost perfect architecture. This work should be with development evolution and slowly mature. I don't dare to say this way is definitely correct, but if we regard the structure of the organism as an architecture, does this approach are not very similar to the evolution of creatures in the nature?
The idea of making perfect architecture at the beginning is not wrong, the key is to make this point. There will always be a lot of problems is that you didn't take into account when doing design. In this way, when the "perfect" architecture that spends a lot of effort, "perfect" will inevitably encounter unexpected problems, this time, complex architecture will affect the design improvement, leading to the rise of development costs. This is like if the direction is wrong, the transportation is fast, but it causes the rapid expansion of the error. Martin Fowler said in his paper, "Working on the Wrong Solution Early Is Even More Wasteful Than Working on The Right Solution Early" (I have to do one thing in advance, more wasteful than one thing in advance), I believe It is also the truth.
More interesting is, usually we are more likely to do something wrong. We can't make detailed needs when we are architecture design. In fact, even if you have achieved complete demand, it may also change. The architecture design made in this case is impossible to not be wrong. In this way, the "perfect architecture" that is wasted in the initial stage design is not as good as a follow-up improvement.
Improve communication efficiency
We have already talked in the team design to reduce the cost of communication, and all people can understand the architecture in order to make all people. But if the architecture is too complicated, it will reach the rise in communication costs, and this cost will not decrease with the project, but will continue to rise due to the encounter of new problems above.
Simple architecture design can accelerate the development team understanding the speed of architecture. We can understand simple meaning in two ways. First of all, simply means that the problem will not be very complicated, the architecture is the key to solving the needs, no matter how complicated and more demand, you can always find a simple and stable part, we can make this simple and stable part as the foundation Further, improve expansion according to the needs to solve complex problems. In the example, we mentioned Measurement Pattern, which is designed in this idea.
Second, simplicity is also reflected in the simplicity of representation. One 5-page documentation can express a clear architecture design why it takes 50 pages? The same truth, can be used in architectural design that can be represented by a simple graphic. After all, face-to-face communication is the most efficient communication. No matter how complicated, no matter how complicated, and complex documents, maintenance needs a lot of time. Only in both cases, we advocate the use of complex documents: First, the development team has no way to face-to-face communication; Second, the development achievement should be accumulated as a team's knowledge, and use it for the next development.
Consider the future
We consider the future, the main reason is the instability of demand. Therefore, if we consider changes in the future, we will increase complex ingredients in architectural design. This is a simple spirit of violations. However, if you don't consider possible conditions, those changes that are not in the current design, will result in a lot of rework. Remember YAGNI? In principle, we still insist not to design in the existing system for future possible conditions. However, we must think that you must prepare for the future possible situation. In fact, the idea of a great interface in the software is not here? Therefore, thinking in the future, but when you need it.
Change cases help us think about the future, the change case is that you may have (or may not be), but now you don't need to meet the needs. When we are making architectural design, the change case will also become one of the design considerations, but it is impossible to become the only consideration for decisions. Many times, we are addicted to the challenges of the design general system to us, in fact, our work is meaningless.
Architecture stability
What is the relationship between architectural simplification and architecture stability? We said that the smaller the architecture, the better the stability. The reason is very simple, 1 class with 4 methods and 3 attributes, and which is more stable than one class with 20 methods and 30 properties? Of course it is the former. The architecture is ultimately to be mapped to the code level, so the simplicity of the architecture will bring the stability of the architecture. To make your class small, let your method shorterly as possible, and make the relationship between classes as little as possible. This is not my advice, and many of the articles of the design class are said. On this topic, we can further read the articles of the same type (think about Refactoring).
Simplete
Therefore, for us, simple meaning is not to join the future, or without realization, and the corresponding architecture design does not need to consider these additional needs, as long as it is necessary to meet the current demand. All right. This is a simple definition. However, in reality, there is always such or such reasons, so that the design tends to be complex. In general, if a design is valuable to the team, then paying a certain cost of research, verification, development, and documentation this design is meaningful. Conversely, if a design does not have a big value or developing it exceeds its ability to provide, then don't need to consider this design.
Value has different meanings for different teams. Sometimes it may be time, sometimes it is user value, sometimes it is possible to reuse the team's design accumulation and code reuse, sometimes in order to get experience, sometimes to study the reusable framework. These can also be called purposes, so you are in designing architectures, please pay attention to you to determine your goal, think about things that are helpful to achieve purposes.
SCOTT W.AMBLER mentioned a story that he personally experienced in his article, spent a lot of time to design database to business logic mapping architecture, although this is an developer I am happy to study (because it is cool). But he had to admit that this design advanced architecture is not much significant because the user does not care about the specific technology. When I saw this story, my trove is very big. A developer is always keen on novel technology, but if this novelty cost is made by the user, is it reasonable? Although the use of new technologies can bring benefits to users, no one has calculated the cost behind the benefits. For the project I have developed, this cost is often greater than the benefit. This problem may not be determined, can only be seen. Simple is not equal to achieving simple
Speaking here, if everyone has a misunderstanding, I think a simple architecture must be easy to design, then it is wrong. A simple architecture is not equal to implementation. A simple architecture requires a lot of effort to spend a lot of effort, as well as designers have a deep attainment to technology. In a project we are in progress, the infrastructure of the design is modified several times in the implementation, but each modification, the amount of code is reduced, and the readability of the code will enhance one point. From a psychological point of view, constantly modify their architecture is indeed a certain courage. Because whether it is design or code, it is the heart of the developer. But crossing this step is worth it.
The example on the right discusses the Java IO design, the design of the Java class library should be very good, but still avoid re-modification. In fact, in the field of software development, due to the original design mistakes, it is later designed to be more complex, such as Microsoft OLEs. Similarly, when we design software, we also need to make constant modifications. It is easy to achieve complex functions, and it is not an easy task.
What kind of designer does it take for simple design?
Simple architecture requires a comprehensive designer. What is a comprehensive designer, and my definition is capable of designing and coding. We have already talked about ivory tower architecture and ivory tower architects in team design patterns. One of the most probabilized things is the detachment of design and code. From our own experience, even in a very perfect architecture considered in the design phase, there will be such or such problems in the coding phase. Thus, the architecture achievement is complicated. The most obvious feature is that there is a large number of methods when encoding, or a class for a long way. This indicates that the architecture and code are detached. In our development process, this phenomenon is not only, or the bad smell appears. Refactoring skills also help to identify bad soutions.
After the architecture design is completed, the developer can program quickly according to the design, quickly. After a period of time, the new features continue to join, we find that the code begins to make confusion, the amount of code increases, the readability is declining, the debugging is difficult, and the code uncontrollable sign begins. We know that the design needs to be adjusted. This belongs to the refactoring mode we mentioned later. What we have to say here is that if the architecture of the architecture does not participate in the code, it can't feel bad taste, so it will not be an initiative to improve the design. To solve this problem, the best way is to let the designer's participation in code, especially the real part of the important architecture requires the participation of the designer. If the designer doesn't have a way to participate in the code, it will need a mechanism to feed the code to the designer, let him reconsider the improved architecture when it is appropriate. A possible way is Code Review. Let the designer audit the code to ensure that the encoders really understand the intent of architecture design. Example 1.Java IO System
From Java's IO system design, we can feel the difficulties of simple design.
The difficulty of IO system design is always recognized. One purpose of Java's IO design is to simplify the use of IO. In Java's 1.0, Java's IO system is primarily divided into two most, and defines abstract class inputStream and OutputStream. From these two abstract classes, a series of input and output classes of different functions are implemented. At the same time, Java's IO system is also implemented in the input and output, and the abstract classes of FilterInputStream and FilterOutputStream are also implemented. The function of the input and output function is connected to implement complex features. This implementation is actually Decorator mode (because there is no source code and related information, this is just based on function and use skills, if you have different opinions, welcome to letter discussion).
Therefore, we can superimpose multiple objects to provide complex features:
DataInpustream IN =
New DataInputStream
New BufferedInputStream
New FileInputStream ("Test.txt");
The above code uses two FilterInputStream: DataInputReam: DataInputReam and BufferedInputStream to implement read data and buffer features, using an InputStream: FileInputStream, read flow data from the file. Although it is not very convenient to use, it should still be very clear.
The design is neither INPUTSTREAM, nor is the class of OutputStream, such as RandomaccessFile, which is indicating that due to the complexity of the function, it makes the design of the input and output classification become confusing, according to our experience, we say design Refactoring is needed. Therefore, in Java1.1, the IO system is redesigned, using the design of the Reader and Writer bit, and adds new features. But the current design seems to be more confusing because we need to use 1.0 and 1.1 different IO design.
Example 2. Measurement Pattern
In the analysis mode, there is a Measurement Pattern (measurement mode) in the book, which is to solve various complicated measurable properties in reality. For example, in a medical system, there may be a high height, a variety of weight, and a number of measurable properties such as a number of blood pressure. If they represent them, it will inevitably lead to rising system complexity. Therefore, Measurement Pattern starts from these attributes to study new solutions, proposing Measurement Pattern ideas: as shown, makes Measurement as instances of Phenomenon Type, and each One of the Person can have multiple Measurements, at the same time, Measurement also corresponds to the properties of the process, such as Quantity in the figure, represents the number and unit of Measurement. For example, a person's weight is 65 kg, then Phenomenon Type is a weight, Quantity's Amount is 65, Units is kg.
Figure 5. Class diagram of the MEASurement Pattern
This is actually a very simple design, but it clearly expresses the relationship between attributes, simplifies the complexity of thousands of properties. In addition, we will find further, it will find that this architecture is just a basic solution for problems currently at present, which can also be extended according to specific needs, for example, realize dynamic adding units, or implement different unit transformations, etc. problem.
Therefore, we show it here is a way to think, immersive, when you face a complex medical system, a lot of properties and different processing methods, you can find out from such a complex demand What is the simple part? In our architectural design, we talked about the essence of architecture design lies in abstraction. Here example is the most typical example. In our traditional ideas, we will use the concept of height, weight, etc. as an attribute or class But in order to meet the needs of this, we make an abstraction of these specific concepts, proposing the concept of measuring category, and design it as a class (Phenomenon Type), and make specific concepts as an example. This abstract thinking is ubiquitous in software design, such as the concept of a metaclass.
More in-depth understanding
In the next chapter, we will discuss iterative design, which will also involve relevant knowledge of simple design. It is recommended to combine the contents of the two chapters.
