Code refactoring practice
Published: 2023-10-14 05:53:56

For this week's [lab](https://github.com/Seneca-CDOT/topics-in-open-source-2023/wiki/lab-5) in [Topics in Open Source Development](https://github.com/Seneca-CDOT/topics-in-open-source-2023), 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](https://github.com/paulkim26/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](https://github.com/paulkim26/til-to-html/commit/df4dd8bd08ab11feb25b0d75ab66585f3df53da0#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R1-L15)). I moved this new feature into my `parseArguments.ts` module ([source](https://github.com/paulkim26/til-to-html/commit/df4dd8bd08ab11feb25b0d75ab66585f3df53da0#diff-b5525fc172c205cb1bd05b3a60fee0de57249d15235a4bc1ef0701eb29a0e59dR36-R55)) 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!