Before we start our project, I would like to list some principles to help us improve our efficiency. I wrote these down in our TDD.

I'll explain here what the reason for doing this is.

In each weekly build, known exceptions must be addressed.

In minicapstone I found that we have been having some Exceptions in our project files. It was causing a series of problems.

Most of the time these exceptions don't cause the game to run incorrectly, but sometimes the exceptions generated by the error are hidden in there for you to overlook. That's why we have to eliminate them, they make you less sensitive to the correctness of the program.

Moreover, an obvious reason is that exceptions prevent programs from Debug, which deprives us of an important tool for handling bugs.

So we want to make sure there are no exceptions in the weekly build to reduce the time we spend on errors.

In exception handling, we follow the "let it down" principle, exposing exceptions and handling them promptly. Hiding exceptions by using try-catch without handling is prohibited.

When I was working, this was a habit of some people that I abhorred. Because of the nature of some programming languages, the IDE will prompt you to handle exceptions when calling APIs that may throw exceptions.

So they catch the exception and the exception goes away.

When a bug occurs, you can't understand why it went wrong, and then maybe a few hours later, you find out that an exception occurred, but was caught, just like nothing happened.

So instead of doing this, we should just crash the program when the exception occurs, so that we can find the problem in time to fix it.

Use "Debug.Assert" assertions more often to handle potential errors and detect issues in a timely manner.

This is still a habit. Because sometimes a program will continue to run based on incorrect data and end up with an error that cannot be observed. This error ends up being visible in an unrelated place. So in conjunction with the previous article, we add more assertions so that the program crashes at the beginning when it encounters the wrong data. To find and fix errors in time.

Encourage knowledge sharing. 

Team members should share typical errors they encounter, discuss avoidance methods, and share codes and designs they are proud of. Document bugs and errors that took a considerable amount of time to resolve for preservation and sharing purposes.

In the game industry, we all lack relevant experience, so I think it is important to share our experience so that the individual experience becomes the group's experience. This will be good for each of us. And avoiding making mistakes that others have made can also reduce the time we spend on debugging.

Through knowledge sharing, discussion, and summarization, develop team coding standards and best practice guidelines as the project progresses.

The absolute correctness of these team coding standards and best practice guidelines is not important, but rather the consistency of the team's style. This helps us understand each other's code and reduces the cost of collaboration and the difficulty of code review. It also makes it easier for us to continue working on each other's code.

Summary

You will find that the entire article revolves around two points: reducing bugs and reducing communication costs.

Yes, because developing a project is like building a mountain of shit, and every project will inevitably become a mountain of shit. We can only find ways to reduce the rate at which it becomes a mountain of shit.

This is because as projects grow larger they become out of everyone's control. Whenever we need to go through code we don't understand, it feels like we're crawling up and punching holes in a mountain of shit.

So by reducing mistakes, we can reduce the number of times we climb the shit hill. Increasing communication is what makes the size of the shit hill smaller. This is where these principles come from.

Xiuyu 'Huey' Zhang