[Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

[enrico franchi]

2016-03-10 14:21 GMT+00:00 Giovanni Porcari <giovanni.porcari a softwell.it>:

>
> Si. Tutto vero.  Tutto sacrosanto. Tutto giusto.
>
> Però come dicevo in un'altra mail è un problema di risorse che puoi avere
> e non avere
> e le compatibilità economiche non sono meno importanti di quelle tecniche.
>

Si, appunto. Per determinati business (che so, se fai servizi web based) il
costo di un baco in produzione sufficientemente grave puo' anche nella
peggiore delle ipotesi farti chiudere baracca. Se i clienti perdono fiducia
nel tuo business, semplicemente non hai piu' clienti (per lo meno, nel
lungo termine). Se il business fa billing sulla base delle transazioni dei
clienti, downtime vuole dire potenzialmente milioni di dollari di mancate
entrate. In ogni caso probabilmente hai delle SLA che devi rispettare, e se
non le rispetti devi sbatterti non poco per scusarti (e generalmente tutto
questo coinvolge ancora una volta mancate entrate)

Certo, se vendi software "boxed" sei in un mondo completamente diverso.
Come e' diverso se vendi soluzioni custom per clienti singoli, e magari ti
va anche bene. Eh, scusa, eravamo giu' per un paio di ore, ma dai, non ti
preoccupare. In altri casi questo e' un pochetto piu' complicato.

Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più
> di 40 anni
> e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'.
>

Eh... che dire. Bravi. La mia esperienza, sebbene molto piu' breve, e'
tutta diversa.

Diciamo cosi'... l'esperienza (breve finche' vuoi) mi insegna a diffidare
molto di questo tipo di affermazioni.

Nel mio mondo, la parola chiave e' "build to fail". I sistemi falliranno.
Il trucco e' essere sufficientemente ridondanti. E il costo ingegnere di
scrivere un test e' assolutamente *nullo* rispetto al costo di tenere in
piedi la baracca (che a sua volta e' completamente trascurabile rispetto al
costo di fallire davvero).

Che poi questo dipenda da fortuna, capacità, senso di responsabilità o
> attenzione non lo so.
>

La fortuna non perdura in eterno, il senso di responsabilita' non aiuta
(ovvero, l'incoscienza chiaramente rema contro, ma non direi che e' un
problema di "senso di responsabilita'"). Attenzione? Forse. Ma vuole anche
dire che il business ha tempi molto lenti (o se vuoi "umani"). Ma
soprattutto, non e' una garanzia. Perche' sei attento fino alla volta in
cui sei disattento.

Se vai a vedere come gestiscono le cose quelli che *non* possono
permettersi bachi *per nulla* (sarebbe piuttosto sgradevole un 404 con
l'omino dei lavori in corso sul monitor del 747 che sta precipitando con
500 persone a bordo -- sorry, we are working for you: ATC will be online in
a couple of hours, please consult your onboard spiritual advisor for your
last prayers). Beh... vedrai che non ti parlano di "attenzione" e "senso di
responsabilita'". Semmai hanno svariati team di QA che fanno test manuali,
automatici, randomizzati e pagano licenze piuttosto costose per tool che
fanno analisi statica e dimostrano l'assenza di determinati bachi in
determinate parti del codice. E a volte tutto questo si rompe e nonostante
tutto si va Arianne 5.

Ora tutto questo ha un costo immenso. Per lo meno vuole dire un ciclo di
sviluppo cosi' lungo che nel mio mondo saremmo tutti fuori dal business. E
quindi via di compromessi. Oltretutto un moderno sistema software e'
*molto* piu' complicato della maggior parte dei sistemi mission critical di
quel tipo (principalmente perche' il costo di non introdurre una feature
puo' essere molto piu' alto del costo del rischio di un downtime).

Forse il rovescio della medaglia è che se ti convinci che i test comunque
> ti parano il culo
> tendi a lavorare con il medesimo.
>

"True man do not write bugs". No. La gente scrive i test quando lavora
bene. Se non scrive i test, dal mio punto di vista, sta lavorando con il
culo. Ci sono talmente tante buone ragioni per scrivere i test... e quale
ragione per non scriverli? Risparmio tempo? In generale si dimostra che non
e' manco vero che si risparmia tempo sul lungo termine. Poi certo, se uno
se la gioca tutta sul fatto che "va in bancarotta sul debito tecnico" ok...
ma non e' un gran piano nel caso generale.

Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta
> attento o è un uomo morto.
>

Ecco... ma noi siamo acrobati che lavorano troppe ore al giorno su un filo
invisibile con illuminazione a lume di candela fatta dal pubblico
sottostante. E il filo non e' dritto ma va un po' di qua e un po' di la. E
un orso ubriaco con la faccia di Bruce Campbell ci sta inseguendo con una
motosega al posto della zampa destra.

Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è
> una cosa meravigliosa.
> Dico solo che io, purtroppo, non me la posso permettere :)
>

E io non conosco il tuo business, per cui non posso e non voglio commentare
oltre. I tuoi clienti sono contenti, restano, e ne continuano ad arrivare
di nuovi? Allora vuole dire che stai facendo bene quello che fai. Puro e
semplice.

Detto questo, io non sono affatto convinto che tu non te lo possa
permettere: di solito quando hai una buona infrastruttura di testing vai
molto piu' veloce a fare tutto.


> Se questo significa lavorare ammerda pazienza. Per ora con questa
> 'ammerda' ho mangiato e
> non ho mai messo in difficoltà i miei clienti :)
>

Ottimo. Mi fa piacere che per te funzioni. Vorrei solo che sia chiaro che
non e' un caso generale che sia facilmente estensibile ad altri business in
modo automatico. Appena cambi un pochetto le regole del business e' facile
che non funzioni piu' tanto bene.


-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20160315/1c90d3a3/attachment.html>