Tool architecture in Internet projects

In an Internet project that requires agile development, do not let a so-called architect encapsulate everything, hide it strictly, and then tell everyone to execute it according to my structure. In this case:
1. This architect will become a bottleneck. He is very tired and the Project Manager is very worried.
2. This so-called architect is usually not only the main force of technology but also the main force of the business (because architects who are not familiar with the business do not deserve to be architects). He often does not have that much energy.
3. The architect has worked very hard to build a beautiful structure and developed a strict specification. After the release of the version, he found that the architecture was inexplicably collapsed. Sorry, I followed up and found that the rules that have been formulated and presented N times have not been implemented. The most basic problem in management: Execution, put in front of, writeProgramExecution is also required. If you have a better temper and find out who has the problem, you can tell it over and over again, just like Xianglin's sister-in-law. A tough guy will launch a penalty rule, and find one, then only the light pole commander is left.
Faced with the third problem, traditional software industry technical architects will generate a bunch of static structures and dynamic structure diagrams to list each article. But now the Internet industry is well-regulated, but it is faster. A project will be available in three months, and every version of the project will be iterated quickly. Product requirements change faster than structural design. Swollen?

I will introduce some of my experiences in Internet project development:
1. Try to split disruptive things into tools and distribute them to members of the participating projects. Then, propose a writing tool specification, such as annotations, calls, naming, and usage rules. All tools provided by members should be executed in accordance with this specification and accepted by an unused person. The standard is to master all key points in a short period of time. The shorter the time, the more successful the tool is.
2. The person who writes the tool must select one from the person who uses the tool. Only then can he know how to use the tool conveniently.CodeDebugging.
3. All team accumulation should be classified tools and then combined based on different projects without a strong "underlying structure ". In this way, we can avoid the deep personal style of team accumulation, so that the team accumulation will not conflict with the frequent changes in demand and the erosion of talent flow.

4. Don't think about what it will look like after a year or even half a year, and then create a huge structure with the accumulation of wood. Honestly works out functions based on the business, and uses resources that have been coordinated by great effort to optimize the UI/UE and service details. At the same time, efforts are made to improve the performance and stability of the client program. Then, you can quickly adjust your business direction and technical direction based on your interests and preferences.

5. the test should start from three aspects: business logic (consistent with requirements) and memory usage stability (whether the program has memory peaks and memory leaks during use), smoothness (such as long list sliding, smoothness during page switching), whether the UI is consistent (ui lookup)

Based on these points, I believe that people who can quickly adjust their technical directions according to business requirements are familiar with the business and focus on product details, people who know that technology is a service for product details and are willing to make efforts for it. People who participate in the project at the same pace through continuous communication are the most important assets of the project.