Architecture and specification of the Java Advanced Programming-react project

Architecture and Specifications
What does the architecture do to solve the problem? I understand the problem of efficiency. With a good architecture, you can easily and consistently understand a system, based on which business functions can be completed quickly and sustainably. It is guaranteed to have three points:

The code base is easy to read.
It's quick to add new features, ideally, just add business-related code, things like style, infrastructure, on a more mature project, should be more stable.
In the process of evolution, you can still keep adding functionality fast
What are the criteria for solving the problem? I understand that collaboration is a problem. Everyone a team work, naming habits, code style, different levels vary, how to ensure the overall quality and style appearance? By the norms of Bai.

So what are the examples of architectures and specifications?

Architecture
such as directory structure, component hierarchy, state management, side-effect management, routing system, UX system (style scheme), buried point design, test strategy, continuous integration, build method, deployment method, etc. belong to this column. As you can see, in order to develop a business function, you may need so much infrastructure support underneath. The purpose of the architecture is to make the most possible operations (such as routing, embedding, UX consistency, etc.) into a constant-level operation, or even the default standard operation, so that you can develop smoothly, so that only the part of the business concerned.

directory Structure: This issue is closely related to component hierarchy issues. In the app scene, it is not the same as the Web, the app is often the home routing + card stack page. How to map the page structure to the directory structure, how to maintain clarity? Do you follow the Duck directory structure design approach or the functional directory structure approach? If the small project selection starts from the functional type, is there a migration path to the duck structure? How much manpower is needed?
Component hierarchy: is the structure divided by Presentation component, container component? Or is it not care?
State management: React Context, MOBX, redux, how do I choose?
Side Effect Management: promise scenario? Thunk program? Saga program?
type system: TS. The architectural abstraction capabilities of a language-level type system
routing system: How do I make page additions and deletions into constant-level operations? How to support many different rendering modes (do not uninstall/uninstall)?
UX System: How do you maintain a high level of consistency with UX design? How do you guarantee that this consistency can be achieved with only constant-level operations? How can you make sure that only constant-level operations are needed to change and try out a new UX design?
buried point design: data is the product of this, how to design a buried system, so that its business code to minimize the intrusion? How to maintain the flexibility of fine-grained burying points? How do I make the buried point a constant-level operation? How is the buried point data structure designed? How is statistics counted? What report do you want to generate? How does the build of the report do constant-level operations (i.e. no manual script is required to do statistics)?
Test Policy: What is measured? What's the test? How fine is the test? Who's the test? Need to develop a test strategy that can be landed
Continuous Integration: development Method (branch or trunk)? At what stage are automated tests run? How do I make a continuous integration configuration into a constant level (without needing to manually re-use CI each time I change the machine)?
How to build: What tools are used for automated building?
Continuous Deployment: deployment Destination? Deployment frequency? Is it possible to deploy each commit? Can you prepare the UAT environment as close as possible to the production environment? The
specification
, such as code style, programming style, naming style, submission information, submission granularity, development habits, code cleanliness, unit tests, etc. belong to this column.

Code Style: Prettier one-click Solution
Programming Style: Eslint try to cover
naming style: after clarifying the basic principles, write the README to do the Constitution + Glossary
Submission Information:precommit hook, but can not standardize to the information level, and the submission of information is related to the granularity of the submission
commit granularity: the part that is more difficult to unify. I'm going to put it in the architecture section.
Development habits: A part of self-abandonment. such as TDD, etc.
code Cleanliness: Basically can only use code review + PR to standardize. This is related to whether the developer is a livelihood or craftsman mentality, and whether the organization is the organization of technical attributes or the organization of political attributes.
unit Test good or bad: clear the standard of testing, develop test strategy + write the README to do the Constitution + code review regular feedback
Other welcome additions.

Architecture and specification of the Java Advanced Programming-react project