This is the second day of my participation in the More text Challenge. For more details, see more text Challenge
preface
Project related
This may not seem like an important part of the project, but it is important to know the key information about the project. Because maybe when we’re talking to other people who don’t know what we’re doing right now, we’ll ask some of the following things.
Project background
Through the project background to understand the current business pain points, want to achieve what effect through our products. For example:
- A: Marketing growth (e.g., inaccurate prediction of individual orders, insufficient visualization of store operations, lack of effective management of members, etc.)
- B: Supply chain (e.g., production and sales forecast do not match, logistics distribution may have food safety risks, etc.)
- C: Sharing and organization ability (e.g., slow payment, low reconciliation efficiency)
- D: Technology and architecture (e.g. lack of synergy among existing systems, performance and functionality affecting business, etc.)
Project vision
Take a corporate project: it’s easy to say here. Build a complete business application based on the middle platform architecture, realize the whole business process, realize the online business implementation and unified data aperture, and realize automated marketing, automatic financial account checking and continuous optimization through the middle platform capability.
What is the project value
- Increase your income
- Promote efficiency
- Reduce the cost
- To strengthen the internal control
Project phase and cycle scheduling
This is still important, because the development task is phased, which is divided into several stages and several iterations. What needs to be done in each period, what kind of output is available, and whether consensus is reached on the business process. This is important. This will also be taken into account when scheduling tasks below.
Team associated
This is mostly for the teamPeople familiar with theandWeeks earlyKnowledge of reporting forms and content forms. Good for later collaboration.
The front-end related
The architecture
This part is mainly in order to be able to give the business, to meet the business situation design writing out of the technical architecture diagram. The first three are to be able to do a good job of technical architecture basic information understanding.
How do I write an architectural solution
I don’t have a good methodology for this. Post two previous drawings:
But what exactly are the standards for technical architecture diagrams?
The following conditions were fed back to me by the company’s boss [Ali P8] and me through the technical architecture diagram [the second diagram above].
- Technical architecture: The figure above shows the technical architecture
- Business boundary: For different business scenarios, the boundary is clear, can not go through the business architecture
- Business architecture: Provides technical support based on specific business scenarios. For example, we encounter a scenario where POS is offline, which is part of the business architecture
- Dynamic process: Business process POS order, check goods how the product process is reflected in the architecture diagram [Missing]
- Integration architecture: Other system integration
- Deployment architecture: Deployment
Technology related
The scaffold
Technology selection & scaffold selection
Here is mainly to do technology selection and scaffold selection. Because we are relatively unified, so basically do not have this problem.
System module processing
Here are three examples
- permissions
- More TAB
- Log in check
Common module processing
- Public methods: Placement of public methods
- Public enumeration values: See Dumi for publishing an NPM package to process enumeration values
- Public Service: data interface processing
- Public components: Placement and specification [also available to publish public or private packages via Dumi see: write a simple calendar with React]
Technology research & technology landing
Technical research and technical implementation of difficult problems.
- Done before: React – Multi-tab page caching
- Electron for POS [js control printer, JS load dynamic library DLL for IC card]
Business Development Demo
This is to maximize the development problems of primary development in the project.
- Code Demo: Demo code used for business development
- Development explanation: synchronous explanation of the development mode of demo
- Documentation: Precipitation documentation
Task division correlation
I won’t go into that here, but some of it has been mentioned in previous articles:Capabilities required by the front end project leader.
Check whether the task is scheduled appropriately according to the phase goal
The emphasis here is on the phase objectives mentioned in the relevant section of the team. It needs to be in line with the goal of the phase, so that in a period of time, what we work together as a whole is a complete thing.
Specifications related to
The development of specification
- Code specification
- Collaborative process
- Submit specifications
Internal collaborative specification
- Early meeting
- weeks
- Task delivery communication: task delivery is clear, technical key points and difficulties are clearly explained, and developers understand and confirm.
- Report on completed tasks: Timely report on completed tasks, more often through project management tools.
- Problem coordination
Document specification
- Address of related documents
- Technical documentation
- Specification document
- Weekly meeting document summary
Front-end department related
Collaboration related
With the product
Uniform prototype specification
It is important to note here that the uniform prototype specification means that the same interactive page style of the output of the prototype should be kept uniform, and there should be no big differences.
- Prototype output is not like a system
- Code development friction
With the back-end
Unified front – end consensus
It’s important to note that the front and back ends need to agree on some things, which will save a lot of communication problems.
With the test
Unified delivery test awareness
- The interface has no obvious UI type BUG and is consistent with the prototype drawing and UI design drawing. The design and layout of the page can meet the product requirements. Any changes should be communicated with the product and UI and modified.
- Functions can realize the requirements of the product, and the input text box, selection box, page turning button, new verification can be consistent with the product prototype. You also need to consider what to do if the fields are too long.
- The current function should be a flow function, not only need to consider the current page function implementation, need to consider the front data from where to come from, in the current data display is reasonable. Whether the front-loaded business data can run down or complete in the current page.
- Each time when the current page is finished or the function of the current page is modified, run the callback interface twice to see whether the current page can transmit data to the back end and return the response successfully.
Common module of unified processing cognition
Determine the page prompt
- No confirm prompt is required for form page submission
- The confirm message is required to update the status of the data delete/list page
- Create a page. Check whether a prompt message is required for routing away from the page
Form processing
- Validation of the length of mandatory/non-mandatory form fields (depending on database Settings or there is a uniform length limit)
- Digital verification/phone verification/email verification
- Form date range validation setting, startDate date range validation can only click before/after the day, endDate select the startDate after the date of startDate
- Special character validation for the form