URL: http://code.google.com/p/codeleanrefactoringseminar/downloads/list
How should you refactor your code?

* Incremental refactoring & the Boy Scout rule

* “Leave the campground cleaner than when you found it”

* Code quality

Code Rot & Technical Debt
Code rot – the decay in software that occurs as a result of not updating your software in respect to the changing environment in which resides
Technical debt – The situation that occurs when you opt to postpone some development activities in favor of a shorter release date.
“Agile – the power of moving quickly and easily; nimbleness: exercises demanding agility“
Does being agile means that you get your product out the door as fast as possible?

* Yes..even if its substandard it is still being agile..

Would you deliver a “squirrel burger” if it meants that you could make the deadline?
Is having a technical debt a bad thing?

* Its tactical decision.

True meaning of Agility

* Agility is measured by the speed of change, not the speed of delivery

How do you know if your code is suffering from code rot?

* immobile

* obscure

* rigidity

* fragility

* Dispensible

How do you know if your code is suffering from a code rot?
Code quality – your code base that many bad code smells.
Development effort – it is becoming more and more difficult to understand.
- take more time to work on the same parts of the code in your system.
Productivity – more difficult to change, developers missing deadlines.

Strategies for Code rot

* automated unit tests

* code reviews

* continuous code write

What if theres too much technical debt in your project?

* Rewrite vs. Refactor

* Depends on the time

What happends to shops that don’t refactor?

* The dead sea effect

* code quality drops

* senior developers quits. they can no longer maintain program

* morale in the shop drops. seniors quit.

* New hires come in, new developers don’t stay because of code quality.

* The big ball of mud

* in many case, systems with large technical debts devolve into systems with no discernible architecture or design (aka the “Big Ball of Mud”)

* common in development shops that suffers from the dead sea effect.

* prevent your application from becoming a BBOM by continously refactoring your code.

Refactor or Rewrite?

* rewriting solves the symptom, not the root of the problem

* the real problem is that there is no refactoring.

* The BBOM is the symptom of bad development practices.

* You should only rewrite a system if:

* The system does not work at all

* It is cheaper to create a new system than to maintain the exsiting system

Beware of the Second System effect

* The second system effect is the tendency for developers to redesign a successor system into giant..

The tale of the Squirrel Burger

What would you do?

* For me, I would do give them the squirrel burger for I am thinking of the sales not the quality of burger we have.

Would you serve it?

Answers:

Reckless/Deliberate

* We don’t have time to design?

Prudent

* we must ship now and deal with consequences

* Now we now how we should have done it

Inadvertent

* What’s layering?

Anatomy of a Software Development “Squirrel Burger”

* No Documentation

* Nobody understands how the system works.

* The shop is “agile” so they decided to document

* Low Code Quality

* Inefficient Development Proccess

If it isn’t broken, then why should we even fix it?

* Refactoring as defect prevention

* refactoring makes code easirer to understand and that makes it easier to find bugs on your code

Why refactor our code if the client doesn’t pay us to refactor?

* Refactoring and the story of Louis Pasteur

* During Pasteur’s time, the concept of washing your hands before an operation was thought to be rediculous

* Refactoring is something that clients rarely ask for.

Refactoring Part II

*fizzbuzzzzbaz coding*

The two values of software

* Function

* Form

Some Bad Code smell Examples

* Contived complexity

* Bad design they want to try out.

Single Responsibility Principle
Many bad code smells inviolate this principle.
Its should do only one and one thing.

Does the following code violate the SRP?
Examples:

* Statement-level examples

* Method-level examples

* Class-level examples

Bad code Smells
The Couplers

* siamse twins, kill one affects the otherother

The Bloaters

* Class, that no one undestands it

Object Orrientation Abusers

* Program code they still writing C. Ugly code structure.