Problems and countermeasures in smartphone app game development Part 2

This is a continuation of Problems and Countermeasures for Smartphone App Game Development Part 1.

I don't know who is currently doing which task

I'm currently the lead of the server team, but the problem is managing the tasks of the members.

Tasks are managed on the backlog by looking at the Gantt chart every morning.

Even if you create a basic task, leave the person in charge unassigned, and ask the member who finished the task to implement the task that the person in charge is not assigned.

The created task is assigned to the member and the state transition is as follows.

By doing the above, you can check which task the member processed later by filtering by person in charge, which is convenient for looking back.

Tasks to be done in the future are forgotten

To keep in mind, all the tasks that need to be performed are put on the backlog, and on the Gantt chart of the backlog with an appropriate date in the future. I will never forget this! Should be.

The client says there is an error on the server, but I don't know what kind of request I made

A common pattern is that the client crashed the app (500 or something came back) due to a server response, but check it out. In some cases, such as a report from the debugger, there is a time lag, so it is difficult to know which request. Even if you get a ** user ID **, it is hard to search from many requests.

The following can be considered as measures for that.

• Make it possible to see requests and responses for each user ID on the management screen.
• Allow Sentry to search by user ID
• Check Errors with New Relic

Make it possible to see requests and responses for each user ID on the management screen

The one that was originally used by other teams seemed to be convenient, so I transplanted it and asked the team members to improve it.

You can narrow down the requests that came to the server by user ID and search. It also records server processing time, so you can filter slow response requests.

Press the open menu to see the contents of the request and response.

The above is useful because the client can also intuitively see the request and response.

Allow Sentry to search by user ID

The company uses Sentry as a service to catch and record exceptions.

When sending this Sentry log, the user ID can also be sent as a custom metric.

class ErrorHandleMiddleware(object):
    ...
    def process_exception(self, request, exception):
        if not self._can_emit(exception):
            return
        data = self._gen_data(request)
        if getattr(request, 'device_id', None):
            tags = {'device_id': request.device_id}
        else:
            tags = None
        client.captureException(data=data,
                                tags=tags,
                                exc_info=sys.exc_info())
    ...

This allows you to find the error by searching by user ID.

When an exception occurs, various logs are sent to Sentry and can be seen as follows.

Check Errors with New Relic

Also in New Relic [here](http://qiita.com/wapa5pow/items/0a4132c62d807286af9d#%E3%82%B1%E3%83%BC%E3%82%B93-%E4%BE%8B%E5%A4% 96% E3% 81% 8C% E7% 99% BA% E7% 94% 9F% E3% 81% 97% E3% 81% 9F% E3% 81% A8% E3% 81% 8D% E3% 81% AB% E3% 81% 9D% E3% 81% AE% E3% 83% 97% E3% 83% AC% E3% 82% A4% E3% 83% A4% E3% 83% BCid% E3% 81% 8C% E7% You can send the user ID by doing something like 9F% A5% E3% 82% 8A% E3% 81% 9F% E3% 81% 84).

I want to identify slow APIs and prevent them from being released before they are released

[Written before](http://qiita.com/wapa5pow/items/e3ef018af270cc2ad014#%E3%82%B1%E3%83%BC%E3%82%B91-%E3%82%A2%E3%83% 97% E3% 83% AA% E3% 82% B1% E3% 83% BC% E3% 82% B7% E3% 83% A7% E3% 83% B3% E3% 81% AE% E5% BF% 9C% E7% AD% 94% E3% 81% 8C% E9% 81% 85% E3% 81% 84% E3% 81% 91% E3% 81% A9% E3% 82% 82% E3% 81% A3% E3% 81% A8% E6% 97% A9% E3% 81% 8F% E3% 81% AA% E3% 82% 89% E3% 81% AA% E3% 81% 84% E3% 81% 8B) I think you should use it.

I want to see if the server performance comes out

I think you should do a load test. locust is written in python and it feels good. I will write the know-how here separately.

I want to reproduce the user in the production environment in the development environment

When testing in a development environment, you may want to use the same user information as in a production environment. For example, the level has been raised, or the specified unit is in possession.

The above can be realized on the management screen, and it can be imported / exported with json.