1. Moderate Design (The first criterion)
A) The architecture should be designed to meet the needs of a certain period of time.
The cycle is generally considered a year, and the requirements include both functional and non-functional (optimization, extension, etc.). The architecture should be as simple as possible in both cases, with some foresight: lower costs, shorter implementation cycles, and higher quality.
Each additional component, including RESEARCH and development, testing, operation and maintenance, and hardware resources, may increase the overall cost of tens of thousands of yuan.
There are some advantages to microservices, but the disadvantages are also obvious: increased response time, higher overall costs, and higher administrative complexity. For small to medium sized systems that don’t need frequent releases, adopting a microservices architecture is like killing a bull.
2. Avoid making the problem bigger
A) Try to solve a problem directly rather than indirectly and introduce new problems.
I. For example, when we used plug-in A, we found that it had some problems, and then we introduced plug-in B to solve the problems of plug-in A, and so on. The correct approach is to replace the A plugin directly to avoid causing new problems.
3. Essential thinking
A) As an architect, you should have a wide range of knowledge and be able to see through the phenomenon to the essence of the problem.
One thing that impressed me deeply in my mind was that once we made a file uploading function. At the beginning, some users gave feedback that the uploading speed was too slow and sometimes the uploading failed. We all thought that there was something wrong with the user’s network, until later, some customers gave feedback about this problem. I realized right away that this was definitely not a network problem, but a single file that was too large and IIS limited. The subsequent solution was to adopt sharding upload and modify IIS restrictions to solve this tricky problem.
4. Technology selection is based on demand rather than personnel status
A) It is often seen that when making technology selection decisions, one chooses the technology mastered by the current team despite knowing that a certain technology is the best. This kind of decision is understandable, but it is not good for the long-term development of the product, and it is very likely to fall behind in the PK with competitors (performance and user experience).
B) The most classic saying in the technology industry: there are no technical problems that can’t be solved, only people who can’t solve them. Always believe that projects can drive the technical development of the team.
5. Focus on cost
A) Many architects may have the mentality that if they design the architecture simply, they will appear mediocre. They can show their ability by creating a high quality architecture, and they can also be good at presenting their work to the leaders. However, if you go too far ahead with this complex architecture, it will cost you nothing.
B) Every decision an architect makes has an impact on cost. Including research and development costs, third-party software and hardware procurement costs and operational costs after launch. The cost distribution and final total cost will vary from one solution to another. It is often necessary to make comprehensive trade-offs to decide the optimal cost scheme.
C) Cost is related to corporate profits and will eventually affect individual bonuses. Although the cycle of this causal relationship is longer and not very transparent and direct, the truth is not wrong. Before you make a decision as an architect, ask yourself how much the solution will cost.
6. We should adopt principles, but not mechanically copy them
A) Some people do design entirely by imitation, not from the actual situation of their own system; Others, on the other hand, take matters into their own hands and do not investigate the design of similar systems. Neither is desirable. We should start from the actual needs of our own system, on the basis of referring to other people’s mature cases, avoid detours, and consider the characteristics of our own system, and give a design in line with our own needs.
7. Focus on process (consistency and maintainability of projects)
A) Now that the era of FTP uploading is long gone, it is important to think about tools and processes to build an efficient and error-free workflow.
B) Workflows are becoming more complex, as are the tools that use them. These tools have yielded amazing results in increasing productivity, speeding up efficiency, and maintaining code consistency. For example, the preparation of the environment, there are test environment, production environment, backup environment and so on, each plate is not related to each other, there is no need to panic if there is a mistake, there is a backup version.
8. Performance testing
A) Not satisfied with the implementation of business functions, but to consider performance and response speed.
B) Site performance baselines are essential to compare with industry averages and common best practices.
C) Recommended HTTPArchive(Httparchive.org/), which tests and records performance data for hundreds of thousands of websites.
D) Data analysis
I. Page size: 2061KB
Ii. Total requests: 99
Iii. Proportion of cacheable resources
E) If you want your site to be faster than most sites, consider setting a goal: a 1648KB site with 79 requests, 44 of which can be cached, which would put your site 20% ahead of the average.
More front-end advanced knowledge, all in the Bright top of the WEB education (web.xingruanedu.com)