Come rendere inusabile il proprio codice (o quasi)
Mercoledì 24 Febbraio 2010 - 07:47
di Gabriele Romanato
Se c’è una cosa che non sopporto degli sviluppatori è che spesso, quando scrivono anche la più piccola libreria JavaScript, ci si mettono d’impegno per farti buttare almeno un’ora di tempo per capire come usarla. Se leggete i commenti degli utenti alla libreria SyntaxHighlighter, noterete il ricorrere di parole come ‘doesn’t work’ e ‘can’t make it work’ (in italiano: non funziona, non so come farla funzionare). Questo è solo uno dei tanti casi in cui sarebbe bastato aggiungere dei file di esempio nel download per facilitare il lavoro degli sviluppatori che andranno ad usare la libreria, esattamente come succede per i plugin di jQuery (sia benedetta la community di jQuery!).
Per rendere inusabile il proprio codice basta poco: non serve offuscamento e compressione, basta semplicemente dire: “Il codice scritto da me lo capisco. Quindi anche gli altri lo capiranno (povero Cartesio!)”. Tutto qui. Se vogliamo proprio andare sul sicuro e far imbestialire gli utenti, aggiungete anche una scarsa documentazione e la mancanza di esempi. E non dimenticate, nella versione non compressa, di non aggiugere alcuna nota esplicativa nei commenti, ma limitatevi semplicemente a qualche sporadico commento generico qua e là.
Risultato? Da un punto di vista dello sviluppo, sicuramente un ottimo risultato (sarei un pazzo arrogante se affermassi il contrario), ma da un punto di vista della condivisione e dell’usabilità un gigantesco autogol. Einstein diceva che se si è capito qualcosa bisogna essere in grado di spiegarlo anche alla propria nonna. Questo il segreto dell’usabilità del codice.
Categoria: Scripting | Permalink
Commenti
1
Penso che jQuery che ha una vasta comunità e una serie impressionante di plugins dovrebbe “certificarli”. Almeno controllarli e dire se sono “accettabili” come uso.
Ne ho visti alcuni che mi sarebbero stati utili ma poi inusabili, non modificabili, non funzionanti, ciofeche vere e proprie!
2
Concordo con Senamion, e poi, anche se siamo tutti “buoni”, documentare bene il codice costa tanto tempo e per una generica libreria gratuita di non tante pretese non saprei se ne vale la pena
# - postato da Daniele - 24 Febbraio 2010 - 10:51
3
chiunque (sia in grado) oggi si alza e fa la sua libreria. Un bene per l’umanità. Peccato che poi l’umanità non voglia così bene al suo autore.
E il discorso ovviamente vale anche per tutti gli altri linguaggi !
# - postato da PiccoloSocrate - 24 Febbraio 2010 - 10:52
4
Io sono dell’idea che mettersi a commentare cose tipo “non riesco ad usarlo” “non capisco come funziona” etc sia inutile.
Se un “oggetto” ha della documentazione mal fatta e mi fa perdere tempo (sempre più prezioso) per cercare di farlo funzionare, fine, chiuso, morto, passo ad altro. Non perdo tempo a lamentarmi, se la documentazione è scadente probabilmente anche il prodotto lo è.
5
lordmax ma cosa stai dicendo? Guarda che si perde un sacco di tmepo a fare la documentazione, ringrazia che ti hanno rilasciato lo script al posto di dire:” se la documentazione è scadente probabilmente anche il prodotto lo è” ma non ha senso, non tutti hanno il tempo necessario per fare una bella documentazione. Sopratutto se non hai un team di sviluppo. Ma d’altronde è facile parlare e spalare merda a chi si sbatte per altri, per fortuna non tutti sono come te e se la documentazione è mal fatta o poco curata cercano di aiutarti, invece tu vuoi solo la pappa pronta.
Odio sto genere di persone, mi fa imbestialire e fosse per lui non rilascerei mai niente sotto GPL… ad uno come lui gli farei pagare ogni decimo di secondo del mio tempo.
6
Il senso del post era: documentare facilita l’uso di una libreria. Nello specifico, per la libreria SyntaxHighlighter sarebbero bastate tre (dico tre!) righe di esempio nei commenti del file shCore.js. ricordo che non tutti quelli che useranno il nostro codice possono essere in grado di capire come funziona dopo averlo scaricato. i plugin di jQuery che uso hanno tutti file di esempio o un readme.
è una questione di usabilità. solo usabilità, nient’altro che usabilità, nessuna critica al codice. solo usabilità del codice e più in generale rapporto con gli utenti finali, sia che si tratti di clienti, utenti, utonti, niubbi, maghi del codice e maestri Jedi della programmazione: non fa differenza. si tratta di disponibilità, di cortesia, di premura verso chi userà il nostro codice. non è nemmeno questione di “leggi il f….o manuale!”, perchè in questo caso non c’è! :-)
è solo dire: “faccio questo per facilitarti la vita, non voglio farti perdere tempo”.Tutto qui. ciao :-)
# - postato da Gabriele Romanato - 24 Febbraio 2010 - 13:35
7
PErfettamente d’accordo con Lordmax. Io credo che la documentazione sia fondamentale. Questo vale per gli script, per le librerie e vale anche per i cms. A volte tra due ottimi prodotti la differenza la fa proprio la documentazione.
# - postato da cristina - 24 Febbraio 2010 - 14:26
8
Quanto ti capisco: stavo cercando un altro plugin per WordPress per evidenziare la sintassi e mi sto accorgendo che molti non funzionano come dovrebbero. E mettere mano al codice sembra più difficile rispetto a scrivere un plugin da zero!
9
@DevAlien
Vedi di stare calmino per favore che prima di parlare oltre a pulirti la bocca dovresti sapere di cosa parli.
E francamente, se non vuoi più rilasciare nulla sai che mi frega.
Se invece vuoi giocare a chi l’ha più lungo dimmi su quanti progetti ai lavorato e quante pagine di documentazione hai rilasciato (ben scritta e con esempi ovviamente) poi ti dico quante te ne mancano per arrivarmi vicino.
10
Io a volte vedo pubblicizzati plugin molto interessanti, ma quando vado ad implementarli (sempre in un ambiente di prova) mi sento ritardato: la documentazione non la capisco, lo script non funziona, il codice non saprei da dove partire, ecc.
Questo post mi rincuora e non posso non quotare lordmax.
# - postato da Dario - 24 Febbraio 2010 - 17:09