OOBootcamp Training Insights

OOBootcamp Training Insights

At the end of April this year, I participated in the company’s OOBootcamp training. The training consisted of 6 sessions, and throughout the process, I gained several key insights that I’d like to organize here.

I should have organized this earlier, but kept procrastinating. After some encouragement from our company’s Peiqi, I finally decided to write it down. The muscular guy on the right in the picture below is him

Repeatedly Confirm User Requirements

What we create, whether for personal use or commercial products, ultimately faces users. Only when users use it and use it well can it deliver value. Conversely, if it doesn’t gain user recognition or deviates from user needs, the value becomes low or zero.

During the OO training, we worked on parking lot development for 5 sessions [I think]. At the beginning, there was a significant gap between our understanding and the actual user requirements. After hitting several walls, we gradually realized the importance of confirming requirements.

Test Naming

This insight is probably the one I’m most satisfied with. Why? Because it’s the most direct. Tests correspond to our confirmed user requirements, using a short sentence to describe a scenario and an expectation.

After discussion and referencing our company’s practices, we settled on the following test case naming convention:

should_xxxx_when_xxx_given

This corresponds to our expectations, execution timing, and given conditions.

Of course, it’s important to highlight one point: If you encounter test names that are too long and cannot be shortened, prioritize readability over brevity - don't shorten just for the sake of shortening.

Code Simplicity

Throughout the OO training, we focused less on theory and more on hands-on coding. While writing lines of code, we also thought and discussed about how code should be structured and what constitutes good code. One thing we were certain about: code should be simple.

Our company’s Jian once said, "When working on projects or products, the real challenge is making complex things simple."

Let me vent a bit: I worked on a project for over a year that only had 3-4 pages. Can you imagine?

For example, WeChat - you just click around a few pages. Simple? Baidu search has just one input box. Simple?

So, for complex matters, we should strive to make them simple. The same goes for code - we abstract, specify, and eventually break down code into simple units. The simpler the program, the better its maintainability and readability.

Benefits of Tasking

I first learned about Tasking when Jian suggested it during pairing. [I mention him again - can’t help it, he’s excellent]

Tasking essentially means "breaking down how to put an elephant into a refrigerator into steps" and then tackling them one by one.

Currently, I use Things to break down work into tasks and complete them step by step.

Revealing Key Information

When doing Tasking, we often use a few sentences to organize our thoughts. It’s important to highlight that these sentences should reveal key information.

Benefits of TDD

Is TDD good? I’d say yes. TDD itself reinforces the importance of testing and, through testing, refines and organizes business points and key aspects. Ultimately, it safeguards the so-called correct logic.

When we write the three parts of tests [given, when, then], we gradually drive out the actual business code.

Why Write Tests First

This is a fundamental question. Writing tests first serves as a double confirmation to some extent. Additionally, tests define the correct inputs and outputs for our business code. So, test-first is correct and wise.

Currently, much of my code doesn’t follow TDD. This is something I need to practice deeply going forward. But there’s no denying that testing is necessary, and TDD is beautiful.

Final Thoughts

Well, that’s it - short, maybe superficial, but I’m being willful! During the OO training, I had many collisions and exchanges with coaches and colleagues. I remember one session going until after 10 PM - it was tiring but also brilliant. I firmly believe that growth happens through collisions. These insights will be integrated into my understanding and applied in future work and learning.