1. Refactoring
Low Level/High Level

2. 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

3. 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

4. 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

5. 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”

6. 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.”

7. 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

8. Testing Make sure your changes do not break the code
Try to automate the testing
Refactor in small steps, always testing
Download JUnit

9. 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

10. 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

11. 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

12. 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