undesigned

In summary: write tests, run tests continually, design modules so that they are open for extension but closed for modification (you can add functionality without changing the existing code) refactor periodically, clean up your code before it stinks. Here are some interesting quotes:

“It was too easy to make a mess in Smalltalk” Ward Cunningham (Dynamic languages allow you to be undisciplined.)

Fundamental dilemma. Bad code will fundamentally slow me down. But when faced with a deadline, we go ahead and write bad code anyway. Showed productivity vs time curve. As a project wears on you become less and less productive. The only solution is to clean up the code.

Possibilities:

• Grand redesign in the sky?
  • It will take forever
• Incremental improvement
  • Always check code in better than you checked it out.
  • Never let the sun set on bad code.
  • Test First! – Provides the necessary flexibility.

RSpec & TestUnit – unit testing frameworks. Write your tests first. Target 100% coverage.

Showed an example of building out a command line argument parser. Starting with handling boolean arguments, then other data types.

Discusses the problem with if-else statements:

• They tend to duplicate themselves. If you want to change the code you need to duplicate it in lots of places.
• The original design pattern did not scale.
• Violates the DRY principle and the Open Close principles. Applications should be open for changes but closed for modification. Design so that you can add functionality without changing existing code.

Refactor when you smell a mess (festering pile) not when you have a mess (as early as possible). So there is this fine balance be over-engineering and keeping your code clean. So clean it when it starts to smell and not before.

Similar to writing essays, we should re-write code periodically.

Incrementalism

Don’t make massive changes in the name of improvement.

• TDD: Keep the system running at all times! I am allowed to make a change that breaks the system. Every tiny change I make must keep the system working.
• Running tests helps point out all of the places that changing the code impacts.

Get into the feel of running the tests continually. Autotest is a product that allows you do this.

Continuing his demo he showed how by creating marshallers he was able to move most of the data type specific code into one place.

Software is about separation of concerns. Segment code that changes according to how often they change. Put things that change a lot in a different place than those things that don’t.

Was it worth it? (refactoring his demo code) If you are worried about function and function alone you should not be in this business. If you are not a craftsman you shouldn’t be here.

The Green Band (A wrist band he wears)

• Professionals write tests first
• Clean their code
• The only way to go fast is to go well

Making a mess is not faster.

Posted on May 18th, 2007 by joel
Filed under: conferences