Un giorno agile

Road Runner Venerdì sono stato all’Agile Day di Bologna. Ho sentito parlare di argomenti molto interessanti: le user-story, il pomodoro (che già in parte conoscevo), i contratti “agili” (un sogno, se solo si trovasse un cliente disposto ad accettarli!). Poi ho visto una cosa per me troppo estrema: la maglietta della campagna “anti-if” di Metodi Agili! Cavolo, quando mi dissero più o meno vent’anni fa che il goto era il male ho afferrato subito il concetto. Adesso che mi dico lo stesso dell’if, sono semplicemente divertito e totalmente scettico.

Forse saranno i vent’anni che hanno ridotto la mia elasticità mentale, ma io l’if me lo tengo ben stretto!

8 thoughts on “Un giorno agile

  1. Beh… magari magari, potrei essere semi d’accordi su “anti else” a favore di un doppio “if”… ma un “anti if”… MAI!

    Figuratevi che io programmo in un linguaggio che non ha nemmeno i repeat, i while, i case of… ecc… quindi per leggere un elenco o un file, sono quasi costretto a usare i GOTO.

    Fortunatamente mi sto cimentando a studiare un super “nuovo” linguaggio:
    PYTHON non so se lo conoscete 😉

  2. C’ero anche io! If è male in codice OO. Codice propriamente Object Oriented non dovrebbe avere bisogno di if, switch, etc. Nel 99% dei casi se ci sono significa che il codice non stà sfruttando le potenzialità del paradigma OO.

    • Giangio, ammettiamo che hai da calcolare un importo e che alla fine devi applicare o meno il bollo a seconda se l’importo supera 1.000 euro. Mi spieghi come fai a farlo in OO in un modo più pulito che non con un if? Non sto dicendo che non sia possibile farne a meno, sto dicendo che ci sono situazioni dove farne a meno ad ogni costo è puro fanatismo. E quando tu dici 99% già implicitamente ammetti che non si può rinunciare all’if. “Aboliamo l’if” per me significa quello che significa, non “Aboliamo quasi l’if” 😉

  3. Peraltro, non mi è del tutto chiaro come il paradigma OO (che non è che di suo mi stia a genio) possa fare a meno dell’If.

    Se la “soluzione” è un “compareTo” alla Java, torno a programmare spaghetti. 😛

  4. Perdono il doppio post, ma ho letto la pagina con la descrizione e l’esempio… e mi sfugge il senso. Quella è solo buona astrazione e non ha molto a che vedere con l’if in sé. 😮
    If che tra l’altro in quelle situazioni in realtà è sempre presente, soltanto si sposta ad un livello superiore (perché se nella classe X mi arriva un oggetto e non una stringa, significa che da qualche parte sopra avrò convertito da un input dati in un oggetto… con un if, unico modo di fare branch del codice).

    Tra parentesi, non apprezzando molte delle ‘esagerazioni’ dell’over-ingegnerizzazione che nel 99% dei casi si trova nell’OOP (99% non a caso :P) mi chiedo perché dovrei creare 5 classi (e in certi linguaggi 5 file) per evitare un semplice – E CHIARO – if.

  5. La campagna anti-if (stamane 1 dic al javaday romano c’è stato un intervento di Francesco Cirillo, dell’xpLabs) è ovviamente provocante, va presa con le pinze e fa parte dell’extreme Programming, un modo “estremo” di programmare in cui vige il paradigma della VERA programmazione ad oggetti (pochi ancora ne hanno capito le potenzialità), l’ingegnerizzazione dei processi, il refactoring (quello vero) e una serie di concetti descritti dai metodi appunto Agili.

    Il punto, secondo me, è che si va fuori strada se si prende alla lettera la frase anti-if, ma ancor più se non si accetta l’affermazione “nel 99% non uso if” neanche avessimo detto “nel 2% non uso gli if”. Il paradigma di programmazione estrema si avvicina molto a Ruby on Rails, se può servire come metro, cioè cercare di pulire il codice da zozzerie costituite da righe piene di if, in modo da DISACCOPPIARE il più possibile il codice.

    E’ normale che l’if esiste ed esisterà sempre, ma lo si scrive solo una volta, è questo il senso. Se mi trovo in una situazione di casistica nuova, cioè se arriva un nuovo caso da valutare, non uso nessun if se ho costruito il codice in maniera da usare piu oggetti possibili, senza dare più di una RESPONSABILITA’ a ciascuno.

    E’ un’utopia per certi versi, ma fa tutto parte dei processi di INGEGNERIZZAZIONE del software, dell’uso de PRINCIPI dei pattern (non ho detto dei pattern, ma dei PRINCIPI dei pattern…) e dei metodi agil. E quelli o li studi e li assimili all’università (pochi prof in Italia ne sanno, e Luca Cabibbo di Roma Tre è uno di questi), o capiti in un team che ne fa uso (pochi, pochissimi). Qua il problema non è il linguaggio in se (io credo che con RubyOnRails si fa Xp alla grande, più facilmente che con Java, ma il punto è un altro) ma il cervello umano: se vogliamo risparmiare tempo (e il tempo è denaro) e provassimo ad imparare bene l’xp capiremmo quanta fatica risparmiata ci sarebbe in futuro. Il codice scritto bene TI PARLA, cioè lo capisci al volo, bastano poche righe, nelle quali non ci sono if, ne for o for_each che tengano!!

    Detto questo, dico che la realtà dei fatti e la forma mentis che la maggior parte di noi ha, porta a dire NO a cose di questo tipo. Pensiamo a quanto ci “rompe” dover cambiare linguaggio per fare una cosa… saremmo piu felici se passassimo una settimana a ravanare col nostro amato linguaggio, più che trovare dei metodi piu veloci ed efficenti, è ovvio.
    In fondo l’if è una passione forte x privarsene cosi facilmente e noi siamo in fondo un po’ presuntuosi con noi stessi avendo spesse volte dei preconcetti bizzarri 😉

  6. Teo, perdonami, ma continuo a credere che sia un eccesso provocatorio. Per shockare ci vuole un eccesso, ma poi per educare non si può usare un eccesso. 🙂

    Perché io sinceramente ho paura dell’over-ingegnerizzazione tanto quanto vedere 20 if annidati o if che svolgono la stessa funzione in parti differenti del codice.

    Sono gli *eccessi* il problema, ed è il motivo per cui non riesco ad apprezzare la campagna anti-if, per quanto possa sposare gli ideali che vorrebbe portare avanti. 🙂

    Come ho detto sopra: “Quella è solo buona astrazione e non ha molto a che vedere con l’if in sé.”
    Educare a programmare? E’ utilissimo, fondamentale e lo vedo poco praticato. Non credo però sia utile prendersela con l’if. 😀

    Vuoi sapere una frase ad effetto che ritengo molto più universale e capace di portare avanti la stessa campagna, potenzialmente?

    “Se scrivi la stessa cosa due volte, stai sbagliando”.

    Questo può significare diverse cose e come noti è un principio guida che include quello anti-if, provocando, senza molti degli aspetti negativi. Un if non è sbagliato, se serve a quella funzione in un punto solo nel codice, perché significa aver fatto l’astrazione al punto giusto. Se ci sono due if che svolgono due funzioni analoghe in due punti diversi del codice (come suggerisce ma non chiarisce il codice d’esempio sul sito della campagna) allora si, bisogna cambiare il livello di astrazione (portando ad esempio più a monte l’if). Questo peraltro si coniuga molto bene con i principi XP, perché significherebbe che quelle parti han bisogno di refactoring e quindi si procede. 🙂

Leave a Reply to Folletto Malefico Cancel reply

Your email address will not be published.