Problems and countermeasures in smartphone app game development Part 1

I would like to share the various problems that occur in smartphone game development that I am involved in and what tools are used to solve them.

When I was talking to a colleague, I was told that it would be nice if other teams were doing something useful and shared, so I would like to share my team first. I'm developing with python, but I think there are many common problems that can occur anywhere. I'm a server engineer, so I'm a little server-oriented.

environment

• Client is cocos2d-x
• Server is python 2.7 + Django 1.8
• Client connects to server via API
• Server and client development are in separate groups (about 5 people each)
• Source code control is git

Problem and countermeasure menu

Before I knew it, the code I wrote was changed in an unintended way.

When one or two people are writing code, they are always able to work together and it is easy to follow the commit log, so there are many cases where there is no problem even if you do not perform code review. However, with a large number of people (6-7 people in my team), I often mess with and use other people's code, and the load increases without using it as the creator intended. It will be chilly and will cause bugs. Above all, if only one person understands the code, the response to a failure will be delayed.

We have introduced a code review to solve the above problem. I am using ** Stash ** and it is called a pull request in Stash.

Make pull requests by feature as shown below and ask team members to review them.

It's time to merge, but in my team, if two or more reviewers approve, the person who made the pull request can merge. If everyone approves the review, we do so because it takes too long to approve.

However, the process of approving itself certainly causes a wait for the person who made the pull request, so it is a promise that small changes can be merged without reviewing.

I've seen code reviews on overseas blogs before, and I've merged them, so I thought there was certainly such a way, but I think this depends on the situation of the team.

Reviews are filled with indications of coding convention violations

The team is committed to PEP8 compliance.

On top of that, the problem with starting a code review is the review point that it violates the coding conventions. This point itself is straightforward, but both those who do it and those who do it feel like a waste of time and are barren.

You can avoid the problem by making a pull request that does not violate the coding conventions ** before reviewing **.

The following methods can be considered to achieve the above.

1. Hook and check when committing with git
2. Run a coding check and play any violations before a pull request is made on the Stash side.
3. Insert a plugin that automatically checks for PEP8 violations in the editor

We recommend methods 1 and 3 within the team. To do the first, after committing with autopep8, let the committed file automatically fix any coding violations. I will write the detailed method in another article.

I don't know if it's a good code to review or if it's still in progress

In the early days, when I looked at the pull request list at the time of code review, I couldn't tell from the title whether it was a good review or a temporary one I gave before the review.

To solve this, I added [Review] to those who can review it and [WIP] to those who do not want to review it yet. WIP stands for Work in Progress.

After deploying the development environment, the client says that the server cannot be connected due to an error.

Even with code reviews, bugs are still there. To prevent this, after merging, Jenkins will run the test and if it is OK, it will be deployed to the development server.

In the following environment, I set up Jenkins on another Mac in the company, poll the change of the develop branch in Stash, and deploy it every 15 minutes. I'd like to run the test as soon as it's changed from Stash to Web Hook, but I'm polling because it's in-house for security and cost reasons.

The test runs the following test with py.test.

• ** API test **: Test the API exposed to the client. Whenever a server engineer creates a new API, he or she is asked to create an API test that is more than communication confirmation. It's a test that takes only a few minutes.
• ** Integration test **: In MVC, we are testing the logic part such as Model and below. There are many items, and when I test Django with py.test, it takes more than 40 minutes because it erases the data and then tests. I need to parallelize it, but I haven't done it yet.

The integration test takes too long, so if the API test passes, I will deploy it to the development server.

Frequent changes in master data and data inconsistencies

Game master data is data that is a unit parameter or a quest parameter. The original file is Excel, but it is complicated due to various reasons. The following is an outline.

The server code reads the master data and uses it on the code. It is a waste of time to manually update the server code every time it is updated, so Jenkins will update it automatically.

Another problem with master data is that it often has more columns in the master data. For example, it seems that the master data of the unit has skills and the skill ID has increased. As a countermeasure, on the server side, one model source code is associated with one master data, and when extending the function, it is wrapped and the method is written.

For example, it has the following form.

application / module / unit / models / unit.py #Models for unit master data (Unit) application / module / unit / models / unit_wrapper.py # Unit model wrapper (UnitWrapper) application/module/unit/models/init.py

init.py is defined as follows

# -*- coding:utf-8 -*-
from __future__ import absolute_import
from __future__ import unicode_literals
from .unit import UnitWrapper as Unit

Then, when referencing from the outside, UnitWrapper can be read as a Unit by doing the following.

from module.unit.models import Unit 

This unit.py part is automatically created by running the script, so you will not have to worry about updating the master data. This part is not automated by Jenkins, but of course it can be.

The client does not understand the specifications of the API created by the server

It is a problem if the server side creates an API and its specifications (request parameters and response parameters) cannot be confirmed. There is a pattern to write in Confluence etc., but it does not make sense unless it is constantly updated, so it is preferable to work with the source code.

There are Swagger etc., but in my team, I realize it on the management screen by myself.

The APIs are listed. It will be added automatically when you create a new API.

API documentation example for player / signup

As mentioned above, the team members made the ones that can understand the request and response.

I want to try out the API, but setting the URL and post parameters is troublesome

During development, you may want to hit the API to check the response. There is Advanced REST Client etc. as a Chrome plug-in, but it is difficult to maintain as APIs are added every day.

You can also issue a request from the API list on the management screen that was mentioned earlier.

It will be added automatically when a new API is added. In addition, you can save up to 5 parameter candidates, which is useful when you want to try different parameters. Once set, it will be automatically saved in the browser. The members have additionally developed the part where you can try multiple parameters.

Since it has become long, I will write "Part 2".