Let's talk about some ideas about software architecture design.

Let's talk about some ideas about software architecture design.

Premature software optimization is the root cause of all evil

 

When I was working on a project, some colleagues always considered Performance Optimization in advance, and demand changes were a lot of rewriting, reminding me of what Donald knuth mentioned: premature software optimization is the root cause of all evil. Here are some important software celebrity philosophies.

The only constant change in the software is the change.

In the process of software development, the demand is constantly changing. With the customer's understanding of the system, as well as the existing development functions and software, maybe the demand he proposed at the beginning is different. I remember a joke on the Internet about the change in demand:

The programmer XX experienced a car accident and became a plant. The doctor said there was only one thousandth of hope to survive, making awakening even more slim. But his lead and his loved ones did not give up. According to XX's life-like style of work, they read around him every day: "XX, the demand has changed. It's time to work. Come on! ", The miracle finally happened. XX woke up. The first sentence: "what? The demand has changed ?"

In design and architecture, everything is absolutely absolute. As an architect or project leader, you must always clearly understand that there is no perfect architecture and design, and there is no omnipotent software. Only suitable solutions in the current environment, demand solutions, team personnel quality, physical environment, security, and other factors exist, for various reasons, your solution may not be the optimal solution under a single factor. What you need to do in this position is to find the optimal solution under this comprehensive situation and create a balance. Don't simply say how bad a team's solution is, or that is the optimal solution of the overall factors at that time. You may not necessarily do better in the same environment. In architecture design and life, it seems very similar to me. There are always a bunch of choices, and every decision will lead to a loss and a trade-off.

Kiss :( Keep it simple, stupid)

Keep it simple, but it is too simple. As mentioned in programming philosophy under UNIX, we can clearly see this principle by keeping the design simple for many times. Nowadays, visual design advocates simple design, which is simple but not vulgar, rather than a lot of luxury. Visual Design started with vbprogramming. You can see the Google homepage and business style. In our software design, we also need a concise design. What users need is the correctness of the visible and quantifiable functions, rather than using the technical model of multi-Bull B, however, it is not too simple. It is easy for you to complicate simple comments, but it is not easy to simplify a complicated thing. A simple life is happiness. However, it should be noted that simplicity is excellent, but simplicity has a bottom line boundary, and simplicity beyond the bottom line also becomes childish. For example, the transaction Script Mode is simpler than the common mode in the other three, but it is often complicated because it is too simple because it is not the optimal solution.

Abstract Programming

In the design mode, architecture mode, and OO, they are all the main lines and exist as the first principle of OO. I can't remember which software cool once said: please remember not to start implementing without interfaces. This sentence may be too radical, but if your interface is understood as unchanged or not easy to change, understanding or contract (company and your contract) it is more appropriate (it may be a constant class. If you can say for sure that your implementation will not change in project development and maintenance in the future, I think this is also an interface, and the interface is unchanged and not easy to change). You may agree to this sentence. For the current requirements, you must be able to write perfect code without an abstract interface, but the only thing that remains unchanged in the software described in the first article is the change, can you be excellent in the future? If not, I think it is necessary to provide extension for the future in the face of the current demand.

I personally understand that most of the 23 design patterns focus on this program to an interface, not an implementation (dependent interface rather than implementation) Principle 1. Of course, we cannot leave the second principle behind us: combination takes precedence over inheritance. In the future, any dip (dependent inversion, IOC principle), LSP (lining replacement), OCP (open and closed principle), and so on will be their extensions and extensions. In tracing, these columns are for the software system "High Cohesion and low coupling" (which can be briefly described as: interfaces (low coupling) are used between fully functional (High Cohesion) objects) communication interaction), cohesion is the degree of functional completeness described, and coupling is the degree of dependency between presentation modules. Here, a colleague told me that there is no dependency on the dependency interface. What I hope is that there is no coupling. My answer is: The computer's principle illustrates all this, since things come together, it is no accident, so there must be dependencies between them. What we can do in software design is to introduce intermediate objects to turn them into indirect dependencies, while reducing the dependencies between them, we hope that this intermediate object is relatively stable. Everything in the design is a word: indirect, layered, MVC, MVP, SOA, middleware and so on all reflect direct dependency to indirect dependency. The reason for talking about this topic is that it leads to the effective method SOC (separation of concerns) of "high cohesion and low coupling". This is not only oo's theory but also effective for process-oriented programming, he proposed it in SP (structured programming) 20 years ago.

Maintenance, scalability, and post-event Optimization

This is also the cause of this Article. As mentioned in the beginning, Donald knuth mentioned that premature software optimization is the root cause of all evil. During development, we do not need to optimize any performance. Even if you think there may be performance bottlenecks, you need to consider more about design expansion and extension, add new functions and maintain them later. Performance optimization is often used as a better experience for user needs. Performance optimization is required only when a performance bottleneck occurs. A Scalable, scalable, hierarchical, and clear code module is easy for your optimization, you can get more optimization solutions based on your understanding of the overall needs of the project at the end of the project. Optimization is also promoted in the reconstruction mode. Premature optimization leads to a deeper project. At the end of the day, you will know that users do not need such high requirements or feature modules that are not commonly used by users. There is also a standard for optimization, the amount of time the user can endure, and the current time. Often, users only need a small number of common operations for performance requirements, while changes to functional requirements are endless, and maintenance costs are high.

Finally, it is often said that reflection performance is low, and we must acknowledge that reflection is inferior to other solutions, but we have a solution: cache. What is the standard for low performance? What is the degree of acceptance of the user? Reflection we can have an alternative emit and Expression Tree. The selection of reflection, Expression Tree, and emit is difficult to use, development efficiency is increasing, and performance is improving. I usually prefer Expression Tree.

Inheritance is for Polymorphism rather than reuse.

In Oop, you can write a class, and then I can continue to inherit and reuse to expand new requirements. This is the reuse of classes. Is it all the reuse? The word Reuse may seem more subtle. Polymorphism is one of the core features of object-oriented, and it cannot be remembered that reuse is only a supplementary feature of inheritance. In our inheritance system, it should not be huge. If a hierarchy with 4 or 5 layers is difficult to understand you, And the integration system must be a clean inheritance system, to meet the LSP (lean replacement principle): You can replace it with a subclass in all areas where the parent class is used, and work properly and accurately. This requires you to inherit more from modifying the behavior of expanding the parent class and avoiding the status as much as possible. Inheritance is just not intended for reuse. A better way at the right time is to implement a complete class to replace the class that cannot meet the existing needs. This is also the second principle of the OO principle. The combination prevails over inheritance. Combination, for example, the policy pattern in the design pattern, you get an algorithm combination. The number of functions is a Cartesian product. But it is also an absolute combination. It is only a priority, not a replacement. The software and the real world are full of contradictions. Just like the first article in the beginning, "the only constant in software is change", it is the biggest contradiction, from dialectical materialism, what you need to do is to weigh the balance. The combination represents the overall replacement, such as the overall replacement of the algorithm in the Policy mode. Inheritance is a small amount of extended modification behaviors, such as the template scheme in the design mode. Under the process control of the parent class, the modification of some steps, data, and transaction flow control are in the parent class. The last sentence of this article is: the design model is not omnipotent. It is only the excellent experience of our predecessors and relies on scenarios. I think it is more important to understand the design model, it may be better to use this mode as a solution when you meet similar scenarios. It is only a solution for your choice.

All user input is evil.

User input is out of our system and cannot be controlled and cannot be listed. For users, the software is only a black box, and there is no need to understand the specific internal implementation. Car sales personnel do not need to know how engine bolts are built. They know what advantages they can offer to users and what kinds of requirements and prices they offer? Performance? Speed? Luxurious ?.... For portal websites, you are not only a trusted user, but may also be attacked by competitors. If your system trusts user input, it will always be "out of stock" sooner or later. A user input, intentionally or unintentionally, can cause a complete functional breakdown of your system, you should not restrict user operations. You cannot command the user to enter anything and cannot enter anything. For example, if someone uses the user one day, the user may be in a bad mood because the user may be in a lower salary or get approval, you may try to challenge your system.

Speaking of this, I would like to say that some logic such as verification was moved to the unit test to ensure that the automated test server has been running for too long. For my understanding, automated testing is similar to integration testing. Functional testing should be black box. In unit tests, we always assume that the input is correct and a dependency is correct to verify that the output is correct. However, the focus of integration testing is that these are all hierarchical combinations and integration, and there is no assumption of correctness. Only test cases from testers can be output as expected.

I will write it here today. There are many more, but I cannot think of it. If I have the opportunity in the future, I will continue to make up for the important ones.

The reality is contradictory, with no perfect design or absolute simplicity. The same is true for life: simplicity is happiness, and happiness is happiness. So What Are simple standards? How is happiness? This lies in your own choice and trade-offs. Think of an interview with a small company interviewer, the interviewer said that ORM has performance problems, and has been entangled in talking against DDD, against the pattern. I am talking about the solutions to the performance problems. First, how should we do this? What should we do if we cannot meet the requirements? From the index cache to the table sharding service cluster: architecture, such as life, always has to face a trade-off.

Let's talk about some ideas about software architecture design.