The Agile Samurai Quote

"when reality messes with your plan, you change your plan—not reality. "

- Jonathan Rasmusson

"If art interprets our dreams, the computer executes them in the guise of programs! "
-Alan J. Perlis

Structure and Interpretation of Computer Programs

I have started a new endeavor of reading the book that give title to this post, Structure and Interpretation of Computer Program. I only have read thought the foreword, by Allan J. Perlis, and the preface. I'm already impressed.

The Foreword - Computer Programs and programing

Allan starts with and excellent summary on what is a program :

"Every computer program is a model, hatched in the mind, of a real mental process."

He goes on on explaining how the program evolves as we learn about the subject of our program. And the promises that this books teaches the small idioms, an arsenal of standard programing structures, that we will use to create larger systems.

Preface - Programing is about Expressing Ideas.

The two major concerns tackled by the book:

• A program is about expressing ideas, thus programs must be written for people to read, and only incidentally for machines to execute.
• Programing is not about the language the syntax or any particular language construct. But about the techniques used to control the intellectual complexity of large software system.

The final promises of the book is the student should have "a good feels for the elements of style an the aesthetics of programming". What part of a big system to read, and what part not to read, what layer of abstraction needs to be understood, in order to work with such a system.

Final thought - Programing Style.

My programing style has been highly influenced by Kent Beck, Martin Fowler, Bertrand Meyer, Uncle Bob and Rod Johnson with their impressive work from Implementation Patterns, Refactoring: Improving the Design of Existing Code, Object-Oriented Software Construction, Aguile software development and the spring source code, respectively.

I got interested in this book because of Clojure and functional programming. Now I have a higher expectation. I'm guessing that, with this book, my programming style will evolve once more. I cant hardly wait to get to end of the book.

The only constant is change

The Schedule is the one way the project will not proceed.

-Johanna Rothman, "Manage it!"

OO Design and Eclipse VS Code Duplication and Copy-paste

"It has a duplication that is painful to my eye"
- Martin Fowler Analysis patterns

The fundamental problem with copy paste is code duplication. Code duplication brings many issues with it, explained in several books and principles, like the "DRY" principle in "The Pragmatic Programmer", or the "Minimize Repetition" principle in "Implementation Patterns". So what's the problem with duplication? In Kent Beck words:

"Duplication isn’t evil, it just raises the cost of making changes."
- Kent Beck, Implementation Patterns.

Why it raises the cost of making changes? Here are a few reasons:

• Change a thing in duplicate code means change in several places.
• Do all need to change? The cost of changing them all is the number of copies you have.
• If the code duplicated has a bug, there is not a single reference where to fix it.
• You drag everything - coping a method but then you forget to change the documentation, the variable names etc...

Object Oriented Design vs Code Duplication.

When you start seeing code duplication, your code will be shouting that there is a missing abstraction. In that case you can do one of the following refactors:

• Extract Method - For code duplication in the same class.
• Extract Class - Some methods are only related to some data on your class, it time to break it down.
• Form Template Method - Sometimes you are copy-pasting procedures or algorithms. In that case use the Template method pattern and possibly turn it into his own Class. A good example for this is the JDBCTemplate in the spring framework. Also a good read explaining how this work is the article Avoiding Repetition by Martin Fowler.

What about static methods?

Its common in Java world to avoid duplication using static methods, but they loose the biggest benefits in OO programing, a local context that simplify the logic. And don't forget that it also makes Unit Testing Harder. So try to avoid them as a solution to avoid code duplication.

Not completely against static methods. Just be sure that you are not missing an abstraction. There can a be a new object that is waiting to come alive. Take a look at "replace Method with Method Object".

Eclipse vs Copy Paste

Once creating a level of abstraction is not longer beneficial, do not use copy paste. Let your IDE do the work for you. All Modern IDE have a template solution a few key strokes away - In eclipse you would never type "System.out.println()" do you? you would do "sysout" then Ctrl+Space. Here is a list of article on how to create your own templates:

• http://eclipse.dzone.com/news/effective-eclipse-custom-templ
• http://eclipse.dzone.com/news/visual-guide-templates-eclipse

The three strikes rule

Use the three strikes rule, copy-paste one, copy-paste two, copy-paste three, Refactor! - or at least create the eclipse template ;) .