Planning the Refactor

As you were building this module, did you notice the redundancies within the view files? We are using separate view files that have virtually the same HTML structures to them. That’s not good.

Why? Because if you need to make a change to the structure or one of the styling attributes, you have to remember to change it in three different places. That is an error waiting to happen. If you forget about one of them, then the change might get released and pushed out to your customers. That’s problematic.

Instead, the better strategy is to combine the shortcode and archive template views. In other words, we would have one container and one FAQ view file for shortcode and template. Let’s talk through this approach. How are we going to refactor?

Also, let’s commit our changes into the repository before we do any refactoring. Why? At each major stage of the code build, you want to capture a snapshot of those changes by committing them into your repository. It gives you a historical record, one that will help you as you look back to find what caused a problem.

And in making the commit, I write a bad commit message. You and I will walk through how to check the log, i.e. git log, and then amend that commit message using:

git commit --amend -m 'the message goes here'