A Gentle Introduction to Refactoring

“I want to reconfigure my code to best survive the environment it lives in, it’s an evolutionary process.” ~ Will Refactoring is the process of making the internals of an application less painful to code without affecting the functionality of the app. Refactoring code improves the ability of developers to troubleshoot problems and increases the speed of developing new functionality. It involves decoupling internal components to keep dependency changes from causing major rework or reorganization of code in preparation for future operations. Organizational inertia and interpersonal disagreements about how to proceed may inhibit the ability to refactor. When refactoring start with small changes and a small locus of control, reference the architecture, and make short iterations before integration. Episode Breakdown * 12:52 Refactoring Defined “Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software.” This means making the internals of an application less painful to work with for developers. Refactoring is reconfiguring code to best survive the environment it lives in, it’s an evolutionary process. * 14:42 Why Refactor Code Refactoring improves the ability of developers to troubleshoot problems in code base. It also allows for increases in the speed at which new features can be surfaced and tested. Decoupling the internal components keeps dependency changes from causing major rework. Code may need to reorganized in preparation for future operations or components broken apart for separate iteration. * 27:55 Hindrances to Refactoring “This code works! Why mess with it?” Organizational inertia is caused by managers and owners who do not see the value in refactoring or the potential dangers of not refactoring. Interpersonal disputes about how to proceed may hinder refactoring efforts. The originators of the code may not want to see it changed. Inability to test for regressions or comprehend existing systems also pose hindrances to refactoring. * 39:38 Strategies for Refactoring * Small locus of control Start refactoring with something small. Don’t start a refactoring that takes days because you will miss something, or get distracted or discouraged. These processes take place while still delivering a product or service. Do a small piece then go back to the work that is bringing in a paycheck and come back later for another small slice. * Testability of changes Write things so that the piece you are changing it is testable. This protects against the possibility of creating breaking changes in other parts of the code. If that happens testable code will help show if or where the refactored code breaks. * Reference architecture Build a piece of code that’s complete end to end. This sets the cleaned up design so that the next person to come in will know how it works. It also helps to make sure there are not major holes in the refactoring due to a cross cutting refactor. * Small changes at a time (small wins) Psychologically small wins develop confidence in the refactoring process. Also small changes when implemented correctly help reduce organizational inertia by showing management the benefits of refactoring without making major changes to the code. * Short iterations before integration Make a branch, refactor, push it back to the main branch. Small changes and short iterations because checking...