Individual operation can only be competent to distribute to their own modules, teamwork can make products quickly and high quality launch.
Every right has a reverse
To improve team collaboration, analyze what is holding back development progress.
Under normal circumstances, the estimated time of the project is relatively tight. If the project performs normally, the online time will not be too far apart. If there is any change in the middle of the project, the progress will be adjusted in real time according to the feedback.
But sometimes code is stable enough to play its fixed role, while people are not, and different behaviors can have vastly different effects.
Negative effect
Global interference
In a recent project, some of the new features had passed the first round of testing as we entered the beta phase.
But in the absence of any changes to the code, the test suddenly presented a bunch of bugs, and some of the previously functional parts didn’t work properly.
Please note that once you encounter similar situations, a large number of bugs suddenly occur under the premise of almost no change in the main function code. In terms of the front end, either the background is down, or there is a compatibility problem, a specific mobile phone model or system version.
Another mistake that should not happen is that other branches of the team affect the overall project and cause you to have functional exceptions, such as CSS style overwrites, JS variable overwrites, etc.
In retrospect, my operation at that time was to first investigate the cause of the abnormal function, and I found that the vuex and VUe-Router parameter parmas failed. But why did they fail? After a long time of Google, I found that I doubted life.
Having had a similar experience with collaborative errors, and with a residual confidence in my code mechanics (technical proficiency determines how I think and how I troubleshoot problems), I turned to gitLab’s logs
Looking at a colleague’s log, I found a recently submitted piece of code, which is defined as doing some operations on global routing.
Here, I also made a mistake, see the other side of the comment is written only in the first login XXX, and then did not look down the role of the code, and then began to doubt life.
When the time is more than half an hour, we should try to solve the problem that cannot be solved at the moment, communicate with colleagues or relax a little, change the way of thinking, etc. When the investigation is more than an hour, we go to ask colleagues.
My colleague said that the global operation was carried out on ios not long ago. Because a new function needed to be developed, vuex and VUe-Router parameter parmas were reset every time the page was switched on ios.
The ability to troubleshoot and locate problems aside, it’s only a reminder that if you know your code is going to have an impact or even a disruptive effect, make sure you do it in the community, or at least verbally with your colleagues.
Of course, as far as possible, do not generate globally uncontrollable code, no one can guarantee that their code will not affect the previous functions or colleagues’ modules, decoupling is a kind of ability, declaration is a kind of attitude, but also a way of cooperation.
tips:
Some teams conduct codereviews, one on submission and one after submission.
Either way, they are responsible for the quality of the code, and errors like the one above, if reviewed, would have been found and intercepted before the test was released, should not occur.
It doesn’t matter that the team doesn’t have review process. Most of the time, don’t get into the habit of implementing rules only when others set them. You must have your own independent thinking and excellent habits.
In the previous installments, I talked about the methods and skills to improve efficiency. I can also add another one, that is, when working overtime or reviewing regularly, I can check my own code and my colleagues’ code in time to make up for any gaps.
Cooperation time
Some time ago, the test worked overtime smoke test on Saturday without any notice. Both the front and back end did not work overtime, and did not know to test.
There are several serious effects, which are also man-made problems.
First, because there was no email or group official announcement about the test on Saturday, the front end did not release the latest test version, and the test on Saturday was the last version that was packaged without knowing when.
This situation can almost be said that the test was in vain, fortunately, the version of the test happened to be functional, only some styles did not keep up with the progress, so it did not cause a great waste of time, the impact is not big.
Second, during the normal working period, few people will take the initiative to mention in the group or make a formal email statement (although sometimes there is no need to be too formal) when the front and back end sends out the version each time.
As a result, the network error will be suggested when the test tester is on the side, or new code will be tested with the old standard (for example, a new requirement and UI will be changed suddenly, but the test does not know), resulting in bugs or interruption of the test process (as shown below).
In fact, it is the basic communication obligation and the minimum working attitude to inform the group before the release of the version. As far as efficiency is concerned, it can avoid many problems that should not occur. It is only a matter of one sentence.
Secondly, with the convenience of people is also for their own convenience, when the version can also indicate the current version, released content (updated what functions, etc.), as well as some other notes, so that things can be checked, others are easier to understand.
But found in several companies, no matter just joined the small white, or mix for a long time veteran, will not pay too much attention to some of the team and communication details, or too lazy to operate, would rather after the blame is not willing to pay attention to beforehand.
tips:
In China, there is no tendency to use email, even in a heavily work-related workplace.
If it’s not mandatory, don’t even bother to reply to an email, or even have a verbal message if it’s not required.
Use email, or at least chat groups or communication tools.
In fact, in the final analysis, the first is a work attitude, willing to cooperate and cooperate, the second is the use of tools.
Secondly, we should pay attention to the matter that the best working time is when all staff are present, and problems must be dealt with in a timely manner.
You can’t just wait until someone else gets off work to solve it. It won’t work either.
It is recommended to resolve collaborative issues while you are at work, and to leave less urgent and important personal issues until you get closer to the end of the day or work overtime or work on collaborative issues.
Permission problems
The process of testing often requires iterations of a process.
However, a process usually fixes the data state after operation, and it is not possible to create an account again or ask the background to clear the data every time (only the front end).
While fake data is fine, some logic still requires real feedback, such as login, SMS authentication, identification, order submission, etc.
In general development, there are local environments, test environments, formal environments, and at least in local and test environments, data can be manipulated AD hoc.
If there is a management background, it is recommended to obtain the background panel of operation test environment, and do some process setting operations for the module developed by yourself, such as changing the user status.
If there is no management background, the use of SQL and other direct operation of the database is also ok (the premise is to know a little database and understand the table structure ~ specific can ask the back end)
The premise is to avoid a functional test that takes many times, but each time someone else has to reset the data, someone else may be too busy to help or notice your needs.
Second, working directly with the database is a very powerful thing, even if it is only in the local environment, it is important to avoid producing dirty data that will affect other processes.
Sometimes it is necessary to reproduce a bug, and some procedures must be completed. The operation is tedious and difficult to locate. It will be much faster through background and database modification.
Generally speaking, it is to test some authority, you should also have as far as possible, such as management background, database, etc., without, can only make the relevant module as far as possible to cooperate.
Avoid the situation where you have time but the process is stuck and can’t operate. This phenomenon is a real waste of time, and a waste of most of the day.
tips:
There will also be other permissions, such as code merge permissions, publish test permissions, and online permissions.
There is an element of skill and attitude accident involved, looking out for things that you have the time and skill to do but you can’t do.
The positive role
The positive approach can be simply summarized as
- Reasonable division of labor, clear responsibility, modular
- Efficient communication mechanism (chat software, task panel, email, etc.)
- Check regularly and adjust in time (
codeReview, daily newspaper, weekly newspaper, big and small meetings
They tend to exclude negative effects rather than positive ones, even if the positive effects are small, but at least they do not affect efficiency and schedule.
To know, large and small companies, in fact, the most chaotic, the most deadly, but also the most core.
It’s never about skills and ability, it’s about team management and collaboration, it’s about interpersonal communication and behavior.
tips:
Positive effects more on that in the next article.