I. Introduction
As a technical developer, especially senior, senior developers, architects, etc., often encounter writing technical solutions based on requirements. So how to write a good technical solution design, let's talk about this topic today.
2. Is the technical solution necessary?
The answer is yes.
I have seen too many due to insufficient pre-planning (even without technical design, open a technical seminar to communicate verbally, and then directly evaluate the construction period), many of which are very important and have a long construction period. In the end, when it came to the joint debugging stage, the various groups couldn't connect together. What's even more ridiculous was that there was no clear communication between the product and the product students. As a result, it was very passive in the end, digging holes and filling holes everywhere, and it took more time and energy, and even led to project delays, weak follow-up expansion and other problems.
So I think technical solutions are an essential part. Often many pitfalls can be avoided at this stage.
The ancients said: "Sharpening a knife is not the same as chopping firewood by mistake", the technical solution is the process of sharpening the knife.
3. How to write a good technical plan
-
It is the general direction to meet the needs and meet the needs.
-
can be implemented. It is necessary to consider whether it can be landed under the current conditions, such as:
-
Acceptability of team members: When selecting technology, the acceptance ability of team members should be considered. Blindly introducing new technologies may cause unpredictable problems.
-
Time cost: Generally speaking, for Java or PHP back-end projects (c language projects may take a year or even longer), the time period of 3 months is relatively long. If this plan is followed, it will take half a year or even longer. That might also be impractical.
-
Resource cost: For example, the project may need to introduce basic resources such as Redis, Mysql, ES, MongoDB, etc., whether the company can provide these resources (servers cost money). If not, when writing a technical solution, you may need to consider whether there are alternatives.
Emergency handling & reliability guarantee As long as people can think of problems, they will definitely happen, and there should be no fluke mentality. So to do a good job of coping strategies for problems, here must be done as follows:
-
grayscale scheme
-
downgrade plan
-
exception handling
-
capacity assessment
4. Technical plan template
The following is the technical solution design template I summarized, and I hope it will be helpful to everyone.
1. Background
The current background status, briefly explain the problems encountered in the past business, give the reasons for this project iteration, and solve the technical pain points or business pain points
2. Target
What kind of business indicators should be achieved through the sub-plan, for example, how much QPS is supported, and how many times the performance is improved compared to the current level, paving the way for later horizontal expansion
3. Overall plan
1) Architecture diagram 2) Flow chart 3) Sequence diagram 4) Call link diagram
4. Storage design
Such as Mysql table structure design, cache design, ES storage design, etc., explain Schema, field type, default value, description information, etc.
5. Interface definition
List the interface structure, parameters, return value, etc.
6. Grayscale scheme
According to what method of gray scale, how to make a gray scale plan, list the gray scale in several stages in the form of a table, and the approximate time of each stage.
7. Downgrade plan
How to downgrade the operation and how to roll back when there is a problem. Minimize risk.
8. Impact of related systems (functions)
The key points that need the attention of each group, the relevant personnel need to pay special attention, and confirm them one by one
9. Resource Allocation
-
Human resources: How much manpower input (development manpower, test manpower, operation and maintenance manpower) is needed to realize the plan, etc.
-
Hardware resources: To implement the above solution, list the physical machine resources needed, and the operation and maintenance personnel need to prepare in advance.
10. Estimated duration and time nodes
List the construction period and key time nodes, such as when to join the debugging, when to raise the test, when to start the grayscale online, and the subsequent iterative improvement plan.
5. Tips
I also summarized the technical solution design documents I wrote for system refactoring (online real version, desensitized), and summarized 2 sets for you. Friends who need it can leave a message "plan" in the background of the official account. Get it, and welcome friends who are interested to exchange and learn together.
