DEV Community

Paul Kim
Paul Kim

Posted on

Code refactoring practice

For this week's lab in Topics in Open Source Development, I was tasked with:

  • Refactoring my code repository
  • Using git rebase to alter my commit history
  • Squashing multiple commits into one
  • Amending a previous commit
  • Merging commits

GitHub Repository: til-to-html

Refactoring

With two recent pull requests from external contributors merged in, the code repository was ready for some refactoring. A lot of new features had been added onto my code base from a lot of different people - it was time to clean it all up. Refactoring changes included:

  • Rethinking how my program handles custom command line arguments
  • Cleaning up extraneous whitespace and deviations in coding style
  • Adding missing documentation
  • Removing extraneous files (i.e. a newly added package-lock.json)
  • Consolidating redundant functionality into one code

It was satisfying to look at my code again and see new patterns and flows appearing. The act of looking over new features like the --config flag recontextualized my prior code - instead of leaving it in a state where it was "added onto" existing code, I found new ways to "integrate" it.

The previous pull request had added new configuration file parsing functionality to my main index.ts file (source). I moved this new feature into my parseArguments.ts module (source) and consolidated the previously added configuration.ts and configurationParse.ts modules into a single one.

I also cleaned up some inconsistencies with the coding style, including replacing the usage of the var keyword with const or let and reformatting my code with Prettier.

After all of these changes, I tested all of my use cases again to ensure they were all working. There were no bugs before to fix so that was good. I did notice the configuration loading feature handled command line switches like -v and -h - I eliminated support for those since that was out of the domain of .toml configuration files.

Rebasing and amending commits

After making all of my changes in a refactoring branch, I performed an interactive git rebase which allowed me to squash all of my commits into one. Then I used git commit --amend to change the commit message. Then I merged this refactoring branch into the main branch.

Squashing commits definitely helped clean up my git commit history. While I could have simply fast forward merged all of these individual commits into my main branch, it would have polluted my commit history for the future. In the grand scheme of things, I doubt I would need to pick apart and checkout specific commits from this refactoring process down the line.

I typically perform commit squashes and merges on GitHub directly but it was nice to do all of that in a local git environment. That said, I plan to still utilize GitHub's versions of these interfaces when collaborating with others in addition to using git.

Thanks for reading!

Top comments (0)