Refactoring code and Git history!

For this weeks lab, we are supposed to refactor and improve AT LEAST 3 things in my code to improve the code's structure, readability, modularity, and maintainability. And we are introduced to git rebase to change git commit history (reword, squash, drop etc.).

Refactoring code

I've been pretty diligent about keeping the code base clean. One this I learned in my time working in various group, personal projects & my last co-op is tech-debt is a real thing and it keeps piling on and on to a certain point where your only choice is either dedicate a sprint to refactor the entire code base or just ignore it. So, since the the beginning I've been extracting functionality in separate functions in my util directory to have NO code duplication. Using inline method call instead of declaring variables if I don't need it more than once and using very descriptive variable names (no one likes single letter variable names). So, I didn't have much to refactor at first glance. On top of that, this was my last PR with title Major Refactoring for consistency last week, where I fixed a lot of syntactic errors and some readme updates. So I kinda did one out of three things before the lab was announced lol. But, one thing I didn't like was how bloated my index.js was becoming. I took a look at it and I figured I could extract some of of the logic in it's dedicated methods to keep the file lean. So, I made two new utility methods. ExtractOptions.js to extract all the options from either the options or toml config and ResponsePresenter.js with the sole responsibility of printing to the console and writing to the file depending on the options. So that's what I did. leading to index.js having 46 lines replaced with seven.

Refactoring Git history

After working on a separate branch and rebaseing to have a single commit I merged it on main. But I did not like how my history on the main repo was like. As you can see below Sep 26 commits are not way I want them to be.

So using rebase I squashed and renamed the commit to have a more linear history. Since I have experience working with rebase interactive it was pretty simple. Having I committed the cardinal sin of changing git history on main, I had to do a force push to remote to update the main repo with all the changes. Now it looks exactly how I want it to.

I would've preferred to have all the commits on main branch only as PR squash merges, keeps things simple and clean. Personally, NOT a fan of working on main repo locally.

The above is the detailed content of Refactoring code and Git history!. For more information, please follow other related articles on the PHP Chinese website!