What should we do when we get down, get back to file, and make up for it?

Online Games are under closed tests and closed beta tests. During the Public Beta period, downtime and rollback are almost commonplace. game developers are anxious to make up for themselves in the process of players' complaints and loss. I have had this experience in Public Beta
The popularity of time is in stark contrast with the cold Qing in a few months. This is a huge loss for the company, and the benefits of the huge ad investment in the early stage are also worth the money. Then, after the game is stable in the later stage, players will be driven by operating means.
Pulling back has become quite difficult and costly. Based on this fact, many people will push their responsibilities to programmers-failing to provide stable releases.

Here, I don't want to get rid of programmers. As a real-time software player, programmers have an unshirkable responsibility. Whether or not we should reflect on how stable software can be developed as a developer. Me
I have talked with company leaders and some developers about this issue. Most of them think that the source of the bug is "not careful" and there are too many low-level errors. So we solve the bug day after day and solve it.
Old bugs and new bugs are generated, which can easily be reminiscent of the TAR traps described in The Mythical man-month.

Let's analyze the problem again. According to the leader's ideas, low-level bugs caused by "not careful enough" lead to unstable products, we can avoid this problem as long as we have enough "care", so we can
Work attitude, salary increase, bug responsibility system policies are introduced, and the final solution is directly proposed for "people. I will not talk much about the actual results. I will talk about my views later.

From a historical point of view, early developers of standalone games were the legendary "elite" programmers (even if they were not before the Games), probably because their games were not large, or the logic is simple (compared with the current network
A stable game version can be released after several months of bug fixes and stable improvements. Therefore, the theory of the game elites is deeply rooted in the hearts of the people, and the programmers who think that the game software is better than other software.
Programmers are more powerful. From the perspective of the Composition Structure of the development team (Planning and art are not discussed here), the program team is usually composed of a master and several programmers who are not so cool. From the perspective of the starting process, it is usually the main process to develop a development plan, then design the entire software architecture, divide the modules according to these designs, and then assign the modules to the heads of people, then, we began to work on coding and constantly communicate and integrate with planning and other programs. Everything looks natural.

 

Let's analyze the problem from the above aspects:
1: Game elites. In recent years, I have often seen a Report on the internet, saying that there is a shortage of Chinese game talents. I agree with this view (only for people
As for whether it is XX million, only those who are engaged in data analysis know), the current gaming development team's threshold is actually not high. For our company, several new graduates will be recruited every year (not devalued
Graduates mean that excellent fresh graduates are also very needed by enterprises), and they will soon be put into development without training. Here is an example. During the discussion, a game master said that he spent a day checking
Find a down bug. The result is that someone has designed a struct with the STD: String member.
Memset is 0. The number of such examples is not very large, and the example of pointer jump is even more difficult.

2: in terms of the development process, I may have been working for small and medium-sized enterprises. I feel that software engineering is far away from Chinese game development, it can even be said that software engineering is far away from most software companies. My Institute
Basically, the game circle we know is a workshop-style development method. in this regard, my point of view is that if it is really a legendary "elite" programmer, it would be hard to adopt this development method. Otherwise, we should introduce some quality assurance mechanisms as appropriate.

3: funding problems many game products are eager to get out of the box. The development cycle of an MMORPG is usually two years, and the development cost is about several millions in one year, under the pressure of progress, we usually choose a certain method of compromise.

4: In addition, due to the long time to see the results, if the R & D process is not well controlled, the core staff leaves the company, and competitors dig corners, there will also be many problems during the handover process, this eventually leads to low product quality.

 

I personally think that the most critical issue is human problems, including abilities and attitudes. Developers with problematic attitudes should be resolutely dismissed. The capability gap between technicians is inevitable. As the main program, we should know people well.
Assign each technician to a suitable position. If necessary, you can improve the technical competence of the entire team through technical exchanges. (The ideal team is Cheng, who can manage a group of cool bits.
Sequencer managers and a group of cool programmers: d)

Then there is the company's environmental aspects, including the work environment, corporate culture, salary and benefits, and the promotion system. These factors will play a positive or negative role in team morale. However, this part is usually determined by the boss. I hope you can meet a good boss. : D

Strengthen product quality awareness: Make team members aware of the importance of product quality. When compromising the progress, they should compromise functions rather than quality. Remember, if you compromise on quality, you owe a debt, which needs to be paid off.

Project management: personnel, project progress and quality management should be strengthened to form a cohesive team.

Software Process: if possible, you can join the code review process and review the code in a crossover manner. Research shows that xx % of bugs can be exposed by directly checking the code, at the same time, cross-code review is also reduced
The risk brought by the loss of developers. At the same time, you can also consider unit testing and daily building, or even try some automated building, such as writing an automated script to check
Out of the source code, and then automatically compile and run the unit test, 2nd days to the company to view the results.

 

The above ideas are just a saying of the family. It is a coincidence to think about them and talk about them casually :)