About the Author: regular column, micro-channel public number [architecture in the future] of ten years of front-line Internet research and development experience in; specializes in large-scale business systems architecture and technology team management; on the membership system, technology units, business units, networking platform and other construction has a wealth of experience; former member fifty-eight city commercial technical director, technical director of Bao drive car rental, etc., now 58 business units responsible for technical home team.
Computer software written in the history of mankind is one of the purest creative activity. Programmers are not bound by the laws of physics and other practical limitations; we can not exist in the real world behavior to create exciting virtual world. Programming is not required as ballet or basketball or physical skills as coordination. All programming is needed is a creative mind and be able to organize your thoughts capabilities. If you can visualize a system, you may be able to achieve it in a computer program.
This means that, in the process of writing the software, the biggest limitation is our ability to understand their own system being created. With the perfect overlay functions and procedures, the system becomes more complex dependencies between components becomes extremely delicate. Over time, increasing complexity, when the programmer to modify the system, they are increasingly difficult to remember all the relevant factors. This reduces development time and cause bug, further reducing development time and increase development costs. In the life cycle of any program, complexity will inevitably increase. The larger the program, the more people involved, the more difficult to manage complexity.
Good development tools that can help us deal with complexity in the past few decades, many great tools have been created. However, our ability to use the tool alone is limited. If we want to write software easier, so that we can at a lower cost, to build a more powerful system, we must find ways to make the software easier. Despite our best efforts, the complexity will still increase over time, but more simple design allows us to build a larger complex before becomes irresistible, more powerful system.
There are two general methods to deal with complexity, these two methods are discussed in this book. A first method is by reacting code simpler, more apparent to eliminate complexity. For example, it is possible to reduce the complexity by eliminating a particular situation or identifier used in a consistent manner.
The second method is the complexity of the packaging process it, so that programmers can work on a system without exposing all the time complexity of the system. This method is called a modular design. In a modular design, the system is divided into software modules, such as classes in the object-oriented language. These modules are designed to be independent, so that programmers can work on a module, without having to know the details of the other modules.
Because of the strong plasticity of the software, the software design is an ongoing process, it spans the entire life cycle of software systems ; this makes software design is different from the physical system design and other buildings, boats or bridges. However, people do not always look at software design. In most programming history, the design focused on the beginning of the project, as in other engineering disciplines. The most extreme of this method is known as the waterfall model, in this model, the project is divided into discrete stages, such as requirements definition, design, coding, testing and maintenance. In the waterfall model, each stage is completed before the start of the next stage; in many cases, responsible for each stage by different people. In the design phase, the entire system is also designed. The design is frozen at the end of this phase, the subsequent stage role is to enrich and implement the design.
Unfortunately, the waterfall model is rarely applied to software. Essentially the software system is more complex than the physical system; Before building anything, could not very well visual design of large software systems in order to understand the meaning of it all. Thus, the initial design will be a lot of problems. Before the smooth implementation, the problem does not become apparent. However, the structure of the waterfall model and can not meet at this time of major design changes (for example, a designer may have been transferred to other projects). Therefore, developers have tried to fix the problem without changing the overall design. This has led to an explosion of complexity.
Because of these problems, and now most software development projects use an incremental approach, such as agile development, in this method, originally designed to focus on a small subset of the overall function. Design, implement and evaluate this subset. Identify and correct problems in the original design, then the design, implementation and evaluation of a number of other features. Each iteration exposed the problems existing designs, these problems before the next set of design features have been repaired. Unfolding in this manner, the system can solve the problem is still very small when the initial design; characteristic late to benefit from the experience gained in the early characteristics of the implementation process, so they are less of a problem.
Incremental method is applicable to software, because the software has sufficient ductility to allow major design changes in the implementation process. In contrast, for physical systems, major design changes more challenging: for example, changing the number of towers supporting the bridge is unrealistic in the construction process.
Incremental development means that the software design will never be completed. Design continue to occur in the life cycle of the system: Developers should always consider design issues. Incremental development also means continuing redesign. Originally designed a system or component is almost never the best; experience inevitably show better ways of doing things. As a software developer, you should always look for opportunities to improve the design of the system you are working on, and you should plan to spend part of the time on design improvements.
If the software developer should always be considered design problems, and reduce the complexity of software design is the most important element, the software developer should always be considered complexity. This book is about how to use the complexity of the design to guide the entire software life cycle.
This book has two overall objectives. The first is the description of the nature of the complexity of the software : "complexity" What do you mean, why is it important, and how to recognize when a program has unnecessary complexity? The second, and more challenging book aims to introduce techniques that you can use in the software development process, to minimize complexity . Unfortunately, there is no easy way to ensure that good software design. Instead, I will show a set of advanced concepts and philosophy, such as "class should be deep" or "definition does not exist error." These concepts may not be able to determine the best design immediately, but you can use them to compare the design and guide you through the exploration of the design space.
1.1 How to Use This Book
Many design principles described here a bit abstract, so if you do not see the actual code, it may be difficult to understand them. To find small enough to be included in the book, but large enough to be a practical example of the system telling is a challenge (if you are experiencing a good example, please send them to me). Therefore, the book itself may not be enough to let you learn how to apply these principles.
Use this book the best method is a combination of code review. When you read other people's code, consider whether it is consistent with the concepts discussed here, and how it related to the complexity of the code. Other people's code easier to detect design problems than your own code. You can use as described herein danger signal to identify problems and make recommendations for improvement. Reviewing code will also make you aware of new design methods and programming techniques.
One of the best ways to improve your design skills is to learn to recognize danger signals: a code signal may be more complex than it needs to. In the course of this book, I will point out danger signals associated with each major design problem issues; most important of which are summarized in the back of the book. Then you can use them in the code: when you see a danger signal to stop and look for a possible alternative design to eliminate the problem. When you first try this method, you may have to try several design alternatives, and to find solutions to eliminate the danger signals. Do not give up: The more you try to solve the problem before you choose, the more you learn. Over time, you will find that your code is less and less of a danger signal, your design has become increasingly clean. Your experience will also showcase other danger signals can be used to identify design issues to you (I'm glad to hear that).
In the application point of view of this book, it is important to moderate and cautious. There are exceptions to any rule, any principle has limits. If you put any design concept to the extreme, you may fall into a worse situation. Nice design reflects a balance between competing ideas and methods. There are several chapters of the title is "gone too far" and describes that when you do a good deed how to identify it.
This book almost all of the examples are in Java or C ++, most of the discussion is an object-oriented language with classes on design. However, these ideas also apply to other areas. Almost all of the ideas are associated with the method may be applied not function language object-oriented features, such as c. Design concept also applies to modules outside of class, such as sub-system or network services.
In this context, let us discuss in more detail the cause of complexity, as well as how to simplify the system software.
Disclaimer: This translation is only for learning to use, belongs to the original author or publisher of English all, if infringement, please contact deleted.