This is the 18th day of my participation in Gwen Challenge
Twitter said
Today I want to share a soft skill that developers should have — document output
Technical solutions have been output for a long time due to business iteration and requirements customization. I’ve gone from hating writing documents to being in a state of mind that’s not as hateful, but still resistant. However, it is still necessary to go to this part of the work, and it is an essential part of the process of technological development.
Scheme criteria
- Simplicity and maintainability: Avoid difficult solutions from an engineering perspective. The dumber the scheme, the more alive it is. Of course, simplicity should also meet the needs of subsequent expansion
- Performance, robustness and scalability: fast is the only thing that can’t be broken, and performance is the root of it. We need to allow some scope for robustness and performance
- Avoid over-design:
- Premature optimization is the root of all evil — Donald Knuth
- Make appropriate design tradeoff – Be the boss
practice
Core requirements and technical difficulties:
Many technical solution reviews go straight to the point in the first paragraph, such as showing a module diagram or storage structure. This can confuse subsequent readers and listeners. It is important to tell the reader what technical problem we are trying to solve first
Project objectives
Only with a goal can we measure whether the technical solution can meet the corresponding degree
Diagram (architecture diagram or work/ Data flow) :
A picture is worth a thousand words
Detailed and clear text description:
Convenient local or document server full text retrieval, for the future people to leave valuable technical assets
Technical indicators:
TP95, QPS, TPS and other system core information description and future requirements expansion support planning
Deployment online solution:
System on-line scheme and gray scale, small flow and rollback scheme (please describe in detail if necessary)