[Recommendation] Twelve principles of extreme programming-simple design

Simple Design: Through all tests, there are no repeated and confusing logic code. A simple design can ensure the simplicity of the Code.

During each discussion of user requirements, the most time-consuming requirements are usually those in some special scenarios. These functional requirements often only occupy 20% of the overall business needs, however, it took 80% of the time to argue about whether or not the requirements and how to implement them. This is the famous 2/8 principle.

Developers tend to be perfectionists and strive for perfection in the development process. We hope that the scalability of our programs will become a common concern once the application changes as little as possible.

What I can't forget is that when I first entered the line, I maintained the program of the "Predecessors" at the customer's site and found a piece of code to implement the "Easter eggs!

I will not write more about the simple design principles. I will repost an article for you, because I think it is very resonated!

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

-All tests passed;

-Reflect all intentions;

-Avoid repetition;

-The minimum number of classes or methods.

It is easy to say. Knowing these standards does not mean that we have followed them. Developers do not like to be confused. The spirit of the experts makes them regard complexity as tigers, but at the same time they understand that the pursuit of simplicity often means a hundred times the effort of design. During the 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 update of the system, and version management, the security of the system and the friendliness of the interface. It is difficult to implement a simple system!

Do the simplest thing that cocould possibly work! This is the slogan of XP (Extreme Programming. There is also a loud saying "You aren't going to need it ". The core meaning of this is not to add unnecessary functions to the software to consider the scalability of the program. Extreme Programming advocates developers not to "Worry". Since it is still to be verified whether the day will collapse in the future, it is better to pay close attention to what needs to be done, at least in a more pragmatic manner. Although this practice is somewhat "too short-sighted", software developers, after all, are not prophet and cannot estimate the future expansion of functions. Instead of spending time and energy to consider the scalability of the entire architecture, it is better to concentrate on dealing with immediate needs. We may bear the huge cost of expansion in the future, but another possibility is that after paying a huge price to solve the scalability of the system, and because the system changes are out of the expected track, the previous painstaking efforts are lost.

Therefore, the evolution design is more in line with the core principles of extreme programming. However, simplicity does not mean simplicity. The so-called "greatest truths to simplicity" means that it is not difficult to import self-simplicity into complexity. Only in this way can we truly need great wisdom. One thing we must understand is that the so-called "simple system" should also ensure its effectiveness. For example, if we want to develop a database management system, we can create a database connection as needed because the database access is not frequent, close the connection once the access is completed. However, as the number of users of the system increases, frequent database access will cause the original database connection policy to become the performance bottleneck of the system. At this time, we need to modify the system, change the existing database connection policy to the Connection Pool Mode to allocate and release connection resources.

If we consider introducing the connection pool from the very beginning, does it mean over-design for simple requirements? Creating a database connection on demand is indeed simple, but is it the most effective solution for the customer's needs? At this moment, we may be accused of over-designed solutions, and perhaps even pushed to the most perfect solutions. Then what standards should we use to judge whether a solution is over-designed, or simple design?

In fact, the question is not whether the design is excessive, but the design concept. Are you only doing what you need now, or are you planning for future function expansion? The answer to this question also needs to be tested by actual project development. The answer varies according to different requirements. The most popular is not necessarily the best. Extreme Programming has its own application scenarios. The iterative development model will become the best software process method in specific scenarios.