From the course: Refactoring with GitHub Copilot

How to convince your team to refactor - Github Copilot Tutorial

From the course: Refactoring with GitHub Copilot

How to convince your team to refactor

“

By now, you're convinced, not only do you want to refactor your codebase but you want to use Copilot to do it. The only problem is your team might not see it as productive work. I'm going to highlight some of the pieces that I've shown along the way. In this code smells file, I created a bunch of new classes and an interface. While this might work on some projects, it's likely overkill. If you have a task adjacent to this kind of work, start by adding comments. Comments are step zero to refactoring. Better yet, ask Copilot to do it for you. That's a simple addition to a PR, and the reviewing developer will really appreciate the effort that you put forth. Once your team becomes accustomed to your PRs, having small improvements with comments, it's time to start making real improvements. Refactor some conditionals. In this case, breaking it into three functions, one per user type as step 1. A subsequent step would be to normalize those into individual files containing the discount rules. Remember, refactoring does not change functionality. Finally, adding a test suite, if one does not exist, is a great first step. It doesn't have to auto-run on every PR in your CI/CD. Start small and build. On some projects, I've never been able to convince the team to spend the time implementing test automation. Even if the tests are a separate repo that are only on your local, you've left the code in a better place than you found it, and you can confirm with each change you make that you introduce no regressions. Refactoring is safest and works best for everyone when the changes are small. You may see a clear path forward, but to prevent regressions, move slowly.

Contents