This Summer/Fall I’ve been interning at a company called Ampere working on Cloud Performance and Automation. The main tool I’ve been developing is an internal fork of an open-source Python framework, originally developed by Google, that will help our performance engineers perform cross-cloud/platform agnostic benchmarks to validate Ampere’s CPU offerings in the cloud.

The tool is called PerfKitBenchmarker, or PKB for short. Because so much of PKB’s codebase wasn’t written by engineers at my company, and because the documentation is a bit lacking, there was a fairly steep learning curve with being able to meaningfully extend the tool for our purposes.

clean code

If I’ve learned anything while working on this project it’s that the practice of clean code can save lives… Or at least prevent future suffering. Clean code saves me from the headache of trying to decipher what I’ve written weeks ago when I inevitably have to return to a certain module I had worked on previously. It also helps me collaborate better when I need help from a teammate by making my logical intent clearly defined in the code that I write, hopefully revealing any bugs I may have introduced for quicker resolution.

I’ve learned that understanding PKB’s implementation “under the hood” with abstract classes, utility functions, run phases, event triggers, etc. is critical for my ability to extend the tool with new benchmarks. It’s taken some time, but after a few months I feel I have a decent grip on the framework and my development is speeding up! However, there is a double-edged sword here: being up to speed with the codebase means I can work faster than before, but working faster creates the risk of writing code that is obfuscated and unmaintainable.

To maintain clean code to benefit my future self and fellow engineers I’ve implemented a few steps I like to take at the end of the development process before code review:

• Refactor any long functions into smaller functions, each with a more singular focus (this is a big one, and usually straightforward)
• Write doc strings for every function
• Address remaining TODOs and leave NOTEs in important areas of the code
• Leverage Python’s ability to compress long nested blocks into single-line statements (when appropriate!) via list comprehensions, compound return statements, single-line conditional assignments, etc.
• Comment important parts of the code, but strive for the code to be “Pythonic” and document itself as much as possible
• Intentionally write comments for any line/block that makes use of a class, method, or function that isn’t immediately obvious to an engineer that isn’t familiar with PKB

These steps are often listed as things every engineer should be hyper-aware of before writing any code. I’ve found that as someone who is new to this codebase it isn’t always possible to do all of this while writing a “first draft” for a feature, and sometimes the priority is on hacking something together that works first. Over time as I’ve practiced clean code at the end of my development cycles I’ve found that I’m actually getting better at writing clean code from the start of a new feature, practice makes perfect after all.

I feel like this experience is making me a much stronger engineer and a better teammate, which is already trickling into the experiences I’m having with my teammates in these first few weeks of the Capstone class.

Here’s to hoping my code gets cleaner and my skills keep sharpening.

-Z