Introduction: Before the review of the architectural plan or technical plan, you must be very distressed. After many revisions back and forth, you still cannot express the intention of the plan. Here are some commonly used technical solutions and architectural solutions.
Why do we need to write technical solutions? To sum it up, it is nothing more than a few points, from the perspective of different people:
- Product: Verify whether the technical solution can match the product solution
- Test: verify whether the technical plan has sufficient & accurate input to the test plan
- Colleagues & leader: Participate in the review of technical solutions and verify the rationality of technical solutions
- Newcomers (not just new students but also students who are new to this area): get a technical solution and get familiar with a certain area quickly
Conclusion: The essence of the technical solution is to ensure that the expressed solution can match the solution of the problem, and can solve the matching degree and logical deduction process of the user's problem at the minimum cost.
What kind of technical solution is a good technical solution
We all know that the technical solution guides the specific development work, and we can discuss this issue from before, during, and after the development.
advance
- Clear goals: What is the purpose of the entire technical solution and what problems do users solve?
- Low communication cost: Product testing can obtain enough input from the technical solution, and there is no need to repeatedly ask you for confirmation
- Thinking about technology selection: why do you want to do this? Compared with the industry solutions, what are the advantages and disadvantages, and how to weigh them
- Decision-making trade-offs: think about fundamentally solving user problems, what needs to be done, what does not need to be done
in progress
- Less adjustment: As few technical solutions as possible need to be adjusted, otherwise the development task cannot be completed
afterwards
- Fewer patches: as few bugs or omissions as possible
- Scalable & Reusable: Relatively simple changes can support new requirements, and similar scenarios can be reused without repeated development
A good technical proposal can run through the entire R&D life cycle, and can play a very good guiding role, just like the logic that the author must draw up an outline before writing a novel.
How to write a good technical proposal
So, how to write a good technical proposal? Below are some points that I think should be done.
Clear goals
A technical document needs to have a clear goal (it is recommended to summarize the business requirements instead of Copy from PRD, if the technology is spontaneous, it must be summarized by itself), how did the goal come about? It is transformed from the demand. So, how do you translate the corresponding needs into a clear goal? I think the most important thing is to try to define a measurable standard. Generally speaking, there are two types of requirements, namely:
1. Product requirements - proposed by the business side or the product side to the technology, including but not limited to the following:
- Page interaction: How much operational efficiency can be improved, and how many quantifiable figures such as PV and UV?
- Business SOP adjustment: What is the business value brought? How much cost can be reduced or how much timeliness can be improved?
- Data Revision: What problems does the revision solve? How much money is prevented from being settled? Or how many customer complaints are prevented?
2. Technical requirements - spontaneous technical requirements, including but not limited to the following:
- Performance optimization: how much to optimize? 20%, 30% or 50%?
- Data isolation: What is the scope of isolation, how many tables are involved, and how much data? What current problems can be reduced? By how much?
- Gadgets of all kinds: What was it like without gadgets? What is it like after that? What benefits can it bring?
- R&D Efficiency Improvement: By How Much? Are there any quantifiable indicators? rather than doing it for the sake of doing it.
Among the many requirements, there are still some pseudo-requirements that we need to identify—not the requirements that the user really wants, such as the user wants to transform an aircraft into a rocket, but the product may only bring two parts of the aircraft. If the wings are cut off, can you turn into a rocket by cutting off the wings? Obviously not, so this kind of demand must be identified carefully.
Outline diagram
There is a saying that "one who does not seek the overall situation cannot seek a domain", and I think the same is true in technical solutions. In a technical solution, an outline diagram is indispensable. Some people call it a technical architecture diagram, and some call it a data flow diagram. It is not important. What is important is that we can see the overall Context, so what are the main points that this picture needs to have?
- The picture does not need to be very detailed (for example, if the processing is more complicated, we can simply write **processing), but we must be able to see the whole picture. If each specific module needs to be expanded, then it can be reflected in the corresponding detailed design. Here we pay attention is the whole;
- If the interface belongs to different applications, it should be marked;
- Different data storage media should be marked;
- The arrows of data flow should be clear;
- The input and output of data processing calculations should be reflected, and the operating environment of processing should be reflected at the same time (for example, whether it is odps computing or memory computing, and if memory computing is used in which application).
Schematic Reference for Outline Diagrams
model design
When it comes to data model design, ER diagrams are essential, and ER diagrams should contain the following information:
- Each domain object, if it is to be persisted, has a table to store it. When we finish designing the ER diagram, we should check it according to this principle to avoid missing some tables. In large projects, missing tables are very common and should be avoided as much as possible.
- If the relationship between domain objects is to be persisted, it must be reflected in the table structure. This embodiment may be a code field, a foreign key, or an intermediate table. When we finish designing the ER diagram, we should also check it according to this principle to avoid missing some relationships. In large projects, missing relationships are even more common and should be avoided as much as possible.
- Clearly defined table names. When designing an ER diagram, it is necessary to design clearly defined table names. Clearly defined table names can help you understand the ER diagram and map back to domain objects and their relationships. In the subsequent design and implementation, this table name will be used.
- Clearly defined field names, field types, field lengths, and enumeration values. Many students tend to overlook this point. They often clearly define the table name, but do not pay attention to the fields of the table. When you do it seriously, you will find that there is a lot of work in it. For example, whether the field name is appropriate, what type to use, the appropriate length of the field, whether there are enumeration values, etc., all need to be considered one by one. If this is done well, a lot of trouble can be avoided during implementation, and even rework can be avoided.
Confirmation of external dependence in advance
Technical solution 1: It needs to rely on cache, distributed scheduling middleware, and consume external messages, but the corresponding middleware usage method and data format are not posted.
Technical solution 2: Need to rely on cache, distributed scheduling middleware, and consume external messages, clearly write the cache access method & corresponding cache key-value design, and prepare dependencies for distributed scheduling middleware access Sort it out, and list the topic and data format corresponding to the export news.
The comparison between the two schemes is actually quite obvious. If we determine the external dependencies in the technical plan at the beginning, then we will be flat when developing. On the contrary, if the external dependencies are not sure and enter the development, then the probability of rework will be greatly increased, thereby reducing our cost. work efficiency.
So, what are the external dependencies and what information should we confirm? Some common dependencies are listed below:
- External hsf dependency: It is necessary to confirm the class, method, version, and second-party package corresponding to the hsf interface (generalized calls can also be used);
- External message dependency: need to confirm the topic and data format of the message;
- Middleware such as distributed scheduling and caching: Whether the current application has accessed the middleware, if not, you need to go to the official website to confirm the access document, and if you access, you need to confirm whether the access logic can be reused.
Internal Front and Back Module Dependencies & Hierarchy
The module dependency level is divided into from high to low:
- domain-dependent (such as transaction-dependent commodities)
- Application dependencies (eg cntcp application depends on cngfc application)
- Interface dependency (for example, scrolling kanban query interface depends on lock interface & channel set interface)
Let's take an example of interface dependency: there are three interfaces in total, which are rollover kanban query interface, lock interface, and channel set interface. The rollover kanban query interface depends on the lock interface and channel set interface.
Technical scheme 1 catalog level: rollover kanban query interface, lock interface, channel set interface;
technical scheme 2 catalog level: lock interface, channel set interface, rollover kanban query interface.
Obviously, technical solution 2 is more reasonable. If A depends on B, then B should be done first.
When we write technical solutions, we should consider what should come first and what should come after, instead of trying to write one step at a time. Have a clear, orderly structure, otherwise it will look disorganized to others.
What should be in a module
The following lists what should be written in the module of a technical solution for reference:
1. Specific interface definition
Requirements: Realize an aircraft transportation capacity contract query interface, and the input parameter is the transportation capacity region
Technical solution 1:
入参：
{
"area": "南美"
}
出参:
{
"date": "***"
}Technical solution 2:
方法名：CapacityService.queryPlan
入参：
{
"cnArea": "南美"
}
出参:
{
"date": "***"
}Solution 2 is better, why? The tester, the front-end, and the people who will take over the interface in the future can all find your interface at once and know exactly what the input and output are. In addition, the input parameters of 1 and 2 are one area and one cnArea, so which one is more correct? Since cnArea is used in the system here, it is correct to use cnArea (consistency reduces communication costs).
Here is a summary of the requirements for the interface definition:
complete class and method names
If the entry field exists in the system, it will be used; if not, then the English description needs to be accurate (discuss with the product business)
The output parameter field requirements are the same as the input parameters
2. Detailed sequence diagram
Requirement: implement a student information query interface.
Technical solution 1: Write out the relevant steps performed in the query results.
step1. 入参校验
step2. 查询A表
step3. 对A标返回结果做校验
step4. 查询B表
······Technical solution 2: On the basis of 1, use the timing diagram to express it.
It is recommended to use technical solution 2. The advantage is that although the content is the same, the sequence diagram can more intuitively see information such as hierarchy and data flow.
In addition to the above two basic points, I think there are some other points:
- Detailed diagram of data processing (if any) - it is also recommended to use the form of diagram to be more intuitive
- Message design (if any), specify message producer, consumer, tps, data structure
- Self-test use cases (recommended), construct some self-test use cases for more important function points
······
Technology selection analysis
Requirements: Implement a scheduled task to delete expired data periodically.
Technical solution 1: Use spring's built-in timer to clear data.
Technical solution 2: Use distributed scheduling middleware (such as schedulerx) to clear expired data at regular intervals.
At first glance, it seems that it can be achieved, but after carefully comparing the two implementation methods, I think most people will still choose technical solution 2. Why? Listed below are some points to consider when choosing a technical solution.
Safe Production
Safe production includes several parts, including but not limited to the following parts
- monitor
- reconciliation
- grayscale scheme
- data isolation
- Compatibility Assessment
- release process
Let's take an example.
Requirement: Trigger settlement to the merchant when the consumer receives the goods successfully.
Technical solution 1: I have written a bunch of how to trigger settlement and how to better support subsequent scalability;
Technical solution 2: The scalability of the written solution is not as high as technical solution 1, but the monitoring of untriggered settlement has been done. , Trigger the reconciliation after settlement, and design the corresponding report to prevent capital loss.
In fact, this is also a point that we may overlook in the technical solution-it is good to bury our heads in the code structure, but some things are actually more important than pure code. For example, risk control, complete monitoring, and indispensable reconciliation are tools to ensure the safety of the company's funds and our own performance (there should be expressions here).
So what are the specific requirements for monitoring and reconciliation? I think there are following points:
monitor:
- Monitoring objectives: write clearly what is being monitored
- Monitoring point: If you monitor by printing logs, which method of which class the logs are printed on
- Monitoring trigger: is it triggered by sunfire collection or other, if it is sunfire collection, it is best to post the address of the monitoring item
- Monitoring subscribers: Subscribers required for monitoring alarms
- Solutions after monitoring triggers: How to solve if an exception occurs? Such as manually triggering settlement
Reconciliation:
- Reconciliation goal: write clearly why the reconciliation is
- Reconciliation method: write clearly how to reconcile accounts (for example, through odps day-level timing tasks, the customs resource code on the fulfillment form and the customs resource code in the customs cp return message in the log table must be consistent, and if they are inconsistent Form a data set and configure it through the Jinyiwei-asset loss risk platform)
- Reconciliation Alert Subscriber
- Solution after reconciliation exception
There are a few other parts to add:
Grayscale schemes, including but not limited to:
- Multi-party pre-preparation
- Design of grayscale cut-off switch
- Gray scale cutting rhythm
- Abnormal response
Forward compatibility, including but not limited to:
- Forward compatibility of interfaces: especially external interfaces
- Forward compatibility of data structures: For example, the storage type and format of fields cannot be changed at will
Environmental isolation:
- If there is tenant isolation & pre-release online isolation, data needs to be considered
Release process, including but not limited to:
- release plan
- check list
- Release traffic monitoring