Refactoring Low Level/High Level
Over Engineering Design Patterns can lead to over-flexible code It is hard to predict the future If certain requirements are never realized, the code is still never removed Code base is too complex So programmers specialize This affects productivity in a subtle way No one wants to get stuck with a bad design
Under Engineering No time to produce good code Don’t know about SW design Add in new stuff quick and dirty Working on too many projects at the same time Look at The Big Ball of Mud
Test Driven Development (TDD) Uses continuous refactoring (in small steps) Write a test Devise code that will pass the test Refine the code Write some more tests Bottom line: Get a small piece of code working correctly before refactoring it
Red, Green Refactor Red: Write a test that tests what your code is supposed to do. Red, because there is no such code Green: Write some code to pass the test Don’t worry about program niceties Refactor: Improve the code that just turned green “Rapid unhurriedness”
Why Refactor? Minimize code duplication Simplify complicated code Make code easier to understand Do this for small improvements--low level Also strive, where relevant, to move towards Design Patterns--high level Try to understand theintent of patterns “Patterns are where you want to be; refactorings are ways to get there from somewhere else.”
What is Refactoring? Refactoring is “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.” Remove duplicate code Simplify complex logic Clarification of unclear code Test, test, test
Testing Make sure your changes do not break the code Try to automate the testing Refactor in small steps, always testing Download JUnit
Code Clarity Why is Better than june(7,2011); //calling public void date() Better than java.util.Calender c=java.util.Calendar.getInstance(); c.set(2011, java.util.Calendar.JUNE, 7); c.getTime(); Because it is readable and keeps your attention away from distracting code
Other Considerations Keep your code clean Refactor in small steps Remove duplication, achieve better design Refactor in small steps Otherwise spend much time getting back to green If the bar stays red too long take smaller steps
Design Debt It is not always easy to get time to improve your design (boss laughs, you get fired, etc) Managers do not always like refactoring “If it ain’t broke, don’t fix it.” Thus you accrue design debt: code tends to deteriorate The Big Ball of Mud If you don’t pay your debts, you get late fees Getting out of debt gets harder and harder Managers understand this
Evolutionary Design Common Problem: Project division can cause bad communication, wrong code can be written, programmers can wait around. Evolutionary Design Form one team Be application-driven Continuously refactor