Anatomy of a Pull Request
Tags: unity3d, programming, gamedev, github
Published: 2022-06-28 20:17:49

One of the programming goals I have for my [Innovating on Tetris](https://dev.to/jerkytreats/innovating-on-tetris-2122) game project is to take the _craft_ of programming seriously. 

Despite being a side project with no other contributors, I wanted to practice the oft-ignored ancillary parts of software engineering. Things like documentation, well defined PR's, etc. 
 
![GitHub PR we'll be analyzing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i8446y0etitdfdtam33r.png)

With this being a side project, I also wanted to use these PR's as the canonical history of this project. By trolling through the [history of PRs](https://github.com/JerkyTreats/tetris/pulls?q=is%3Apr+is%3Aclosed), you would discover a _narrative_ of game development. 

The advantage of all this extra work? I can take that narrative and convert them into running devlogs- the heavy lifting is already done. In today's digital economy, marketing is everything- and the key to marketing is a compelling narrative. By creating a narrative in PR's, I enable a _derivative marketing pipeline_. 

![Setting up the marketing pipeline is TODO](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e88kyptqiz9tkg9ucn86.png)
_Setting up the marketing pipeline is TODO, I'm thinking a GitHub Action that prints out the markdown of the PR into a blog post._

## PR Anatomy

Taking the above PR, let's break down what I've done: 

![Detailed Anatomy of the PR](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dsy19299edhjhnxlyts9.png)

### Link to Design

Regardless of using your PR's as a DevLog, having your PR's link to the requirements is going to be very useful- not just for yourself, but for the reviewers who may not have the context. 

### Major Components

This was major feature I was implementing, which required a couple of distinct steps. Much like the design links, we are communicating context here- allowing the reader to frame what we are doing (design links), where we are doing it (major components), and why (narrative)

### Link to Commit

To complete this feature, there were a number of major changes required. By linking to each each major change, I continue to help the reader understand where each change is coming from. 

[Coupled with the power of open source, you can view the commit yourself](https://github.com/JerkyTreats/tetris/pull/21/commits/38947244adc38f5c638e2f78a41c7c401ef25981).

One criticism I have is here I over-committed. Here I added the unused folder `GameManagement` folder even though it's unused. One thing I have to get better at is adding more, smaller commits.  

### Narrative

One one of those major components were completed, I used a commit to write the narrative of the change:

> The previous refactor was useful for detangling the gameplay logic from the Board object. The resulting gameplay controller had several issues of its own, unfortunately.

> As I define in Blog/multiboard_tetris_design, I want to structure how objects are created, destroyed, and managed throughout their lifetime.

> Starting from the very top, I defined the GameManager as a holder of GameControllers. I defined the relationship between manager-controller to get the mandatory function a game controller would have.

> With this structure defined, I was able to look at the Tetris GameController (renamed now to TetrisClassicController) and refactor it with a clearer goal in mind. This led to fixing ActivePiece and GhostPiece, having them more independent and properly managed by the Controller.

> The result should be fairly clear object control. From the GameManager to the ActivePiece, control of an object is defined by its parent. Even more importantly, each object has a clearly defined way of how to be managed. Common functions for the control flow.

## Practice Higher Standards

In many respects, the actual code you write is the least important part of programming. The design/requirement phase is as critical as the PR/merge phase. Good habits, started early and ingrained into even your side projects is critical to the long-term success of your projects. 

Good habits are a force multiplier because it offers the opposite of technical debt- technical _dividends_. Instead of fighting toil, you're pivoting rapidly, or expanding easily. 

By practicing higher standards, you are continuously honing the craft of software development. This is the only way to become a better developer.