Interfaces are written, and the progress of the pot is on the front?
Separating the front end from the back end is definitely a good thing. Separating the responsibilities also means that each other’s progress is not affected, but is that really the case? I believe that many front-end students suffer from it, there are bitter, workload is not reduced but increased.
Foreplay: Too much work? Where are the more?
After the separation of the front and back ends, the back end only supports the underlying services and provides the following basic interfaces:
1 Interface for querying and modifying basic information 2 Interface for flow
While the front-end workload from the original pure page production, workload surge, including:
- Interaction design, especially some user operation habits, product friendly experience are in the front end
- Compatibility of all kinds of strange devices, use in different environments (network environment)
- When the cost of connecting the interfaces is high, you are just like connecting with a third party (many interfaces at the back end are unfriendly to the interface, so the concept of BFF has been very popular for some time).
- Understanding the product, knowing what the product is trying to achieve, and does the logical interface of the product match
- Product overall function self-test
- Acceptance of back-end interfaces
You write the back end interface, and then you have the front end, right?
Here we don’t discuss whether the back end is really written, assuming that the back end really tested its own single interface is through, and then put the project progress and bottlenecks are in the front end here, is it appropriate? Not right!
First of all, to clarify the first concept, what is your own interface written, you write the interface is self-test pass? Definitely not. Consider the following questions:
- Does your interface implement what the product understands it does
- The discrepancy of the interface, conform to the demand of the front end, oneself is not only a function of complete, and ensure that the front can be as small as possible, the cost of access, rather than a mobile phone and let the front page, call 5-8 interface, there are many unknown interface calls, just because a page of different fields from different interfaces, Or just because one of the fields in the returned information is a key and your database does not have it, you can provide a dictionary enumeration interface to check the definition of key-value. Interfaces should be able to provide complete business information and complete the basic function points as the basic requirements, rather than how you simply decouple. For the back end, if you want to decouple, you can decouple internally, instead of spreading the cost on the front end.
- Whether the multi-scenario, complete link test is completed using the interface, most cases are not. Most of the back end will complete the single test of the single interface in the single scene in the simplest scenario, even if they pass. In practice, when waiting for the front-end chain, there are still many problems in the single interface and interface series.
Secondly, we are a team, and just because the backend finishes its own work does not mean that you are not responsible, can you ensure that you will not find any problems in the process of joint investigation? If you find a problem with your interface, and the loss of front-end resources to solve the problem due to the restart of the back-end project, is it a front-end integration problem?
Finally, UI, interaction, the acceptance of detail, most card here at the front, and even the backend will advice said, where are you here where is bad, because it seems that the front-end time to make any changes are at the lowest cost, and then end even make a small function changes to add extra time, delay to demand, but the front is seldom to get such say, For the front end, any detail can cause an increase in front-end workload and stress. The back-end part, basically in the joint adjustment link back-end and front-end have solved the problem of more than 90. Therefore, at this point, I hope the R&D team can give the front end a reasonable statement, can confirm UI, interaction, details before the start of the front end work, and avoid excessive optimization after the process and test. In response, the front end has the right to say: Accept the proposal, but don’t change it.
A small case: the door lock interface to write good twists and turns
An external door lock is written, but the front end is tuned, and then the front end. What? The only thing missing is you. The backend is self-tested. When are you going to do it?
Personnel involved: Back-end owner 1, back-end developer 1, front-end 1, and product manager 1
Stage 1: The initial plan, the scope of influence of the plan judgment, Shanghai, the judgment city Stage 2: the person in charge of the back end thinks that the city judgment is too coupling, and sets the external door lock as an extra room, and the product does not agree with the third stage: the product agrees and compromises, and the front end realizes the fourth stage according to the plan: The back-end 1 development phase defines an additional interface for the front-end to request (quite different from the two-phase scenario). The fifth stage: discuss with the product again, and the product, front end and back end decide to use the changed plan. The sixth stage: the front end changes the interface and fields according to the new scheme, and performs joint adjustment again
So in this kind of change process, the back end in phase 2, phase 3, phase 4 all say they have finished the interface, and then the front end is missing, this kind of problem is really the front end? Just because the back-end of the product, there is no suitable handover of the front end, think of the scheme is good even if good, poor front end you adjust the interface, adjust the function, you are the code written, front-end code has not written ah, with what you just write, to urge the front end of the progress?
I also want to say
Front-end requirements review, UI review, interactive review, research and development, interface joint commissioning, test, the workload is a lot.
If there is a difference, it is in the development phase, with more work on the back end for more complex functions. But in conventional business development, for workload, the front end is only much more, UI details are front end, interaction details are front end, joint adjustment is mainly front end (the back end is basically such as the front end to ask questions, such as the front end feedback what is not working and what is the expected data), functional testing is basically the front end. Although the function of the completion is the back-end, but the front-end work is really very complicated and messy, and from the beginning to the end, almost to pay attention to the content of a lot of special, only in the middle of the research and development interface gap will be a little empty.
So to the front end, must put himself as a product manager, the product have enough grasp, details of various interactions, UI and function have enough grasp, precipitation solution, don’t be a pure interface caller that role, what kind of interface and the back-end service for logic to make product more relaxed, front-end do a single, can also very important.