Principle#1: Reasons for existence
The reason why software systems exist: to provide value to users. All decisions should take this into account. Before specifying system requirements, before focusing on individual features of the system, before settling on a hardware platform or development process, ask yourself the following questions: Does this really add value to the system? If the answer is no, then don't do it. All other principles take precedence over this one.
Principle#2: Kiss
Software design is not an accidental process. Many factors need to be considered in any design work. All design should be as simple as possible, but not too simplified.
The complexity is your enemy. Any fool can make things complicated. Conversely, it is difficult.
——Richard Branson
This is conducive to having a system that is easier to understand and maintain. But it does not mean that the function should be abandoned in simple names, and even internal functions. Of course, it is usually more elegant often means simpler.
Simplicity is the ultimate sophistication.
——Leonardo Da Vinci
Simple does not mean fast and dirty. In fact, in order to simplify, we often need a lot of thoughts and iterations. Harvest is easier to maintain and not errors.
This has always been a motto of mine – focus and simplicity. Simple may be harder than complex; you have to put a lot of effort into making your thinking simple and organized.
——Steve Jobs
Principle #3: Maintain the Vision
Clear vision is essential for the success of software projects. Otherwise, the project will basically fall into a swaying situation. Without the integrity of the concept, the system is likely to be a piece of pieces of unsatisfactory design -connecting the wrong screws.
Concept integrity is the most important factor to consider in system design.
——Fred *s
Establishing a clean internal structure is essential for the construction of an easy -to -understand, scalable and reorganization, and maintenance and testable system.
——Stroustrup
Only with a clear understanding of the system architecture can it be possible to discover common abstractions and mechanisms. Taking advantage of this versatility will ultimately make the system simpler and therefore lighter and more reliable.
- Grady Booch
Compromising the architectural vision of a software system can weaken and ultimately break a system, even a perfectly designed one. Having an empowered architect who can realize the vision and enforce compliance helps ensure the success of a software project.
Principles#4: Production of things consumed by others
Few industrial-grade software systems are built and used in a vacuum. Others will use it, maintain it, record it in some way, or other ways that rely on being able to understand the system. Therefore, always specify, design, and implement understanding that others will help you understand what you are doing. The audience for any software development product is likely to be large.
Specify the user. Design, keep in mind the executor. Pay attention to the code that must maintain and expand the system. Some people may need to debug the code you wrote, which makes them become your code user. It is convenient for them to work to add value to your system.
Principle#5: Facing the future
Systems that last longer have greater value. In today's computing environment, when specifications change in a blink of an eye and hardware platforms become obsolete in a matter of months, software lifespan is often measured in months rather than years. However, truly industrial-grade software systems must last much longer. To do this, the system must be able to adapt to these changes. Systems that can successfully achieve these goals are designed this way from the start. Don’t ask for trouble when designing. Always ask "what if" and be prepared for all possible answers by creating systems that solve general problems, not just specific ones. This is likely to encourage reuse of the entire system.
Abusing this principle is where I see a lot of developers go wrong. One of the benefits of having years of experience and many of them working on a single project is that you can learn about YouArentGonnaNeedIt's strengths. As developers, unless we are also experts in the field, we often guess wrong about how the system will change.
The system does change, but it usually returns to the same way, so the broad solution becomes a baggage.
——Sal Mangano
Principles#6: Pre -planning reuse
Reuspecting can save time and energy. To achieve high -level reuse can be said to be the hardest goal of developing software systems. The reuse of code and design has been claimed to be the main advantage of using object -oriented technology. However, the return of this investment is not automatic. In order to use the possibility of reuse provided by object -oriented programming, we need to consider and plan in advance. There are many technologies for each level of the system development process that can be used to achieve reuse. Detailed design and code -level reuse technology is not only well known but also document.
A new literature is looking for design reuse in the form of software patterns. However, this is only part of the battle. Communicating reuse opportunities to others in the organization is critical. How to reuse something you don't know about? Planning reuse ahead of time reduces costs and increases the value of reusable components and the systems in which they reside.
Principles#7: Think twice!
This last principle is probably the most overlooked. Developing a clear and complete train of thought before taking action almost always yields better results. Only when you think about a problem are you more likely to solve it. You'll also gain knowledge on how to do it correctly again.
If you do consider something, but still do wrong, then this is your precious experience. Another result of thinking is the process of how to study the answer when you don't know what you don't know.
When clear ideas enter the system, value will be produced. Applying the first six principles requires deep thinking, but the potential rewards are immeasurable.