Leaving the code base cleaner than you found it is a common advice from clean code advocates. But except for renaming variables and extracting code snippets into separate methods, it's difficult to know what else to do. The first tactic is to find or create scenes in the legacy code to allow for safer changes or additions. As we explored earlier, we identified this part over here as a scene, and we have extracted the functionality into a strategy pattern. So, if you remember, we had something like this.

and we have extracted the functionality into a strategy pattern. So, if you remember, we had something like this. PaymentProcessors, and then setting all the processors that we want to deal with. Now, instead of that switch block at the bottom, what we did was call the appropriate method on the proper Processor class. Now, this is a scene, and it's a valid way to refactor your code so that you can improve the structure and make it easier to extend it with additional functionality.

so that you can improve the structure and make it easier to extend it with additional functionality. Another good candidate of a scene would be any direct instantiation of a concrete class, like this one over here. We're depending directly on the back API instance, and what's more, we are referencing it directly in the code. This makes it very difficult to test it because in the tests, I won't be able to create a mock for this part. So, remember when we were testing the wire payment processing,

because in the tests, I won't be able to create a mock for this part. So, remember when we were testing the wire payment processing, we were relying on the characterization tasks and the database structure that we have without following the proper route for isolating the test cases. In reality, if you want to create isolated tests for this part, you would want to mock this. And the way to do it without having to refactor the whole legacy code would be to extract the creation of this class in a separate method. So, we would do something like this,

would be to extract the creation of this class in a separate method. So, we would do something like this, public function, createBankAPI, and this will return newBankAPI. Now, instead of making this instance directly, I will just call the createBankAPI method. Now, for testing purposes, I can create a new class called TestablePayment, and then over here, I will have public property mockBankAPI, and then I will override the createBankAPI method to just return this mockBankAPI.

and then I will override the createBankAPI method to just return this mockBankAPI. And with this, in my tests, I will be able to use this mocking class instead of the original API class, and with that, isolate the whole functionality and test properly. This is how that would look like. So, I'm creating a mock of the BankAPI class. I create an instance of the new TestablePayment, set the mockBankAPI, and then execute the test. Now, apart from refactoring the existing code,

set the mockBankAPI, and then execute the test. Now, apart from refactoring the existing code, when it comes to adding new functionality and still keeping this mindset of continuously improving the legacy codebase, the sprout and wrap techniques that we discussed are also worth mentioning here. Just as a quick reminder, based on the sprout technique, whenever you need to create new functionality, you would just add it elsewhere. So, follow all of the best practices like we did with the wiseProcessor, for example, and then reference them from the existing code like so.

So, follow all of the best practices like we did with the WiseProcessor, for example, and then reference them from the existing code like so. Only this would be an instance of the payment processors. This is the sprout technique, and it allows you not to complicate the code further. So, it's not directly connected to refactoring and improving the code as you go, but then it's a side effect because instead of adding everything to the existing code, you are keeping a mindful approach, handling it on the side, following all the best practices, and then just referencing it within the existing codebase. Similarly, the wrap technique was used when you need to do something.

and then just referencing it within the existing codebase. Similarly, the wrap technique was used when you need to do something before or after calling the legacy code. In that case, we were creating a new method like processWirePaymentLegacy, and then had the existing method call this new one together with some action before and some action after. The goal of this was that all of the instances throughout the codebase would be still relying on the same method,

The goal of this was that all of the instances throughout the codebase would be still relying on the same method, but now within that same method, something else would happen. And this action before and this action after would again be isolated elsewhere and created following all of the best practices so that the code is testable and easy to extend. And we're just referencing it here in our Payment class without affecting too much of the existing functionality. The good thing about all of this is that even if you don't have dedicated time for refactoring,

The good thing about all of this is that even if you don't have dedicated time for refactoring, taking incremental specific steps can significantly improve the codebase and make it much easier to navigate through it.