{"id":31,"date":"2022-10-12T03:11:37","date_gmt":"2022-10-12T03:11:37","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/meyersz\/?p=31"},"modified":"2022-10-12T03:24:44","modified_gmt":"2022-10-12T03:24:44","slug":"writing-clean-code-as-a-cloud-performance-engineering-intern","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/meyersz\/2022\/10\/12\/writing-clean-code-as-a-cloud-performance-engineering-intern\/","title":{"rendered":"writing clean code as a cloud performance engineering intern"},"content":{"rendered":"\n<p>This Summer\/Fall I&#8217;ve been interning at a company called Ampere working on Cloud Performance and Automation. The main tool I&#8217;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&#8217;s CPU offerings in the cloud.<\/p>\n\n\n\n<p>The tool is called PerfKitBenchmarker, or PKB for short. Because so much of PKB&#8217;s codebase wasn&#8217;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. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">clean code<\/h2>\n\n\n\n<p>If I&#8217;ve learned anything while working on this project it&#8217;s that the practice of clean code can save lives&#8230; Or at least prevent future suffering. Clean code saves me from the headache of trying to decipher what I&#8217;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.<\/p>\n\n\n\n<p>I&#8217;ve learned that understanding PKB&#8217;s implementation &#8220;under the hood&#8221; with abstract classes, utility functions, run phases, event triggers, etc. is critical for my ability to extend the tool with new benchmarks. It&#8217;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.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"903\" src=\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/5948\/files\/2022\/10\/gettyimages-1340157909-1024x1024-1.jpeg\" alt=\"\" class=\"wp-image-42\" srcset=\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/5948\/files\/2022\/10\/gettyimages-1340157909-1024x1024-1.jpeg 1024w, https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/5948\/files\/2022\/10\/gettyimages-1340157909-1024x1024-1-300x265.jpeg 300w, https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/5948\/files\/2022\/10\/gettyimages-1340157909-1024x1024-1-768x677.jpeg 768w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption>computer maintenance operation<\/figcaption><\/figure>\n\n\n\n<p>To maintain clean code to benefit my future self and fellow engineers I&#8217;ve implemented a few steps I like to take at the end of the development process before code review:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Refactor any long functions into smaller functions, each with a more singular focus (this is a big one, and usually straightforward)<\/li><li>Write doc strings for every function<\/li><li>Address remaining TODOs and leave NOTEs in important areas of the code<\/li><li>Leverage Python&#8217;s ability to compress long nested blocks into single-line statements (when appropriate!) via list comprehensions, compound return statements, single-line conditional assignments, etc.<\/li><li>Comment important parts of the code, but strive for the code to be &#8220;Pythonic&#8221; and document itself as much as possible<\/li><li>Intentionally write comments for any line\/block that makes use of a class, method, or function that isn&#8217;t immediately obvious to an engineer that isn&#8217;t familiar with PKB<\/li><\/ul>\n\n\n\n<p>These steps are often listed as things every engineer should be hyper-aware of <em>before<\/em> writing any code. I&#8217;ve found that as someone who is new to this codebase it isn&#8217;t always possible to do all of this while writing a &#8220;first draft&#8221; for a feature, and sometimes the priority is on hacking something together that works first. Over time as I&#8217;ve practiced clean code at the end of my development cycles I&#8217;ve found that I&#8217;m actually getting better at writing clean code from the start of a new feature, practice makes perfect after all.<\/p>\n\n\n\n<p>I feel like this experience is making me a much stronger engineer and a better teammate, which is already trickling into the experiences I&#8217;m having with my teammates in these first few weeks of the Capstone class.<\/p>\n\n\n\n<p>Here&#8217;s to hoping my code gets cleaner and my skills keep sharpening.<\/p>\n\n\n\n<p>-Z<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This Summer\/Fall I&#8217;ve been interning at a company called Ampere working on Cloud Performance and Automation. The main tool I&#8217;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&#8217;s CPU offerings in the cloud. The tool [&hellip;]<\/p>\n","protected":false},"author":12703,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-31","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/posts\/31","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/users\/12703"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/comments?post=31"}],"version-history":[{"count":9,"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/posts\/31\/revisions"}],"predecessor-version":[{"id":43,"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/posts\/31\/revisions\/43"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/media?parent=31"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/categories?post=31"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/meyersz\/wp-json\/wp\/v2\/tags?post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}