Originariamente inviata da
M.A.W. 1968
Il problema non consiste certo in questa banalità: questa è solo una fallacia di mutatio argumenti.
I criteri per la decomposizione funzionale sono numerosi e l'approccio agile è decisamente riduttivo. Mi limito ad una sola questione elementare, a titolo di esempio: come si concilia questa vaga tensione alla "semplicità" con il criterio di information hiding di Parnas?
La vera questione è comunque ben altra, e vi abbiamo dedicato fin troppi post: copiare la stringa a rovescio per poi confrontarla con l'originale è un'idea naive tanto quanto il bubblesort, ossia un vero e proprio errore progettuale algoritmico che non va in alcun modo incoraggiato. Questo è l'errore rimarginato, un errore decisamente poco difendibile e non giustificabile. Tutto il resto citato in seguito, Fowler e compagni di merende, ha davvero ben poca attinenza: non c'è teorico serio, per quanto poco apprezzato, che possa davvero giustificare una "soluzione" del genere.
Quanto ai testi, le mie bibliografie tematiche sono ben note (e troppo spesso scopiazzate senza citarne la fonte, anche in passato sul presente forum) e c'è solamente l'imbarazzo della scelta: dal classico poker di Knuth col TAoCP al Sedgewick, al CLRS, all'Harel fino alla lunga silloge degli autori minori e specialistici per la parte algoritmica, sfido chiunque a trovare apologie di questo modo assurdo di approcciare un problema del genere.
Quanto ai testi di engineering, per restare alla genericità del mainstream ma con molto più rigore rispetto ad Agile, posso facilmente consigliare gli arciclassici Pressman, Sommerville, e a latere il Mandrioli-Ghezzi (sì, proprio il Ghezzi autore dell'articolo in parola) uniti al Myers "The art of software testing", Wiley che uso nei miei corsi come aperitivo, giusto per iniziare a familiarizzare anche con metodologie non mainstream. Poi ci sono due dozzine di testi specifici per i metodi formali e le metodologie di progetto e verifica per i sistemi critici, se interessa davvero progredire.
