Extreme Enthusiasm

Summary: my report of the Italian Agile Day 2006

Sto riprendendo il fiato dopo la giornatona di Agile Day 2006… è stato molto divertente. Nella prima sessione plenaria, dopo che Marco Abis ha introdotto la giornata, abbiamo sentito Nicola Canalini e Luca Minudel, del team Ferrari Racing, che hanno presentato la loro situazione lavorativa, e come hanno implementato le pratiche agili nella loro realtà. Molto interessante, soprattutto vedere come le pratiche agili vengano adattate alle necessità molto particolari di questo team (una particolarità su tutte: alle 14:00 ora locale inizia il Gran Premio, e non ci sono “se” o “ma”!)

Dopo la sessione plenaria, è iniziato l’esperimento Open Space; come diceva Abis, si tratta di una conferenza in cui le chiacchiere nei corridoi sono preponderanti rispetto alle presentazioni programmate. Non avevo mai partecipato a un open space; devo dire che la possibilità di gironzolare e saltare da un gruppo a un altro è molto interessante. Se ho ben capito, in un Open Space “classico” non c’è nemmeno un programma definito; chi vuole iniziare una discussione si porta un flip chart e inizia a parlare. Nel nostro caso un programma c’era, anche se ha subito numerose variazioni in corso d’opera. Uno dei temi della giornata è stato il “pomodoro“, grazie alla presenza di Francesco Cirillo, inventore della tecnica del pomodoro, che ha recentemente pubblicato il suo atteso articolo; e grazie anche alla presenza di numerosi fan del pomodoro, come Enrico Mangano, che ha spesso bloggato sull’argomento.

Io ho tenuto una sessione sul Test-Driven Development, che secondo me è una pietra angolare dello sviluppo agile. E’ ormai la quarta volta che presento questo argomento; la dimostrazione pratica segue da vicino il kata del bowling di Robert Martin. Sono molto contento della partecipazione numerosa e attenta.

Nel pomeriggio ho tenuto una lunga sessione di XP Game, che è una simulazione di planning e iterazione XP inventata da Pascal Van Cauwenberghe e Vera Peeters. Pascal e Vera mi hanno gentilmente passato i file Word originali, così ho potuto tradurlo, per renderlo più accessibile al pubblico italiano. Sono convinto che questo gioco sia utilissimo per capire come funziona il planning agile. Come molte pratiche agili, il planning agile è così semplice che sembra impossibile che possa funzionare; e invece… basta imparare come funziona! Comunque, la sessione è stata molto partecipata e divertente. (Mi scuso per il baccano con gli altri partecipanti… l’acustica ci ha colti un po’ impreparati.) Paolo Polce ha tenuto un’altra sessione di XP Game al mattino.

Putroppo non sono riuscito a seguire quasi niente delle sessioni degli altri; c’era molta gente in gamba che mi è un po’ spiaciuto di non essere riuscito a sentire.

Un problema è stato l’acustica del locale, che rendeva difficile comunicare nell’open space: se uno non era sufficientemente vicino allo speaker non riusciva a sentire, e il rumore delle sessioni vicine aumentava la difficoltà. L’ideale forse sarebbe avere dei paraventi mobili per creare una barriera per il rumore, senza impedire la mobilità della gente fra una sessione e l’altra.

La sessione di pair programming remoto consisteva non in una sessione live, ma in una registrazione audio-video di Davide Varvello e Piergiuliano Bossi che facevano pair programming fra l’Italia e il Canada. La sessione in sè era molto carina; è bello vedere gente che sa fare pair programming bene, e che scrive codice ben scritto, cooperando e commentando quello che stanno facendo. Però non sono convinto che abbassare tutte le luci sia stata una buona idea; era subito dopo pranzo e mi è venuto subito sonno :-/ E poi non si riusciva a leggere bene il codice sullo schermo. Forse sarebbe stato meglio presentarla come una sessione fra le tante, ripetuta a ciclo continuo, piuttosto che come sessione plenaria. Spero che venga messa presto online.

La serata si è conclusa per me presso la prestigiosissima Trattoria Righini, in un posto che chiamare “fuori mano” è un eufemismo, ma che ci ha proposto un menu lodigiano-piacentino veramente eccellente. Raccomando i ravioli di zucca :) Abbiamo fatto una specie di pranzo di nozze per 35 euro, un prezzo che mi pare più che onesto. Complimenti agli XPer bolognesi, che hanno scelto il posto!

Concludendo: mi sembra ieri che partecipavo curioso, intimidito e titubante all’Agile Day 2004… sono stati tre eventi per me epocali. Grazie a Marco Abis, e a tutti i partecipanti!

Summary: Linux is way snappier than either Mac OS X or Windows. So what else is new? :-)

Non c’è niente da fare. Avevo la sensazione che il mio amato MacBook Pro non fosse tanto snappy quanto desideravo e adesso ho capito perché. Ho installato Slackware su una macchina virtuale, e ho installato Rails dentro alla slackware virtuale. Eseguiamo ora un semplice test: time rails. Non fa quasi nulla, serve solo a vedere quanto tempo ci mette a caricare Ruby e Rails e ad eseguire dalla riga di comando. Il risultato: dentro al Linux virtuale ci mette 660 ms , mentre nel Mac OS che ospita la macchina virtuale ci mette 923 ms.

Summary: second part of my report about XP Day Benelux

November 17

Again, it’s difficult to choose among many concurrent sessions. I choose Joseph Pelrine’s and Ben Fuchs’ presentation “Turning up the heat (without getting burned.)” Joseph is a coach and Scrum master; Ben is a psychologist. The idea is an analogy about cooking; when the temperature is too high, food burns; a team might get in bitter fights. At the right temp, the food is cooking, and so is a team. The cooking temperature might be higher than comfortable, meaning that *some* amount of discomfort might be good for team performance. If the temp is too low, the team stagnates and stops improving. Most geeks like me are introverts who will usually avoid conflict; we like “peace.” Yet peace might simply mean that conflicts are tacitly ignored and left unsolved.

So, part of the job of a coach is keeping the temperature of a team in cooking range. There are techniques for defusing destructive conflicts; and there are techniques for productively “destabilizing” a team. It all seems very delicate stuff to me; in fact Joseph recommends to go about it in an agile way: try a small change and evaluate the results in a short iteration. All in all, an amazing presentation; I wish I could know more about this, but it seems a very deep subject, quite unlike anything I’ve been prepared to handle. The most important thing I think I got from this is more confidence in handling conflict in the workplace. Another important thing is “don’t play psychologist”; just like you wouldn’t want a psychologist to write your software.

In the afternoon, I attended Steve Freeman‘s and Mike Hill’s “Telling stories with Fit”. Nice introduction to the complexities of turning waterfall-ish specs into nice Fit tables. The audience was split in teams of five people. Each team was given a spec; ours was about computing fares for a rent-a-car service, and it had more than enough special cases and arbitrary complexities. We had to explain the spec by means of tables, written with a felt pen on a large sheet of paper. After 15 minutes, a presenter from each team had to take the sheet and take it to the next table, to see what the other team could get from it. Then the presenter had to turn their back on the table, and the team was asked to criticise brutally :-) while the presenter takes notes. Unfortunately I could not attend to the end of the presentation; but I think I learned quite a lot about Fit in a very short time.

We still had a little time before our taxi came, so we peeked a little in Pascal’s presentation about “Presentation Zen.” It’s all about effective presentation, and it seems like powerpoint bullets are heavily démodé. Pascal showed us videos from some impressive presenters, like Lawrence Lessig. I can see how powerpoint can get very tiresome. Yet some good presentations I attended in these two days used bullets. I guess that in the end, having content behind the slides is still a deciding factor :-)

Conclusion

One thing I liked was the heavy use of 1-minute presentations. In the morning, the presenters got to present their own stuff in a minute, to help you decide which presentation to follow. At the end of the day, there was a one-minute debriefing given by someone in the audience, about each presentation. Pascal’s blog contains much other interesting notes about the process of selecting and then refining the presentations.

I think it was very much a worthwile trip. I got a lot from it, both about content and about format. The organization was very professional in all respects. The atmosphere was nice, friendly and knowledgeable. Can’t wait for the next time!

Summary: my report of the XP Day Benelux.

November 15, the arrival

I arrive with my friend Uberto to Charleroi airport in the morning. Pascal is so kind to pick us up and take us to Bruxelles on his sleek coupe. We have a nice meal right in the center of the old town, then we meet Philippe who takes us for a long walk around town. Then Pascal takes us to the conference center, a nice hotel in the middle of the autumn Belgian country. In the evening we meet again with them and a few other participants for a dinner in the nearby town of Mechelen. I have too much Belgian beer! Very nice evening.

Willem tells me “if you’ve come here to listen, you’ve come to the wrong conference.” And boy, was he right! Almost all the presentations I attendend in the next two days involved the participants to do some work.

November 16, first day

There’s so many different presentations to attend, and many are run in parallel! It’s a difficult choice. In the morning I attend the Coding Tournament by Markus Hjort and Lasse Koskela. It’s about writing a bot for an online game, and trying to do that in a way that is both XP, and is better than everyone else’s bot. The game is a simplified version of poker. There are a Java and a Ruby toolkit; in principle any language could be used, as long as you speak the right protocol to the Poker server. In practice there’s not enough time to write networking code. If you take the Java or Ruby route, all you have to do is implement an interface; no networking is required.

The rules of the game are simple: you are given a single card, but you can’t look at it. You can only look at everyone else’s cards. Each organizer demonstrated this by holding a card up to his forehead so that everyone but him could see it. Then a round of betting starts. Each player has a choice of staying, folding, or raising the bet. The betting stops when everyone has stayed or has folded. The point of the game is that you must base your decisions on what everyone else has, and how the others are betting.

My pair was Pascal Vogel from Philips, (Hi Pascal!) who doesn’t usually do Java; he knows C# though, and that is enough. We decide on a simple strategy, and write an acceptance test in JUnit for it. Then, we comment out the failing acceptance test, and TDD our way until the AT works. The idea is simply to look at the average value of everyone else’s cards, and fold if the average is high, and stay if it is low. This is more than enough to win a few games against the other bots.

Later we improved on this strategy by raising the pot when the average of everyone else’s cards is very low. Again, first we improved the AT, then we TDD’d until the AT was green.

Yes, it’s a very simplistic strategy. Yes, it may even be wrong (why take the average? The highest card may be more important.) Yet, this strategy won the final tournament! Yep, we won :-) It’s quite a challenge to implement correcly even as simple a strategy as this in about three hours. I don’t think we could have done it as well without TDD. It was tiring work, but not stressful.

My impression is that the choice of the rules is excellent. It’s complicated enough to make it interesting, yet simple enough that you can write a simple bot in the given time. The API you have to code to is adequate. I’m not so convinced about the format of the event though. The idea was to explain the game, and then do four iterations composed of 15′ coding and a 5′ bot tournament. After the fourth iteration the real tournament starts.

I was expecting something more along the lines of “now we coach you to do proper AT’s and proper TDD and proper pairing,” but we were more or less left to our own. Perhaps the organizers saw we were chugging along just fine, and spent their time coaching the other pairs. I was also expecting to be given some intermediate goals other than “write the best bot.” Something like, “first write a bot that always stays; then write a bot that folds when someone else has an ace”. I think the format of the presentation could be improved along these lines. I was given permission by Markus and Lasse to replicate the event, and I intend to try it with my local XP user group. Thanks guys!

In the afternoon I followed Vera Peeters presentation about simple design. It’s about how software can be made simple by not implementing unneeded features. The case in point were unit testing frameworks for C++, and how Vera got along fine with a tiny framework of her own, that was essentially just a few macros. After a brief presentation about what is good design, Vera asked us to form groups of five to six people. Then she had us write down on cards features of testing frameworks in general. Then she had us estimate how useful that feature is to us, and how well supported it is in our favourite testing framework. This allowed us to plot each feature on a graph and see how features are clustered. Finally, each group had to select a presenter to discuss and relate their findings. I found the whole experience interesting, both because of the subject matter, and because of the way the event was run. Quite unlike any conference I’ve been before!

The last presentation I attended was “A Fugue about Paradigms and Functional Programming”, by Emmanuel Gaillot & Christophe Thibaut. It was basically a coding kata done in Haskell. It is clear how skilled the two are at doing these public kata; the dialogue between the two was interesting and witty. Also the cheers at every green bar were fun! I haven’t done functional programming in a long time. It’s nice to see how clear and concise a functional program can be. The final program was a composition of functions; it involved very few variables, and no control structures except recursion (and it was very simple recursion.) The use of pattern matching pretty much does away with conditional statements. Getting rid of control structures is a worthy goal in code style, IMO. A great many important topics were demonstrated in very little time; interested people should definitely get a book about functional programming. The point of the exercise was also to pitch for a more functional style of programming, even when we program in non-functional languages. Modern languages like Ruby make it easy to do so.

In the evening, we are treated to a fine Belgian dinner. I manage to drink less this time!

Stay tuned for my report of the next day…

Summary: the Boccioni exposition in Milano is very nice

Ho appena visto la mostra di Boccioni al Palazzo Reale; sono molto contento. Il tema è Boccioni scultore; salta fuori che l’attività di scultore si è limitata a pochi mesi, nei quali ha prodotto poco più di una dozzina di sculture, molte delle quali oggi perdute. In mostra c’è il famoso omino in movimento, quello che appare sulla moneta da 20 centesimi, e lo “Sviluppo di una bottiglia nello spazio.”

Ci sono anche molti disegni e alcuni dipinti bellissimi. La creatività e l’energia dei primi dieci anni del novecento dove sono adesso? Boccioni dipingeva, scolpiva, sfidava le avanguardie parigine sul loro terreno (la natura morta con bottiglia…) scriveva libri, teneva conferenze… E ogni cosa pareva dare uno spunto per idee nuove. La stessa idea che il pittore dovesse celebrare la bellezza femminile gli dava l’idea per l'”Antigrazioso”, per cui la bellezza canonica veniva di proposito evitata (e sbeffeggiata!)

Divertente il suo “Manifesto tecnico della scultura futurista”, che inizia con

La scultura, nei monumenti e nelle esposizioni di tutte le città d’Europa, offre uno spettacolo così compassionevole di barbarie, di goffaggine e di monotona imitazione, che il mio occhio futurista se ne ritrae con profondo disgusto! Nella scultura d’ogni paese domina l’imitazione cieca e balorda delle formule ereditate dal passato, imitazione che viene incoraggiata dalla doppia vigliaccheria della tradizione e della facilità.

Sembra quasi di sentire parlare un ardente sostenitore dei metodi agili:

Il software, nelle aziende e nelle università di tutte le città d’Europa, Asia e America, offre uno spettacolo così compassionevole di barbarie, di goffaggine e di monotona imitazione, che il mio occhio agilista se ne ritrae con profondo disgusto! :-)

Unica nota di demerito: non c’era in vendita neanche un manifesto, eccetto la locandina, troppo scarsa perché mi venga voglia di appenderla in casa. In compenso, milioni di manifesti di Tamara De Lempicka, che fanno un effetto molto volgare dopo aver visto tutti i Boccioni.

Insomma, nei primi del novecento l’arte figurativa veniva rivoltata come un calzino dagli artisti europei (e russi); come anche la musica. La matematica veniva scossa nelle sue fondamenta dai paradossi portati alla luce dalla logica. La fisica veniva ribaltata dalla relatività, e poco dopo dai quanti. Vedremo mai un periodo simile a quello?

Summary: nice paper by Jeff Langr on the subject of mocks

Pubblicato oggi nella sezione file della lista http://groups.yahoo.com/group/testdrivendevelopment/

No perfect way to implement mocks exists. … This should suggest that while mocks can be useful in testing, they introduce other issues into a system … Mocking is still an extremely valuable tool. Slightly imperfect design is almost always the better choice over the inability to test. But the rule for mocking is still, don’t… unless you must.

Langr esprime alcune perplessità che ho sempre avuto sui mock, ma che non ero in grado di spiegare bene. Introdurre un mock comporta sempre una modifica al design del sistema, che non sarebbe stata introdotta se non per il testing. Io sono sempre dell’idea che vale la pena di introdurre modifiche nel codice, se sono necessarie per testarlo. Qualsiasi circuito integrato contiene della circuiteria che ha il solo scopo di testarne il funzionamento. Jeff discute le possibili alternative: passare l’interfaccia da mock-are nel costruttore, con alcune varianti, oppure la soluzione preferita, il deferred factory-based mocking..

Sono d’accordo con le conclusioni di Jeff:

• Meglio usare i veri collaboratori di una classe, se possibile, piuttosto che un mock.
• Non usare i mock come scusa per non sforzarsi di trovare un design meno complesso
• Preferire lo state-based testing al test basato sulle sequenze di chiamate attese; quest’ultimo rende difficile il refactoring
• meglio usare un mock fatto a mano, piuttosto che un jMock o simili

Summary: nice exchange on the TDD list

Phlip:

Change your code to meet these ideals, in this order:

• 0. matches your community agreements on style
• 1. passes all tests
• 2. clear and expressive code
• 3. no duplication of _behavior_
• 4. minimal classes, lines, and methods

Item 0 goes before 1 because you can’t TDD good style. Things like
when to use a reference or pointer, when to capitalize, etc. This is
too low-level to TDD, so just write it.

Item 1 is TDD. Do this before Refactoring, which is 2., 3., and 4.

Item 2 is before item 3 because for some languages (such as C++) if
you squeeze out the last drop of duplication, you will have unreadable
code. Only remove duplication in ways that improve the style.

And 4 is your “simplify” thing. Balance out the classes and levelize
your packages.

Jeffries:

I personally refactor for all the purposes you list, and perhaps more. Removing duplication, for me, is the first thing I look for, and still carries much of the weight, especially as I learn new ways of recognizing duplication. It’s a good first step to better code.

Phlip:

To teach us to improve things, we spread the definition of “duplication” as wide as possible, beyond mere code cloning. For example, the numbers 4 and 6 may, in context, actually represent 5-1 and 5+1. Remove optimizations to inspect latent underlying concepts.

When we refactor 4 and 6 into their actual behaviors, 5-1 and 5+1, we are increasing the amount of duplication on purpose, to then merge it. The only difference between those expressions is the – and +.

In general, if you have two situations that look generally the same, you should should refactor them, separately, until they are more similar. Then you might merge them together. Put another way, don’t merge them together until you first prove they are equivalent.

Jeff L:

As fasr as why “only” emphasize eliminating duplication: first, the
presumption is that we’re doing TDD, otherwise we don’t have the
confidence to do much of anything with the code. Doing just TDD should
already give us a significantly better design, because of its impacts
on coupling and correctness.

If we just did TDD and eliminated all duplication, our system would be
of significantly higher quality than 99.9% of all other systems out
there. Maybe that’s all we need.

Summary: cool simple program design lesson on Uncle Bob’s blog

Uncle Bob scrive:

In my previous blog (RubarianNotation) I had posted this little code snippet from a Mad Libs program:

  def translate(text)
    questions_and_text = split_questions_from_text(text)
    answers_and_text = replace_questions_with_answers(questions_and_text)
    answers_and_text.join
  end

The variable questions_and_text held on to a list of strings which alternated between questions and text. The question strings looked like this ((an adjective)), and the text was just raw text. So, for example, if my original document looked liks this

((name of someone in room)) took a ((a noun)) today and ((a past-tense verb)) his back.

We would expect the questions_and_text variable to look like this:

["((name of someone in room))",
" took a ",
"((a noun))",
" today and ",
"((a past-tense verb))",
" his back."]

So this variable holds a list of strings of alternating questions and answers.

I did not find the name questions_and_answers satisfying, and started to think that it would be better to use a name more like list_of_strings_of_alternating_questions_and_answers. This variable name is long, so I thought it might be better to create a set of standard abbreviations like ls_alternating_questions_and_answers. And then I stopped myself and realized that I was just reinventing the horror of Hungarian notation. I took this to mean that my program had a design flaw.

So I refactored the program to improve the design. Here’s the impact of that refactoring on the previous snippet of code:

  def translate(document)
    game = make_game(document)
    game.play(GameContext.new(@asker))
  end

What a difference! Remarkably, the first line of both snippets parses the incoming text into a convenient form. The second line of both processes that convenient form, asking the approriate questions and replacing the questions with the answers. And yet the implication of the names between the two snippets is remarkably different. In the first case they are rife with implementation detail. In the second, they tell you whats going on at an abstract level.

There is a more important difference between the two snippets. In the first we are operating on data structures, which is why we want to identify the structure of those data structures. In the second we are telling objects what to do, which is why we don’t care about the structure of the objects and can focus on their intent instead.

Of course this is just good old OO. But for an old C++/Java/C#-head, like me, this is something of an eye-opener. Ruby has very rich primitive types like lists and maps. You can use them to create lists of lists and maps of lists and lots of other deep and convoluted structures. Indeed, that’s what I had done in the first snippet. I had created a semantically rich data structure composed of a list of strings that alternated between raw text and questions. What I have come to realize is that although slinging these rich data structures around is fun, it’s also bad.

As I said in the previous post, we want our variables to hold objects that we can tell what to do, we don’t want our variables holding data structures that we operate on. If we use the former strategy, then the variable names don’t have to encode the structure of the data. Rather they, coupled with the methods that are invoked against them, let us know what we expect the object to do.

Questo articoletto insegna una cosa preziosa: evitare di passare in giro array e liste. In Java, per esempio, spesso uno si chiede se un dato metodo debba restituire un array, oppure una lista:

  List employees();           // meglio questo
  Employee[] employees();     // oppure questo?
  List<Employee> employees(); // o magari questo?

In molti casi la risposta potrebbe essere nessuno dei tre. Meglio restituire una classe ad hoc:

  Employees employees();

Nel primo caso, il codice per iterare sulla collezione dipende da che tipo di collezione ho scelto.

  // caso array
  Employee[] e = employees();
  for (int i=0; i<e.length; i++) {
    e[i].printSlip();
  }
  // caso lista
  List e = employees();
  for (Iterator i=e.iterator(); i.hasNext(); ) {
    ((Employee) i.next()).printSlip();
  }

Potrei addirittura essere tentato di codificare il tipo della variabile “e” nel nome: empList, empArray. Brutto no? Usando la classe ad hoc invece abbiamo:

  Employees e = employees();
  e.each(printSlip);

o addirittura

  employees().each(printSlip);

dove “printSlip” è un oggetto di un’altra classe ad hoc. (Scuse a Francesco Cirillo per avere copiato il suo esempio!)

Questo principio di design è un caso particolare di un principio più generale che consiglia di evitare setters and getters. Ad esempio è brutto

  return rectangle.width() * rectangle.height();

Molto meglio mettere dentro la classe Rectangle un metodo per calcolare l’area:

  return rectangle.area();

In questo modo il nostro codice non si interessa più alle viscere dell’oggetto che riceviamo, ma delega il comportamento all’oggetto stesso. Questo codice continuerà a funzionare anche se gli passiamo un oggetto che rappresenta un cerchio, purché quest’oggetto risponda al messaggio “area”.

Il duo pragmatico ha coniato questo slogan: Tell, Don’t Ask. Non chiedere a un oggetto cosa contiene. Digli di eseguire la sua operazione.

Summary: third meeting of the Varese XP User Group today. The topic: agile planning

Terza riunione del neonato Varese XP User Group. Presenti in 9; argomento: pianificare l’applicazione Examinando.

Dopo la lezione di Applicazioni Web, ci siamo trovati in un’aula prestata dall’Insubria. Abbiamo fatto uno stand-up meeting facilitato da Piero; poi Federico ha ricapitolato che cosa deve fare Examinando. Si tratta di una semplice applicazione per la prenotazione delle date degli appelli, per i docenti dell’Insubria. Quindi ci siamo riuniti intorno a un tavolo e abbiamo scritto le carte. Queste ultime due attività hanno richiesto un pomodoro (gergo per un periodo di 25 minuti).

Dopo la pausa canonica di 5 minuti, abbiamo stimato la difficoltà delle storie. Abbiamo usato il metodo di Pascal, che è poi quello dell’XP Game: prima ordiniamo tutte le carte per difficoltà. Abbiamo ottenuto 4 cluster di carte. Poi abbiamo scritto “2” sulle carte più facili, e via via abbiamo assegnato un numero alle altre. A questo punto tocca al cliente, nella persona di Federico, prioritizzare le storie.

Qui ci siamo scontrati con diverse difficoltà. Non abbiamo molto tempo per lo sviluppo (probabilmente due ore ogni due settimane.) Non abbiamo mai lavorato insieme. La maggior parte di noi non ha confidenza con la tecnologia che useremo (ovviamente Rails.) Tutto ciò rende estremamente difficile parlare di “iterazione”. Sono poi gli stessi identici problemi che abbiamo affrontato con lo user group di Milano.

Allora abbiamo semplicemente chiesto al cliente di scegliere storie per 8 punti; queste sono quelle che per lui sono assolutamente importanti. Senza promettere date, ci siamo impegnati a farle. Prima o poi :-P

In tutto il planning ha richiesto meno di due pomodori. Abbiamo fissato la prossima riunione per mercoledì 1 novembre, ore 11:00 o 11:30.

Aggiornamento: ovviamente il primo di novembre è festa :) La riunione è spostata al 31 ottobre, ore 12, aula 2.06 in Via Ravasi

Summary: with careful refactoring you get concision and clarity.

Questo è un frammento di codice di una famosa applicazione open source:

  public boolean isTitleValid() {
    if((title==null) || "".equals(title)) {
    return false;
    }
    return true;
  }

Brutto vero? Perché scomodare un if-then-else? Un valore booleano può essere restituito direttamente. Prima facciamo un passo di refactoring:

  public boolean isTitleValid() {
    if (! ((title==null) || "".equals(title))) {
      return true;
    }
    return false;
  }

Ora possiamo eliminare l’if-then-else.

  public boolean isTitleValid() {
    return (! ((title==null) || "".equals(title)));
  }

E così risparmiamo tre righe su sei: 50%. Eliminiamo tutte le parentesi inutili, per capirci meglio:

  public boolean isTitleValid() {
    return ! (title==null || "".equals(title));
  }

Applichiamo De Morgan per portare la negazione all’interno:

  public boolean isTitleValid() {
    return title != null && !"".equals(title);
  }

E non è finita; eliminiamo una delle negazioni:

  public boolean isTitleValid() {
    return title != null && title.length() > 0;
  }

Ora questo codice è 50% più corto, e molto più “parlante”: l’intento è evidente, tanto che si può leggere “il titolo è valido se non è null e la sua lunghezza è maggiore di zero.”

Visto quanta cura si può impiegare utilmente per poche righe di codice? Il bravo Steve McConnell ha impiegato 900 pagine di dettagli sull’arte della codifica, nel suo Code Complete, seconda edizione.