According to the normal Internet gameplay, the product manager draws the prototype and conducts the requirements review. After the review, the requirements need to be passed to the technical manager or technical person in charge to conduct a complete set of outline design, and then review the outline design and develop after the outline review . This time let's talk about the architecture of the outline design. Understand the next routine.
Software system design
In the eyes of many people, software system design is to write documents. Writing documents is a burden. In fact, brainstorming in system design is a very happy thing. So we must master what is the design of the system. What are its methodology and how to do some system design.
Do we usually do development and design?
In the few years when I graduated and returned to Zhengzhou, it was just a word of demand. After the development was completed, there was not even a tester in Henan. The developer said that the development was completed and the development was completed, and it was directly given to users for testing. Some users scold their mothers directly, some users feel uncomfortable and cry (the work is not finished), and some users throw things directly. Smarter users directly contact the developer to help him operate. There is no direct test. The user is the tester. To be honest, I told the user how to use it 7 or 8 years ago and how to use it. He feels very mysterious. In recent years, with the increasing number of Internet products and the popularity of smart phones, everyone's requirements for software have become more and more strict. Many colleagues who were used to before have not changed it now. They are really earthy. Later, I didn't actually pay much attention to design, maybe it was just drawing a picture. It was not until later that I exchanged data with a third-party system, and under the hasty design at the beginning, the next 2 months were not well. So system design is a very important job. Rather than what the old irons often say, just write a document.
- Take this keyboard directly.
- After careful consideration and consideration of many issues, we started our coding.
- There is a sentence in the demand, just do it directly, don't ink it.
- When designing, what are developers thinking about? Or is the technical manager thinking about it?
What method is used to do it?
Waterfall process (ignored directly by the Internet)
On the basis of requirement determination, all aspects of system design are designed comprehensively, and each stage has very strict verification conditions, in the mainstream large-scale software development method.
Based on prototype, rapid iteration (commonly used on the Internet)
Many start-up company bosses really like it and feel that the business can be developed quickly, but there are still many pitfalls in it. Few people develop based on waterfalls. In fact, rapid iteration has become a reason for many bosses to let you old iron catch up on projects. I have a list of several hundred million, let users verify first, let users experience, everyone can not delay our great business model, even this development model requires documentation, and there will be many unclear areas about the design, many The pit is in it, including the performance and expansion in the later stage. If the foundation is not built well in the early stage, the muscles will be injured in the later stage. Randomly changing a small function may be necessary for the program. But at this time the boss will not care about you, the testers will not care about you, the product will not care about you, they only know that we meet the business and needs.
What is the specific design
What exactly needs to be designed? If the system does not have a good design, if you are still based on the so-called prototype, rapid iterative agile development uses this as an excuse, the later stage of the program is getting bigger and bigger, when it gets bigger and bigger, it really hurts, and you will not change your system at all. For example, the code in the bank and social security is basically the code 10 years ago. There are a lot of problems in it, but no one dares to change it. This is also a fault caused by the design department.
- Architecture design
1. Specify what a system is, it is the most essential performance in the entire software
When developers look at the documentation, they must first look at the architecture. It is the most essential thing of a software system. The form of the main body and the human skeleton are the architecture. If the architecture you design is a gorilla, no matter how it evolves and develops later, it will never become a human being, it can only be a gorilla. For example, to build a house, you may build a high-rise building, you may build a dirt house, you may build a bungalow, or a cave, and you want to build a high-rise building from the beginning. The materials and the depth of the foundation are all different. So the architecture needs to understand the nature of software design. You can also say architecture.
2. It should be designed to be very stable
Is it a sad reminder to change the foundation? Think twice when developing a design.
3. Design principles
3.1 Adaptability
Meet user needs and achieve business goals. Rather than being crooked by the developers themselves, high-level designers design software that just meets the needs of users, instead of designing the most advanced software at all costs. There is no best, only the most suitable. It is best to build a closed loop. For many Internet projects, it may not be a rigid demand, or a mature business model. If a closed loop is necessary, the opportunity for trial and error is not given, and the cost of development cannot be accepted by the boss, and the boss cannot promote it quickly. Inside the market. The more functions developed, the more powerful the functions, once the business is adjusted, the software will not change well. So it must be divided into many stages. Many development and product managers are prone to this problem, since the beginning of the design, they like to be large and comprehensive, and detailed. Product managers often like to say: "Other people's systems have this function, why can't you do it!" "In fact, you can be so confused and teach him a lesson: "Such product design simply cannot meet the adaptability of product design at this stage!" 』
3.2 Structural stability
We design for relative stability, and we must make sure that it must be relatively stable. If it changes frequently, it is relative to the foundation of the house. You see that the foundation of the house changes frequently after it is built. If the software happens frequently, it would be too tragic. The architecture design is unstable and the scope is not clear. If a system is B2C at first, it suddenly becomes B2B, and the table structure, system modules, and interfaces will all have to undergo major changes. The entire project became chaotic, and the constant changes in demand caused the system to be chaotic. As a result, developers dare not touch the code (to move the whole body), and they all copy a copy of the code. Finally maintain multiple copies of the code. For high-level designers, they have certain experience, and they can know in advance that those needs are basically unchanged and those needs are variable.
Must be derived: variable demand and variable demand.
For example: the design of the message center in the previous project, message center: there will be many types of messages for users. In addition to the PC terminal, the mobile terminal also has a lot of news, logistics news, marketing news, and notification messages. At that time, there was a problem. The actual message center was to receive messages from various channels and then distribute them to various platforms (email, SMS, push, system message information). There was no message center before, and the business side did it individually. In order to meet the atomicity, the atom is immutable. What the message center needs to do is to send the message out according to the needs of the business party, and send it to the corresponding channel, SMS. But the message center is designed after the business platform, and the business platform cannot modify its own business code for sending messages. A monitoring module is specially designed in the message center to monitor an action of the business side. This module is tightly coupled with the business platform. The event monitoring module changes with the business, and the core function of the message center will not change, because the function is very It is purely sending messages, receiving messages, and pushing messages. This is the question of how to ensure stability. Divide on the module. If you need to split later, split the module directly. The monitoring module is changed according to business changes.
Stability will not be driven away by the business demand side, and the project is controllable. Don't worry about the boss having new needs every day.
3.3 Scalability
How easy it is for the software to extend new functions. The better the scalability, the stronger the ability to adapt to changes, especially in agile development. If the scalability is not strong, it is easy to enter a dead end. Distinguish variable and unchangeable. The software volume is approximately small, the stronger the expansion capability, the smaller the ship, the better the turnaround. Why the project is staged is for scalability. The size of the system is definitely limited by business. The larger the project, the more difficult it is to expand, so it must be distributed (application layer, intermediate business layer, atomic service layer), layered (control layer, service layer, data access layer) , The more stable it goes down.
Reasonable division of business modules, split and expand according to modules when expanding. Division of business boundaries.
3.4 Do all systems have to consider scalability when designing?
One-off projects only need to complete the current functions, such as the docking interface of two separate companies. In fact, because it may be one-off, there is no need to consider scalability. If you consider it may become an over-design. If you are an open platform, you must consider scalability.
3.5 Reusability
Once used, you can continue to use it, tools, and public components. Tools must be designed purely (no assumptions about the use environment, less configuration and zero configuration, no dependencies)
- Table structure design
- Methodology
- Table structure design
- Performance scalability considerations
-
Systematic modular design
-
Prototype interface design
-
Design Patterns
-
Data structure and algorithm
PS: I didn't do design before, but after doing the design, it is obviously different from not doing the design. Many are well designed in advance, and the design is easy and controllable. No matter how many theories you have about design, design is a must. Forewarned is forearmed, without prejudging the waste. The design is for developers, testers, and product managers (the design is not biased).