Joel on Software

Joel on Software   Joel sul software

 

Altri articoli da "Joel on Software" in italiano

Altri articoli da "Joel on Software" in inglese

Scrivi all'autore (solo in inglese)

JOEL E IL SOFTWARE

 

Cose da non fare mai, parte I


Di Joel Spolsky
Tradotto da Angelo Dipierro
Redatto da Fernando Marotta
6 Aprile 2000

La prima beta pubblica di Netscape 6.0 sta finalmente per venire rilasciata. Non è mai esistita una versione 5.0, e l'ultima major release, la versione 4.0, è uscita quasi tre anni fa. Tre anni sono un enormità nel mondo di Internet. In quel periodo Netscape è rimasta ferma, inerme, a guardare la propria quota di mercato precipitare.

È un po' ipocrita da parte mia criticarli per aver fatto passare tanto tempo tra le versioni. Non l'hanno mica fatto apposta, vero ?

Beh, sì. L'hanno fatto apposta. Hanno fatto l'errore strategico più grave che una software house può fare:

Hanno deciso di riscrivere il codice da zero.

Netscape non è la prima società che ha fatto questo errore. Borland ha fatto lo stesso errore quando ha comprato Arago e tentato di trasformarlo in dBase per Windows, un progetto destinato a fallire, e che ha richiesto talmente tanto tempo che Microsoft Access li ha messi fuori mercato. E poi l'ha rifatto riscrivendo Quattro Pro da zero, e stupendo tutti con quanto poche funzioni aveva. Microsoft ha quasi fatto lo stesso errore, provando a riscrivere Word per Windows, un progetto condannato in partenza di nome Pyramid, che è stato interrotto, cancellato e nascosto sotto il tappeto. Per loro fortuna non hanno mai smesso di lavorare sul vecchio codice, quindi avevano qualcosa da vendere, trasformando un possibile disastro strategico in uno "solo" finanziario.

Siamo programmatori, e i programmatori in fondo al cuore sono architetti. La prima cosa che vogliono fare quando arrivano in un posto è radere tutto al suolo e costruire qualcosa di grandioso. Non ci interessano i piccoli miglioramenti, il bricolage, le aiuole fiorite.

C'è un motivo sottile per cui i programmatori vogliono sempre buttare via il vecchio codice e ricominciare. Pensano che il vecchio codice sia un casino. Ed ecco un osservazione interessante: probabilmente si sbagliano. La ragione per cui credono che il vecchio codice sia un disastro è una legge fondamentale della programmazione:

 

È più difficile leggere il codice che scriverlo


Ecco perchè il riuso del codice è così difficile. Ecco perchè tutti nel vostro team hanno una funzione diversa per dividere una stringa in un array di stringhe. Ognuno si scrive la sua funzione perché è più facile e più divertente che cercare di capire come funziona quella vecchia.

Come corollario a questo assioma, potete chiedere a qualsiasi programmatore com'è il codice su cui stà lavorando. "È proprio un gran casino" vi risponderà. "Niente mi piacerebbe di più che buttar via tutto e riscriverlo da capo".

Perché è un casino ?

"Beh," vi diranno, "guarda questa funzione. è lunga due pagine ! E niente di questa roba dovrebbe stare qui dentro! Non ho idea di cosa faccia la metà di queste chiamate alla API."

Prima del lancio del nuovo foglio di calcolo per Windows di Borland, Philippe Kahn, il loro eccentrico fondatore, è stato citato spesso sulla stampa vantandosi di quanto migliore di Excel sarebbe stato Quattro Pro, perchè era stato scritto da zero. Tutto codice nuovo! Come se il codice arrugginisse.

L'idea che il codice nuovo sia migliore di quello vecchio è evidentemente assurda. Il codice vecchio è stato usato. È stato testato. Un sacco di bachi sono stati trovati e risolti. Non c'è nulla di male in quel codice. Non è che accumula bachi nuovi standosene parcheggiato sull'hard disk. Al contrario, baby! Il software è come una vecchia Dodge Dart che arruginisce standosene in garage ? Il software è come un orsacchiotto un po' bruttino perché non è fatto di materiale tutto nuovo ?

Torniamo alla nostra funzione di due pagine. Sì lo so, è solo una funzione per aprire una finestra, ma ci è cresciuta intorno un sacco di roba, e nessuno sa perchè. Beh, ve lo dico io perchè. Quella roba sono bug fix. Una è la soluzione per il problema che Nancy ha scoperto tentando di installare il coso su un computer senza Internet Explorer. L'altra corregge il problema che si verifica quando c'è poca memoria. Un'altra fissa il problema che si verifica quando il file stà sul floppy e l'utente caccia fuori il dischetto a metà del lavoro. Quella chiamata a LoadLibrary è orribile, ma fà funzionare il programma anche sui vecchi Windows 95.

Oguno di quei bachi ha richiesto settimane di uso del programma nel mondo reale per essere trovato. Il programmatore potrebbe aver passato un paio di giorni in laboratorio per riprodurlo e correggerlo. Se assomiglia alla maggior parte dei bachi la correzione potrebbe essere una linea di codice, o anche solo due caratteri, ma ci sono voluti un sacco di tempo e lavoro per quei due caratteri.

Quando buttate via del codice e ricominciate da zero state buttando via tutta quella conoscenza accumulata. Tutti quei bachi risolti. Anni di lavoro di programmazione.

State buttando via la vostra leadership sul mercato. Regalando due o tre anni alla concorrenza, e credetemi, sono un sacco di tempo nel mondo del software.

Vi state mettendo nella posizione estremamente pericolosa di distribuire una vecchia versione del codice per qualche anno, completamente incapaci di portare cambiamenti strategici o di reagire alle nuove richieste del mercato, perché il vostro codice nuovo non è pronto. Perché non chiudete baracca per tutto il tempo che ci vorrà, visto che ci siete ?

State buttanto una quantità di soldi che non sta nè in cielo nè in terra per riscrivere del codice che già c'è.

C'è un alternativa ? L'opinione generale è che il vecchio codice di Netscape fosse veramente orribile. Beh, può anche essere stato orribile, però la sapete una cosa ? Funzionava maledettamente bene su un gran mucchio di computer, là fuori nel mondo reale.

Quando i programmatori dicono che il loro codice è un gran casino, come fanno sempre, ci sono tre generi di cose sbagliate in quel codice.

Per primi ci sono problemi che riguardano l'architettura. Il codice non è fattorizzato correttamente. Il modulo per l'accesso in rete mostra dei dialog-box che spuntano dal nulla e avrebbero dovuto essere gestiti dal codice che si occupa dell'interfaccia utente. Sono problemi che si possono risolvere, uno alla volta, spostando con attenzione sezioni di codice, ri-fattorizzando, modificando interfacce. Un programmatore da solo, che lavori con attenzione può farlo e registrare tutte le modifiche in una volta sola, così che nessuno venga danneggiato. Modifiche architetturali abbastanza estese possono essere apportate senza buttar via il codice. Sul progetto Juno a un certo punto abbiamo impiegato dei mesi rifattorizzando il codice: spostando blocchi, ripulendo qua e là, creando delle classi base che avessero senso e definendo delle interfacce ben delimitate tra i moduli. Ma l'abbiamo fatto con attenzione, con il vecchio codice e senza creare nuovi bug o buttar via codice funzionante.

Il secondo motivo per cui i programmatori pensano che il proprio codice faccia schifo è perché è inefficiente. Si dice che il codice per la visualizzazione di Netscape fosse lento. Ma questo riguarda solo una piccola parte del progetto, che puo' essere ottimizzata o anche riscritta. Non serve riscrivere tutto. Se ottimizzate per la velocità l'1% dello sforzo vi fà guadagnare il 99% del risultato.

Terzo, il codice può essere veramente orribile. Un progetto su cui ho lavorato aveva un tipo di dati "FuckedString" ("StringaFottuta"). Un altro era partito con la convenzione di chiamare tutte le variabili membro con il prefisso "_" per poi passare al più comune "m_". Così metà delle funzioni cominciavano con "_" e metà con "m_", orribile a vedersi. Francamente questo è il genere di problemi che si risolvono in cinque minuti con una macro in Emacs, non riscrivendo tutto.

È importante ricordarsi che quando cominciate da capo non c'è nessun motivo di credere che questa volta farete un lavoro migliore della prima volta. Prima di tutto probabilmente non avrete neanche lo stesso team di programmatori che ha scritto la versione uno, quindi non avrete "più esperienza". Non farete che ripetere molti degli stessi errori, e aggiungerne di nuovi che nella prima versione non c'erano.

Il vecchio mantra fanne uno da buttare via è pericoloso quando lo applicate a software commerciali su larga scala. Se scrivete codice come esperimento potete anche buttare la funzione che avete scritto la settimana scorsa quando vi viene in mente un algoritmo migliore. Va benissimo. Potere rifattorizzare una classe per renderla più facile da usare. Va bene anche questo. Ma buttare tutto è una follia pericolosa, e se Netscape avesse avuto qualche supervisore adulto con un po' di esperienza nell'industria del software avrebbe potuto evitare di darsi la zappa sui piedi così malamente.



Traduzione dell'articolo originale inglese dal titolo Things You Should Never Do  

Joel Spolsky è il fondatore della Fog Creek Software, una piccola ditta di software a New York. Laureato alla Università di Yale, ha lavorato come programmatore e manager presso Microsoft, Viacom e Juno.


I contenuti di queste pagine esprimono opinioni personali dell'autore.
I contenuti sono Copyright  ©1999-2005 di Joel Spolsky. Tutti i diritti riservati.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky