Changing 3 lines of code shouldn't take a whole day

Author | Adam Berg

Translated by | Winter rain

Planning | Ling Min

I've worked for 5 different software companies, including game development, mobile development, and web development. Among these work experiences, there's one topic that hasn't received the attention it deserves: iteration time. Originally I was going to write an article about build time, but I thought that the perspective of iterative time would be more accurate to the point. I define iteration time as the time it takes to see code changes work as expected.

The purpose of this article is to help you reflect on the current development process. Are there parts of your pipeline that are spending too much time? Is there a way to do some debugging tools to make change testing easier? Does unit testing bring benefits, but you keep avoiding it because of its upfront cost?

In 2014, I joined the FIFA team as an intern. The world of AAA game development was a whole new experience for me. I remember when I saw that my desktop had 16 (maybe more?). When the CPU is core, the eyes are staring like brass bells. I then set it up as instructed and was told that the initial build would take at least 30 minutes, after which the incremental build would be faster.

While incremental builds are indeed much faster, compiling a single line of code change is still likely to take at least 10 seconds. As a relatively naïve C++ developer at the time, I made a lot of syntax mistakes. Every time I change the code, I have to wait 15 seconds to see what I'm doing wrong.

Changing 3 lines of code takes a whole day

While waiting, I might just go online and search for something, try to think of other changes, or look at instant messages on the chat tool. No doubt my attention may have been distracted, and it took me a minute to get up and look at the compilation status.

Compiling is only the first step. Now I need to package the application and deploy it to the platform I'm using. When I first opened the PS Vita, Nintendo 3DS, and Nintendo Wii, I waited about 30 seconds for the game to run on the console. Then I need to launch the game, navigate to the game feature I'm changing, and eventually maybe see my changes.

I am often responsible for changing the logic of the competition. Testing the changes here can mean spending a few seasons in Career Mode before you can figure out what's changed. Without kidding, it takes a whole day to change 3 lines of code so you know if it actually works correctly.

Debugging tools

I eventually moved to a newer platform and was given a "test bench" by Amway. It streamlines some packages in an attempt to reduce iteration time by focusing only on specific areas of code. Once I found the Career Mode test bench, I almost never ran the game again. This test platform will be built in seconds and includes various debugging features. It all runs on a personal computer and things get faster.

I'm excited! But I looked at the people around me and I saw that a lot of people obviously didn't know how to use this tool. Instead, they're following the old way of launching an entire game, manually navigating through the UI to the features they need to test changes. I quickly became a champion of this test bench and frequently added new features to make it easier to develop new content.

I still need to run the full game occasionally, but this testbed allows me to experiment quickly and understand how the code works, which keeps me focused. It also allows me to fix actual problems at a reasonable (by my standards) speed.

Unit tests

Finally, I changed teams, and I found that the team was already starting to do unit testing. Although I had some unit testing experience at the time, I never used it in game development.

I was briefly introduced to the code, the various tests, and how to run them. I found that the test package basically contained only code for a specific game area of our team. A brand new build can take up to 10 seconds, and subsequent incremental builds can take less than 1 second.

It's hard to stress how important this threshold is. The reality is that in less than a second the test is compiled (and run), and I can now keep an eye on this one task. Compilation and logic errors are inevitable. But when I was able to quickly spot bugs and recompile, I went into a fluid state.

For the first time, I started to enjoy writing code at work. Refactoring and moving large chunks of code is a breeze. It became much easier to modify someone else's code and know that I wasn't doing any damage. Change code anxiety is gone.

I then rewrote the competition logic to speed things up and add unit tests. A wide variety of edge situations make unit testing the perfect way to ensure that all the main content is covered.

When I finally left the company, I felt doubly cool because I left a system with self-checking. I spent a lot of time figuring out how something should work, and it was all programmed into test specifications.

Conclusion

In many ways, I'm grateful for my time in the electronic arts world. I've seen many times where long-term engineering initiatives take root and bring real day-to-day benefits, and this is one of them.

At some point, someone will come forward and say, "It takes a long time to test these changes, is there a better way?" This is a question we should ask ourselves every day.

https://devtails.xyz/3-lines-of-code-shouldnt-take-all-day?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhY2Nlc3NfcmVzb3VyY2UiLCJleHAiOjE2NDEyODY5NTYsImciOiJZS0pXY1ZLS1RDREp2dDhWIiwiaWF0IjoxNjQxMjg2NjU2LCJ1c2VySWQiOjI1NjUxMTk2fQ.jQ0_q56To1EZSXgHHeaFPLix3gvQa-FeliLv6n8fNwI

Translator's Bio:

Winter Rain, a small technical house, engaged in R & D process improvement and quality improvement work, focusing on programming, software engineering, agile, DevOps, cloud computing and other fields, very willing to share fresh foreign IT information and in-depth technical article translations to everyone, has translated and published "in-depth agile testing", "continuous delivery practice".