[Q] How do front-end and back-end personnel collaborate in development?

Here I will talk about my thoughts on the collaboration between front-end staff and background staff. I hope you can give us some advice and share your cooperation methods.

 

I joined the company for a while and participated in a web project. In the project, I am mainly engaged in front-end coding. During front-end development, I encountered some problems and had some thoughts.

The front-end developer's team cooperation is mainly reflected in calling the business logic layer method compiled by the background developer. In this development, the background staff will first write some common methods for business logic objects, such as basic addition, deletion, modification, and query. The front-end staff will look for these methods for calling. If the front-end personnel need some new methods, they can achieve the following in two ways: 1. verbally inform the background staff: "I need a new method". Then the background staff will write the method. After the preparation, the background staff will tell the front-end staff the location of the method and ask the front-end staff to call it. 2. The front-end personnel first add the signature of the new method at the business logic layer, and then inform the background staff to write the method.

Some problems may occur during development:

1. If only one person is responsible for the background class library, it is easier to find the method. If multiple people are responsible for the back-end class library, and each person's encoding does not follow the encoding rules, the class name writing rules are different, and the method signature writing rules are different, there are both instance methods and static methods in a class at the business logic layer. Methods of the same business logic object may appear in classes at multiple business logic layers, it makes it difficult for front-end developers to find a method.
2. There are both external public methods and private methods used internally in a business logic class. There are too many methods in a class, which makes it difficult for front-end personnel to search for methods.
3. The front-end personnel may search for the required method in the business logic layer class library, and misuse the method due to name similarity or other reasons.
4. If a front-end engineer needs to add a new method, he needs to check whether the method already exists in the class library. If not, the front-end developer needs to ask the back-end coders. If most of the new methods required by the staff in the previous section need to ask the back-end staff, the development speed will be reduced (the query may be time-consuming, and the background staff may not be able to ask questions on a business trip ).
5. If the front-end developer is not notified in time after the new method is compiled by the background engineer, the development progress of the front-end developer will be delayed.
6. If the front-end personnel directly add a method to the file at the business logic layer, the conflict may occur because the front-end personnel and the background staff edit the same file at the same time, integration after a conflict is a time-consuming task.
7. If the front-end personnel forget to inform the background personnel after adding the method signature to the business logic layer class, the background personnel may not be able to know that there is a new method to be implemented in the class.

 

In this regard, I personally have a solution with imperfect consideration: in the development process, the front-end staff should first write the contract, and the back-end staff should implement it.

Implementation Method: add business logic interfaces and business logic factories.

Simple process: the front-end personnel are responsible for adding the required methods to the business logic interface and adding the method for creating instances in the factory. The background staff inherit the corresponding business logic class from the corresponding interface, and specify the business logic class for creating the instance in the factory.

Advantages:

1. Because the interface is compiled by the front-end personnel and there are only external public methods in the interface, it is convenient for the front-end personnel to query the method.

2. Front-end personnel will not misuse their own defined methods.

3. To add a new method, the front-end personnel only need to add the method directly in the interface. The compiler informs the background staff that the business logic class does not fully implement the methods in the interface.

4. The front-end personnel can call the interface method directly without being notified of the location of the new method to decouple the relationship between the front-end personnel and the background personnel.

5. frontend and backend personnel do not conflict with files because they operate business logic classes at the same time.

Disadvantages:

1. If a front-end engineer adds a new method to the interface, the project compilation fails before the background engineer adds the method to implement the method in the interface in the business logic class. In this case, I also came up with a solution: multiple solutions can be used in the project: a total solution (including all projects) A front-end solution (including projects required by the front-end such as utility, model, ibll, and performance Layer), a background solution (including utility, model, Dal, BLL, bllfactory, and other background Projects), a test solution (including utility, model, BLL, test, and other projects required for testing ). In this way, adding a new method to the ibll layer does not cause compilation failure of the solution used by the front end.

2. Increase the encoding capacity

 

In fact, problems encountered during development can be solved through communication among team members. I want to use some mechanisms to minimize unnecessary communication, because communication is at the cost of time. The above is just some of my thoughts from the perspective of front-end development. These ideas are based on the premise of Improving the front-end development efficiency. We try to separate the association between the front-end and the back-end as much as possible. In some places, the work of other team members is not considered, and some places must still have problems. This is just an idea of some solutions for the problems encountered by front-end developers during this development.