> Il giorno 10 mar 2016, alle ore 02:34, Marco Beri <marcob...@gmail.com> ha > scritto: > > 2016-03-09 23:53 GMT+01:00 Giovanni Porcari <giovanni.porc...@softwell.it>: > Comunque i bachi più insidiosi, purtroppo non li scovi con i test. > > Giovanni, > credo sia "the other way around". > > Non è che i test ti fanno scoprire i bachi. > > I test ti garantiscono le non regressioni (e già questo li rende > irrinunciabili). > > Poi, quando scovi un baco, la prima cosa da fare è scrivere un test che lo > evidenzi. Solo dopo lo correggi (e te ne accorgi quando passa il test che lo > evidenziava). > > Così è più faticoso che fixare subito il baco? Certo. Ma a tendere è più > conveniente? Più certo ancora. Dici che c'è del codice non si può testare? > Chiedi a Valentino, lui ti direbbe che non esiste codice siffatto :-) > > C'è chi sostiene che un bug è in realtà un test non scritto. >
Marco non pensare che non sia convinto della necessità di avere dei buoni test in modo da non essere mai a rischio di regressioni. Sono certissimo che sia ottima cosa. Come sono certo, ma davvero certo, che un'ottima documentazione sia la chiave di volta per avere un prodotto condivisibile con altri sviluppatori. Come sono certo del fatto che dovrei finalmente rompere gli indugi e passare a python 3. Purtroppo, da imprenditori, e io sono un piccolissimo imprenditore, sappiamo che ci sono costi che ti puoi permettere e costi che non ti puoi permettere. Magari vivessi in un altro paese troverei fantomatici finanziatori in grado di assicurarmi le risorse per fare tutto senza dovere ipotecare la casa dove vivo. Quindi devo fare delle scelte, che, per carità, possono essere alla lunga anche scelte sbagliate. Ma gli aspetti economici di un progetto sono comunque importanti. In Softwell siamo in tutto 5 sviluppatori e abbiamo scritto tutto Genropy e una serie di applicativi che vanno dalla gestione dei trasporti, alla gestione dei contratti editoriali, poliambulatori, condomini, gestione di produzione e da ultimo Erpy, che è un ERP che sta venendo proprio benino. Tra tutte queste cose l'attività che ci è costata di più è stata di volta in volta la migrazione dei dati da sistemi legacy che andavamo a sostituire. Gestire degli interregni in cui il sistema legacy e quello nuovo coesistono e devono essere tenuti sincronizzati è un piccolo grande incubo. Poi un altro aspetto che è davvero oneroso è stare dietro alle fantastiche trovate dei nostri governanti. Realizzare in 2 settimane uno 'spesometro' che deve riclassificare 'ad minchiam' dati caricati nell'anno precedente e trasmetterli a chi di dovere con un formato demenziale è qualcosa che solo chi lo ha fatto può capire quanta fatica costi. Ora purtroppo in questa attività 'concreta' e fatta di costi da tenere d'occhio, clienti da tenere buoni e opportunità da non perdere, il tempo è quello che è. La ricerca di bachi è, per fortuna nostra, un qualcosa di poco impegnativo o perchè siamo molto ma molto fortunati o magari perchè la struttura di Genropy, il modo in cui è stato ideato e scritto, rende i bachi un evento abbastanza inconsueto. Ti racconto l'ultimo baco che abbiamo dovuto scovare. Un certo giorno di circa un mese fa, Google ha improvvisamente aggiornato Chrome introducendo un comportamento misterioso che rompeva il reload delle nostre pagine. Ovvio che un baco così significa che tutti i clienti ti chiamano più o meno contemporaneamente (il fatto che Google ti aggiorni in modo automatico è una delle cose che detesto di più) e quindi dovevamo trovare il baco e risolverlo nel giro di minuti. Dopo circa mezz'ora di imprecazioni e lavoro, il fix è stato fatto e consisteva nel rimpiazzare nel NOSTRO metodo 'reloadPage' l'istruzione: window.location.reload(); con: window.location.assign(window.location.href); Questo mi dice 2 cose: la prima è che se nemmeno il sistema di test di Google gli fa trovare bachi di questo genere prima di aggiornare centinaia di milioni di browser per il mondo, allora i sistemi di test sono comunque fallaci. La seconda cosa, assai più importante, è che wrappare in metodi TUOI il codice secondo la funzione svolta è estremamente importante. Avrei potuto avere in giro centinaia di chiamate a "window.location.reload();" magari in n repository e cambiare tutto ovunque sarebbe stato molto dispendioso. Il fatto di usare il nostro metodo 'pageReload' invece dell'istruzione base ci ha consentito di fare un unico fix nel framework, pusharlo e fare un pull in tutti i sistemi dei clienti. Quindi in meno di un ora il baco è stato sistemato. Se avessi dovuto procedere secondo la metodologia canonica, avrei dovuto scrivere un test in javascript che facesse un reload di pagina e verificasse questa tipologia di errore. Forse sarei ancora qui a grattarmi la testa per capire come fare :D Quindi, riepilogando: 1) Concordo sul fatto che un buon sistema di test è ottima cosa e andrebbe speso tutto il tempo e le risorse necessarie per averlo in piedi. 2) Nel passaggio a python 3 (che spero di affrontare in autunno) mi propongo di partire proprio dalla revisione dei test e passare poi alla conversione vera e propria. Un passaggio di questo tipo senza test è semplicemente impossibile. 3) Abbiamo una piccola pattuglia di sviluppatori che hanno imparato ad usare Genropy e che spero ci potranno aiutare anche nel preparare i test. Il fatto che in questa pattuglia manchino persone del tuo calibro e della tua esperienza è purtroppo qualcosa che mi spiace tantissimo ma, come sai, non dispero di averti a bordo prima o poi :P Con questo chiudo il mio sproloquio e auguro a tutti una splendida giornata :) G _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
