Refactoring 2 The Max

Refactoring 2 TheMax Alfredo Morresi: www.rainbowbreeze.it Diego Guidi: lacorrente.blogspot.com staff@dotnetmarche.org

Shit happens Anything that can go wrong will go wrong. (Arthur Bloch)

Underengineering AKA "fast, slow, slower.... never :("  quickly deliver 1.0 release that works well for our customers but with junky code  working on 2.0 release, junky code slows you down, and new features are harder to implement  as junky code multiplies, people lose faith into the system and the programmers  planning next release, you realize you can't win, and start thinking about a total rewrite

Overengineering AKA "the 'HelloWorld' pattern"  code more sophisticated that it possible future requirements  code hard to understand for new ones  time wasted understanding and maintaining complex code so you need to write documentation

Code smells  copy/paste (duplicate) code  large method/class  method-like properties  contrived complexity (patterns everywhere!)  inappropriate intimacy  unused code  dangerous if (if - else if - else if - else...)

Cunningham's metaphor The technical language doesn't communicate effectively with the vast majority of management. Instead, Ward Cunningham's financial metaphor of design debt works infinitely better. Design debt occurs when you don't consistently do three things. 1. Remove duplication. 2. Simplify your code. 3. Clarify you code's intent.

Cunningham's metaphor Few systems remain completely free of design debt. Wired as we are, humans just don't write perfect code the first time around. We naturally accumulate design debt. So the question becomes: "When do you pay it down?"

And so, refactoring! Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. A refactoring is a "behavior-preserving transformation" or, as Martin Fowler defines it, "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior"

Why refactoring?  Code i wrote yesterday is worse that code i'm writing today  Make it easier to add new code  Improve the design of existing code  Gain a better understanding of code  Make coding less annoying  Readability / Testability / Estensibility  bugs correction  ...

When refactoring?  Keeping code clean is a lot like keeping a room clean. Once your room becomes a mess, it becomes harder to clean. The worse the mess becomes, the less you want to clean it.  It's best to refactor continuously, rather than in phases. When you see code that needs improvement, improve it.  On the other hand, if your manager needs you to finish a feature before a demo that just got scheduled for tomorrow, finish the feature and refactor later!

When NOT refactoring?  If it's working, don't change  if you have a poorly factored program  if your code isn't tested, that does what the customer wants and has no serious bugs, leave it alone!  performance matters...

How refactoring Refactoring recipes  extract superclass/interface  rename method/property/variable  replace conditional with polymorphism  replace constructor with factory method  inline method  even more: http://www.refactoring.com/catalog

How refactoring Only refactor when refactoring -- do not add feature during refactoring. Refactoring, or improving the design of existing code, requires that you know what code needs improvement.

How refactoring Each transformation (called a "Refactoring") does little, but a sequence of transformations can produce a significant restructuring. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring process.

How refactoring If you want to refactor, the essential precondition is having solid test (Martin Fowler)

Test-Driven Development Test-driven development (TDD) and continuous refactoring enable the efficient evolution of working code by turning programming into a dialogue.

Test-Driven Development Ask: You ask a question of a system by writing a test. Respond: You respond to the question by writing code to pass the test. Refine: You refine your response by consolidating ideas, weeding out inessentials, and clarifying ambiguities. Repeat: You keep the dialogue going by asking the next question.

Refactoring and pattern There is a natural relation between patterns and refactorings. Patterns are where you want to be; refactorings are ways to get there from somewhere else. (Fowler Martin)

Refactoring and pattern  Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.  There are many ways to implement a pattern. If you don't know patterns, you're less likely to evolve great designs. Patterns capture wisdom. Reusing that wisdom is extremely useful, also when refactoring.

Readings  Refactoring: Improving the Design of Existing Code (Martin Fowler)  Refactoring to patterns (Joshua Kerievsky)  Design Patterns: Elements of Reusable Object- Oriented Software (Gang of Four)  The Pragmatic Programmer (Andrew Hunt and David Thomas)

The sage final sentence Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. F.)

Questions?

http://www.rainbowbreeze.it	18
http://static.slideshare.net	9
http://feeds.feedburner.com	1
http://127.0.0.1:8795	1
http://www.slideshare.net	1

Refactoring 2 The Max

by Alfredo Morresi on Oct 14, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 30

Statistics

Refactoring 2 The Max — Presentation Transcript