Alchemy (3): how to do a good job in interfacing a business process

Suppose a complete project , Contains 6 Different 【 End 】：PC client 、 Mobile 、 Official website 、 Payment page 、 Activity page 、 And the back end 、 And the development of the underlying core functional components .

Suppose there is 5 Individuals are responsible for 5 individual 【 Have a face 】 Of 【 End 】：PC client 、 Mobile 、 Official website 、 Payment page 、 Activity page ; hypothesis 1 The individual is responsible for developing the backend , How many people actually don't know , this 1 An individual is a representative ; hypothesis 2 The individual is responsible for developing the underlying core functional components , How many people actually don't know , this 2 An individual is a representative ; hypothesis 1 Follow up tests .

Suppose the product , Ready to MVP Functional analysis and design , Write the design documents of each end . Product at this time 【 You can't 】 Directly send the document to the person in charge of each end , Just waiting for people at each end to do development . What needs to be done at this time 【 Demand confirmation 】： With the person in charge of each end 【 formal 】 Open a discussion ,【 Item by item 】 Check the design , Confirm each other's requirements for this end for the first time 【 Consensus 】. If 【 No, 】 This is a necessary discussion , Design only exists in the mind of the product itself . Others may just look at the rough and start writing code , So as to stay at the beginning and 1 Version requirements do not match .

In development , Different ends will start to implement without relying on the functions of other ends , When it comes to interfaces that need to be connected with other terminals . You must stop your work ,【 first 】 do 【 Interface confirmation 】： Find the person in charge of other end to confirm the interface design of a business model , At this time, you should not only consider the relationship between the two ends , But should be able to consider from the overall framework , Interfaces between multiple ends , There should be a sequence diagram , This sequence diagram shows a complete business process ：

1. From which portals do you start business , Suppose that A End , Called entry startXXX.
2. Consider the complete interface call from the entry 【 closed loop 】：
   • Which interfaces depend on the other end , For example, back-end calls 1 Or N Interface .
   • What events on other ends are monitored , For example, monitoring the backend 1 Or N Events .
   • Whether the process jumps to other end , For example, display a QR code , Scan the code and jump to the web page , What did you do on the web page , For example, the back-end interface is called , The back-end interface triggers an event to A End .

After this discussion , Each end confirms that its own logic is 1 In a business process 【 Location 】 And function , At the same time, have a clear understanding of the overall situation of the process .

After understanding this business process , A consensus has been reached , But not enough . On the frame , These scattered process points , Should be encapsulated in a common component , Each end depends on the interfaces and events of this common component . Suppose the component is C, that ：

1. C A set of 【 Entrance to meet different needs 】 Interface , In order to meet the needs of different scenario entry calls at different ends .
2. C A standard set of events should be provided , Different entrances should trigger follow-up 【 Consistent flow of events 】. Make the event flow concerned by each end for the same business consistent .
3. C The details should be hidden inside , Do it internally 【 A complete state machine 】, And complete error handling 、 timeout handler 、 Retry mechanism and so on .

For this business process , Take this public component as the entry , Write 【 Based on the command line 】 Of 【 Scenario test 】 Code . Available after basic testing , Before submitting the interface implementation , And notify other end interfaces and components that are available .

In terms of coverage , It should be for each individual interface , Write unit tests for interfaces . Tests and assertions that contain both normal and abnormal data . Can be written by developers , perhaps 【 Division of labor 】 Write for tests that have the ability to write unit test code .

Come here , in the light of 1 Business processes , Form a design that involves multiple ends 、 docking 、 encapsulation 、 The test of 【 closed loop 】, Instead of becoming a person who knows only a little at each end 【 Toy interface docking 】. In multiple iterations , Will continue to adjust this chain , Gradually complete the complete understanding of the chain . The program development environment has been fragmented , Client diversification , The distribution of the back end , The development environment is 【 cracking 】, do 1 Interface design and docking of business processes , There needs to be an overall closed loop , In order to avoid program development “ I don't know the truth , Only the body in this mountain ” problem .

--end--