Some thoughts on remote collaborative development

In the past two weeks, I have been busy with a friend's project in my spare time, and I was very busy. In the end, the finished product delivered by the project could not fully meet the needs of the customer. This project is based on the application on Andoird's Pad. It mainly completes some online learning and exam functions, and also needs to cooperate with the display and statistics of background data. There are some special requirements in the front desk that can process office documents in different formats (mainly reading) on ​​the Anroid Pad, and the traditional architecture of SpringMVC+Spring+Hibernate is used in the background.

The biggest problem facing this development is:

(1) The technical skills of the developers are uneven, which leads to the poor quality of the code part. Many problems are found in the process of integration testing, and it is difficult to change.

(2) The developers are distributed in different regions, and the code management is managed through the svn of google code. Google's svn is very unstable and often fails to connect, resulting in a lag in code synchronization, affecting code synchronization and the advancement of project testing.

(3) The front-end and back-end interfaces are not agreed and formulated in advance. This project has front-end Android programs and back-end Web services. The front-end and back-end communicate through JSON and Key-value pairs. We use the JSON framework for parsing, so the specification of the front-end and back-end communication interfaces includes: the unification of entities (the number and name of main fields), the URL request to be called, and the parameters that need to be sent or accepted. After negotiating these three elements, you can start working! But in the development process, it is still necessary to constantly communicate and optimize.

(4) Iterative integration testing is not done well. In this project, due to the tight time, the initial demand was discussed from the beginning and the development was started. There are no dedicated testers in the project team, so an engineer does the test part-time. Later, I chatted with him about the project. He mentioned that the main reason affecting the quality of this project is that the integration test was not well controlled and the phased delivery was not done well. Each test product delivered to a customer is partially developed and compiled. But later, it was found that the code that passed the test had a problem with the submission of svn, and a lot of repetitive work was done to fix it. After repeating this several times, the internal friction is particularly large. Complaints from customers also increased.

In short, after this project, I have learned a lot of lessons and gained some experience. The biggest gain is to do the above four points well in the project management of remote collaborative development, and to increase the intensity of communication in the development process.

Original author: An ordinary Java guest www.javake.net