You need to eliminate not bugs, but the reason for their appearance: case from the game developer



    From the translator: today we are publishing for you an article by an experienced game developer tester Richard Taylor. The article will be useful for both beginners and experienced developers, - there is definitely something to discuss here.

    I created a lot of games. Usually the final stage of development is very painful. After all, it is at the end that we encounter bugs, and only after that we can finally finally gloss over the product. The situation worsens when the developer has a minimum of time to complete the project. We have to work quickly, and the bugs in this case are frequent guests. How can you deal with them? It's very simple: to make fewer mistakes, that's all (this is the author's irony - the translator's note).

    Skillbox recommends: Two-year hands-on course “I am a PRO Web developer . ”

    We remind: for all readers of "Habr" - a discount of 10,000 rubles when recording for any Skillbox course on the promotional code "Habr".

    Reducing the number of bugs


    Since all the bugs are in the code, it's probably enough just to ask the development team to make fewer mistakes?

    If you are funny in this place, I would not be surprised. Indeed, no one (or practically no one) commits them of their own accord. So what can we suggest to the team so that it makes fewer mistakes in the code so that there are no bugs in it?

    We are starting a new project. Step one - do not repeat previous mistakes


    Our team worked on several AAA projects. Before starting one of them, we decided to conduct brainstorming on the topic “How to make the minimum amount of mistakes”. None of us wanted to spend the last couple of months working on a project looking for bugs and sweeping the code. One of the main tasks is the distribution of responsibilities and responsibilities. Each type of work was assigned a senior.

    Step one is to decide why all this is necessary. The “why” of the top level is explained simply: we want to reduce the amount of time required to eliminate bugs, optimize costs and improve the overall quality of the project.

    The point is to free up time to perform interesting tasks, those that allow you to happily wake up in the morning and immediately take up the implementation of task. This is what made us all developers - the ability to use your time for really cool stuff!

    By the way, even if there is a clear task to create fewer bugs, it is so general that it may simply be meaningless. This is a statement of intent that needs to be clarified and broken down into a series of clear assignments addressed to individual team members.

    Answering the question how to do this, you must follow the basics of the scientific method: observation, hypothesis, test, repetition.

    Observation


    Categorization

    Open the database of the bugs of your last project and view it. There are many kinds of bugs, so just saying: fewer mistakes are simply useless.

    In order to better understand the issue, you need to decide on the specifics. First of all, it is necessary to reduce the number of those problems for the detection and solution of which a time gap is needed.

    Analysis

    After compiling a list of the most time-consuming bugs, the next step is an attempt to find common ground in these errors, as well as to understand the reason for their occurrence. Analyze and interpret!

    Cause of the problem

    In the end, we created a number of templates for searching for specific bugs, which made it possible to understand why their search and elimination eats up so much time. After that, we were ready to go to the source code to find the root cause of the problem.

    Working with technicians, we found more fix changes. Then compiled new lists of systems, files, and lines of code related to major bugs. As a result, we made a list of necessary code changes that could be discussed with the development team.

    We told you so!

    Then we had a meeting with programmers to discuss our findings. As it turned out, the guys knew about most of the problem areas in the code. But if so, what was the point of holding a meeting?

    Answer: we managed to draw a parallel between specific code points and temporary losses associated with these problems. And this, in turn, made it possible to objectively evaluate any proposal for the maintenance of the code.

    Thus, we revised sections of code that could be called acceptably bad. When we evaluated them with our work in hand, it turned out that refactoring was needed. At the same time, the engineering team had previously abandoned it because “there is too much work” or “this is simply impossible.”

    In fact, many problems were systemic. Many "invisible" aspects led to a chain of events that caused the appearance of an error. By the way, the causes of the problems were so systemic that the project had to start almost from scratch.

    As a result, we have accumulated enough results of empirical observations and analysis in order to form hypotheses. The whole team took part in this process.

    Hypotheses


    Hypothesis 1. Specific coding patterns are likely to lead to bugs in a large software project.

    Hypothesis 2. The time required to correct errors in a project can be reduced if we avoid the patterns of behavior defined in the first hypothesis.

    Let's define what a big project is. These are about 25 programmers, 12 months of development. The following statements are true for him:
    A. Any code will live long enough, so the cost of maintenance will eventually exceed the cost of the development itself.
    B. The complexity of connecting individual project systems is higher than the complexity of a particular system.

    Why is this so important? In small projects you can cope with almost everything, here the program structure is not so important. The code is all at your disposal.

    If the project is large, then everything changes. You can work with the code, the purpose of which you do not understand, you can not even know to which part of the project a particular section belongs.

    After our discussion, we obtained the following statement of results: “The data show that these specific programming patterns were a common factor associated with various bugs / problems. We believe that by avoiding these patterns, we will be able to reduce the time spent on correcting errors and at the same time improve the quality. ”

    Now we start practical implementation.

    Testing


    When creating a new project, it is necessary to avoid identified bug patterns. We had these:
    • Operator overloading and bad naming.
    • Auto, polymorphic functions and type safety neglect.
    • Increase code complexity through, for example, dependency injection and callbacks.
    • Use mutexes, semaphores, and the like in high-level code.

    What's next?


    And then we had the opportunity to start a new project, the development of a new game. We were able to create a game engine from scratch and complete everything on time, with a relatively small team of programmers. There were a few bugs, and the code was good. At the same time it took a little time to maintain it.

    All this became possible because we did not use problem patterns, as if they did not exist anymore. We even had the mantra "Make it harder for you to make a mistake."

    The whole team was pleased with such results, it became more interesting to work, because again it became possible to spend time on what you like.

    Skillbox recommends:

    Tags:

    Also popular now: