CleanCode/2 - It is not enough for code to work

Chiedo scusa a quanti si risentirono pesantemente quel giorno quando dissi che il codice prodotto di corsa in un mese di overtime non fosse di qualità. Perchè di qualità si trattava, non del fatto che funzionasse o meno, non del fatto che il cliente ne fosse soddisfatto o meno. Non era mia intenzione sminuire il lavoro di nessuno.
Perdonatemi, ma...

It is not enough for code to work. Code that works is often badly broken. Programmers who satisfy themselves with merely working code are behaving unprofessionally. They may fear that they don't have time to improve the structure and design of their code, but I disagree. Nothing has a more profound and long-term degrading effect upon a development project than bad code.

Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down. tiem and time again I have seen teams grind to a crawl because, in their haste, they created a malignant morass of code that forever thereafter dominated their destiny.

Of course bad code can be cleaned up. But it's very expensive. As code rots, the moules insinuate themselves into each other, creating lots of hidden and tangled dependencies is a long and arduous task. If you made a mess in a module in the morning , it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it's very easy to clean it up rigt now.

So the solution is to continuously keep code as clean and simple as it can be. Never let the rot get started.

Chapter 14: Successive Refinement - Conclusion - pag. 250

Ricordate quando tante volte abbiamo ripensato al passato e ci siamo chiesti "Ma perchè abbiamo fallito?". Personalmente aggiungo questa qui: non sappiamo scrivere codice pulito.

Il TDD oggi

"It is 2010. I declare that #TDD is no longer controversial."

"@bradwilson #TDD I am not wishing. I am DECLARING. Resistance is futile!"

Uncle Bob - Twitter - 01/01/2010

Agile & Fear

People fear that agile disciplines will cause delays.  The opposite is true.  We use these disciplines because they help us go faster.
Uncle Bob - Twitter - 02/12/2009

@unclebobmartin and because many are developer disciplines and not management disciplines as some understand  management disciplines.
Tim Ottinger - Twitter - 02/12/2009

CleanCode/1 - Procedural code vs. OO code

In questi giorni sto leggendo "Clean Code" di Robert "Uncle Bob" Martin e volevo regalarvi alcune perle che mano mano sto trovando.

Nel capitolo 6 - Objects and Data Structures, pagina 97, circa l'antisimmetria fra il codice procedurale e il codice ad oggetti.

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

The complement is also true:

Procedural code makes it hard to add new data structures because all the functuions must change. OO code makes it hard to add new functions because all the classes must change.

So, the things that are hard for OO are easy for procedures, and the things that are hard for procedures are easy for OO!

Ma anche "est modus in rebus" ;)

Mature programmer know that the idea that everything is an object is a myth. Sometimes you really do want simple data structures with procedures operating on them.

Ammetto candidamente di non aver mai pensato alle differenze fra i due paradigmi in questi termini. Anche per quello mi considero in cammino...