For this weeks Podcast, I again listened to Complete Developer Podcasts. Today I will be talking about a brief introduction into refactoring. This includes the Wiki version of the definition of Refactoring and a more likely and on point definition of Refactoring. Also included will be reason you would need to refactor code or want to, reasons why you wouldn’t want to or need to. Refactoring while it may be simple is something that I have overlooked in the past because it wasn’t a topic that was spent a lot of time in class on. I thought like a lot of the topics that I have listened to this semester, are about topics that I knew or heard about, but did not go in depth about. Will and his co-host did a really good job about describing what it meant and what it does, which I always appreciate since reading a book can sometimes be hard to understand.
So to start this off, I will give you the Wiki definition they said first when talking about Refactoring. Refactoring is the process of restructuring existing computer code, changing the factoring without changing its external behavior. Refactoring improves nonfunctional attributes of the software. While this may be the definition for wikipedia, this does not actually define what it is. A more realistic definition is that it’s making the internals of the app less painful. Anything you are working with inside the application that is a pain-point and ways of getting rid of that, it is ways to make the app more extensible. The wiki version does not include everything and is not on point.
The next point to cover is answering the universal question: Why need it if you did a good job on your code already? The first thing to point out from this question is that nobody does a good job on their code completely. Nobody builds things that the world doesn’t change around. Your code is going to be under different restraints and requirements. It may be the best code but given some time and it will eventually become garbage. To begin, the first reason is improving the ability of developers to troubleshoot problems. Make it where developers can actually tell what is going on. The next reason is to improve testability. THis means making code changes that are not intended to be surfaced to an external party. Its code changes for organizational structure, testability, or management structure that are internal to your organization and not to your surrounding parties. The third reason is trying to decouple internal components. An example is if you have different pieces of the app that are testing to each other. So part A is dependent on Part B, B is dependent on Part C which is dependent back on B. THe problem though is when you want to upgrade for this instance Part A. If you have a massive dependency like this example portrays, it can be painful because you upgrade A and B gets busted. The fourth reason is to reorganize code in preparation for future observations, which in this case is hitting people now with the new mobile space. They now have to support tablets, phones and even iwatches. You don’t want to break the external functionality, but they have to tear things apart for it to work. People have to pull things apart to put new things in and refactoring helps prepare for this. The fifth and last reason is breaking components apart so you can iterate on them separately. You usually see this in bigger systems, where the company builds an app to handle everything internally. As they start to scale up, for example they go to franchise model, all of a sudden things need to be separated to functional efficiently. Code would need to be reconfigured to best survive the environment that it lives in, it is a evolutionary process.
Lastly what was talked about was why not to, don’t want to refactor code. One reason is organizational inertia. This idea is when someone believes that the code that they have is already good enough, so why mess with it? Another example is when a company has use the same code for a long time it has always worked, and never faced any bugs. If it works perfectly, why mess with it and cause unneeded problems? People also feel attached to their code, so they may not want to change the code that took them a lot of time to perfect. Technical considerations are also important. ANother reason is volatility in your tool chain. This is the inability to comprehend existing system and the inability to test the code.
Overall, I felt that this podcast was very informative. It explained a lot about why refactoring would need to be used and it helped a lot with my general understanding of what refactoring was. I was happy to find a podcast about this because it was very simply explained while going into some detail but without getting too complicated. SOmetimes it is hard to find podcasts that are informative, but also entertaining to listen to. As always, I really liked the podcast that I listened to and definitely recommend it to anyone who want to learn about the basics of refactoring.
