Refactoring explained - Github Copilot Tutorial

Refactoring is changing code without changing the way it behaves. That second part is important. It means that when code is refactored, it is for the benefit of developers, not users. I want to start with some simple examples of refactoring. I'll add two functions, function foo, thanks, Copilot, and I'll add function bar. One console logs foo, one console logs bar. And then I'll call them, and not surprisingly, the output is foo and bar. Now, to refactor, when I look at this, I have two functions that have similar functionality. I could probably create one function and pass in the string to echo. So I'll simply create a display string function with the help of Copilot, a lot less keystrokes. And then I'll update the calls to foo and bar to use the new function. And at this point, I can delete the old functions that aren't called anymore. When I call the file again, not surprisingly, the output is identical. This is a super simple example of refactoring. Note that the output didn't change, but I removed two functions and shrunk the file by about 30 percent. Now, refactoring is not about removing code. Sometimes, that is the shape that it takes, but it can also be about adding code. First, I'm going to create a new file called add code to work in, and I'm going to type out a function that returns a discounted price on a product. Imagine this in an e-commerce situation. So function apply_discount(). And we'll take a string which is the product type, and a float, which is the price. I'm going to ignore Copilot's prompt so I can talk through this while I'm doing it. If product type, let's say clothing, then we'll return price times, sure, I'll take 0.9, and then, else if, product type is grocery. I will return 80 and I'll add one more. Sure, I can take that. Oh, fix some formatting here. Let me spell that correctly. And I'll return, sure, I'll take all of that. Now, you're probably thinking this might be a pain to maintain. What if more categories are added? I'm going to add a wrinkle. It would not be surprising if I needed to display the discount percentage somewhere. So I'll add that function. And this time, I will let Copilot auto-complete it for me; it has enough context. And it was able to infer that from the previous function that I had written. A logical step here would be a function that returns the value of the discount for each category. That way I can use them both in apply_discount() and display_discount_percent_for_product(). So I'll call this get_discount_for_product_type(). With that in place, the body for apply_discount() becomes, get_discount_by_product_type, and then, I return the price, minus the price, times the discount. And for display_discount _percentage, it's similar. I don't know why Copilot thinks we need that echo, but there we are. Now, the behavior of those functions didn't change from when I created them until now, but their source is no longer hard-coded. And that means the get_discount_for_product_type is ready for me to connect to an external data source or a JSON file instead of hard-coding it. Now, these were both simple examples in this video, but the key takeaway is that refactoring is for the benefit of developers. The user experience should not change.