The path to migration-vsts Software Development Guide

A few days ago, at the teacher's course requirements, I selected the course recommendation reference book "The path to mountain migration" and read a part of it, so that I found many shortcomings in my current work.

First of all, this is not a very serious book. The author has a strong narration and can answer questions by yourself, which has solved many of my questions.

But at the same time, I also found some problems from myself:

1. How is the workload allocated in team projects? If you have a mature team, you can assume that everyone can trust it. At this time, you can allocate the workload almost evenly to ensure the interests of everyone, however, in our current immature team that only works for one project, it is difficult to find a balance point in workload allocation. Because they are very familiar with each other, considering differences in personal character habits, knowledge reserves, and team awareness, it is difficult to achieve an average way of assigning work; however, unbalanced allocation can lead to a series of problems such as team centripetal force.

2. How should we weigh the operational and development efficiency? In previous exercises, the teacher asked us to optimize algorithms as much as possible to improve code quality. However, in this process that is closest to the actual development, we found that excessive pursuit of algorithm optimization will greatly reduce our development efficiency, other steps of code development are stuck in the bottleneck of algorithms. We try our best to reduce our requirements for algorithms to pursue higher development efficiency. The result is that we sacrifice the efficiency of some algorithms. Is it wise to do this?

3. I agree with the standardized development process described in the book, but in the actual development process, our team is not mature and our members have understood each other and can communicate well, not everyone in the team can take responsibility, so the standardized development process is not applicable to our small-scale development process to a certain extent.

4. Finally, it is about bugs and tests. First, we must accept that our program has many bugs. But how can we determine the importance of these bugs? How can we ensure that modifications to a bug do not affect other functions? Is there a simpler and faster way to ensure the correctness of all units than unit tests? Even if we have passed enough tests, we still cannot guarantee that there will be no errors in actual operation. Is there a more standard and applicable method for bugs in the maintenance phase than patching?

These problems may seem very naive to the development team, and I can easily explain them even after this semester of training, but for now, these problems have always plagued me. I hope that I can answer these questions through my own efforts in the future development process.

The path to migration-vsts Software Development Guide