Beginner's Introduction: A detailed interpretation of the seven Principles of software development

First principle:

Reason for existence (Pattern:thereason) The reason for a software system is that it provides value to its users. All of your decisions depend on that. To specify a system requirement, write down a piece of system functionality, ask yourself a question before deciding on the hardware platform and the development process, "will this add value to the system?" "If the answer is yes, do it." If it is "no", do not do it. This principle is the principle of other principles.

the second principle (can be simple, stupid!) Software design is not an understatement of the process

You have to take a lot of factors into consideration when doing any design. All designs should be as simple as possible, but not simpler. The resulting system is understandable and easy to maintain. This is not to say a lot about the nature of meaning, because this simplicity is also to be discarded. Indeed many more elegant designs are often simpler, but simplicity does not mean "quick and dirty." In fact, simplicity is achieved through many reflections and repeated revisions. These efforts are reported to be easier to maintain and fewer code errors. (see if it's a violation)

3. Third principle:

Keeping a Vision (pattern:maintainthevision) A clear vision is the foundation of a successful software project. Without such foresight, project development finally becomes a daily fix for a bad design. Brooks said: Conceptual integrity is the most important problem in system design. Stroustrup also said: There is a clean internal structure to build an understandable, identifiable, maintainable, testable system. Booch concludes that only when you have a clear sense of the system's system can you discover common abstractions and mechanisms. Developing this versatility ultimately makes the system simpler and therefore smaller and more reliable. If you keep copying, pasting, and modifying code, you end up in a big quagmire (the large mud), and you'll never have a clear understanding of the system.

4. Principle IV:

You make, others will consume (Pattern:whatyouproducetheyconsume) the software system is not used in a vacuum. Other people will use, maintain, and document your system. It depends on the understanding of your system. So, what you design and implement should be able to make others understand. Keep in mind that the code you write is not just for the computer, you have to keep in mind that the code is still to be seen. (Kent Beck) How can someone discern the similarities and differences of the code, and how to understand the relationship between them, if there is a pervasive flow of plausible code?

5. Principle Five:

For the future open (Pattern Buildfortodaydesignfortomorrow) A successful software has a long lifetime. You have to be able to make the software adapt to this and that change. So, in the beginning, do not design software to a dead end. Please always ask yourself "if so, then ...?" "This problem, you have to take into account a variety of possibilities, not just a picture of the convenience." Copy, paste it.

6. Principle VI:

Planning software patterns for reuse is a kind of reuse plan. Repeated code is clearly not such a plan. (Commentsonsix)

7. Seventh principle:

Thinking! Do a clear and complete consideration before taking any action to produce better results. If you think about it, but it still produces the wrong result, it's worth the effort. It is easier to understand and master when you are learning or studying similar problems.

These principles tell us that it is not possible to easily copy, paste, and modify code, that is, code that is easy to understand, maintain, and reuse. But please do not go to extremes. I have always thought that a good software system is the result of various factors, that is how you grasp a degree of problem. Another major reason for repeated code generation is that it's done too much, and XP has a basic principle called you arent gonna Need it, which says "Just realize what you really need and never do what you expect." If you're going to achieve what you think you need in the future, it's not necessarily what you really need later. You may not be able to understand what you want to achieve in your current environment. You'll waste a lot of time building the possibility that you don't know if you have to. At the same time, you can generate duplicate code when you actually implement it.