Le specifiche andrebbero rispettate

Ammiro chi scrive specifiche, perchè francamente è un lavoro palloso, spesso trascurato, che si deve fare con cura perchè è fondamentale nell'ottica di dare a chi non ha scritto quel pezzetto di codice la possibilità di capire l'autore cosa volesse fare nel suo momento di ispirazione creativa. Non è banale fare specifiche chiare, come non è banale fare software che funziona.

E l'uso di should o would, in casi come questi, non è un dettaglio stilistico o un esercizio per la bella forma, è indice di cosa quel pezzetto di bit deve fare.

Questo è un discorso generale, in realtà, che va bene anche per il web, ad esempio, perchè come sappiamo tra HTML, XHTML, CSS, box model, positiong e compagnia cantante, quasi nessuno dei browser può dire che effettivamente ha l'anima pulita e linda, nemmeno FireFox, tanto meno IE.

Bene, siccome in questo periodo mi capita spesso di utilizzare servizi o codice di terze parti, la prima cosa che faccio, giustamente, è andare a leggermi le specifiche. Bravo, direte voi. Giusto, dico io, seguirle alla lettera, aspettarsi che quello che c'è scritto nelle specifiche sia quello che il pezzetto di bit di cui sopra effettivamente dovrebbe fare.

Invece, e mi è capitato circa 5 minuti fa, credi di aver fatto tutto alla perfezione (che vuol dire, hai seguito le specifiche), e ti accorgi che purtroppo la risposta di un certo URL non è in plain text, come dice il tuo bel manuale, ma un bel <html><body>0</body></html>.

Fighissimo, aggiungo io. Perchè nell'era dei webservice, di WCF, di BizTalk, di Kaka', degli schermi piatti e delle chiamate a cui non rispondi che ti arrivano via mail, siamo ancora a dare risposte in siffatto modo ad una chiamata simil-REST. Potevo tollerare il plain text, non tollero questo aborto di HTML.

Tralascio il fatto che, ovviamente, se ometto un parametro, anzichè rispondermi con un errore che io possa gestire, mi spara (sempre in HTML...) l'errore di parsing del parametro.

La cosa che mi rende perplesso, più di tutte, a questo punto, è una: se il manuale l'ha scritto chi ha fatto il software, allora quella mattina non stava tanto bene con se stesso e con il mondo; se l'ha scritto qualcun'altro, deve odiare la persona che ha fatto il software. Altre spiegazioni razionali non mi vengono in mente, perchè nel manuale c'è scritto che se mi risponde con "0", allora è tutto OK, se mi risponde con "1", allora c'è qualche problema. A parte che 0 ed 1 dovrebbero significare falso e vero, e non il contrario, mi domando perchè le specifiche siano così lontane dalla realtà. Chiamare un desiderata specifiche è sbagliato.

Alla prossima puntata!

Nella stessa categoria

Commenti
m.alberti scrive:
Le specifiche andrebbero rispettate

Quoto e concordo con voi, la disperazione più totale arriva quando le specifiche non ci sono, sono inncomplete, solo descrittive e del tutto inutili...
Spesso chi fa analisi non he le idee chiare, chi sviluppa ancora meno e chi riutilizza si trova nella ....
29/02/2008 ore 9.02
naighes scrive:
Le specifiche andrebbero rispettate

Altre spiegazioni razionali non mi vengono in mente, perchè nel manuale c'è scritto che se mi risponde con "0", allora è tutto OK, se mi risponde con "1", allora c'è qualche problema. A parte che 0 ed 1 dovrebbero significare falso e vero, e non il contrario, mi domando perchè le specifiche siano così lontane dalla realtà.


No, guarda, quello che hai scritto, e che io ti ho quotato in grassetto, mi rende estremamente felice, perchè è capitato anche a me! (tra l'altro, abbastanza recentemente)
In quell'occasione ebbi le tue stesse perplessità ma, molto umilmente, presi per buono quello che era scritto all'interno delle specifiche, proseguendo con il lavoro.

C'è da dire, comunque, che la vicenda che hai descritto è abbastanza inusuale, nel senso che, fortunatamente, non mi è mai capitato di trovarmi di fronte quella roba, ma ne sono capitate di carine anche a me.
Ritorno quindi al caso che ho citato prima.
Il web service, stando alle specifiche, mi restituiva un oggetto "ReturnCode". Se la proprietà "CodiceDiErrore" (notare il nome della classe in inglese e quello della proprietà in italiano...) dell'oggetto in questione era valorizzata con "0", allora tutto ok! In caso contrario, all'interno della proprietà "Descrizione" avrei trovato la motivazione di questa risposta "inattesa".
Bene, dentro ci trovo tutto lo StackTrace, il quale mi segnala un'eccezione alla riga 4.905 del file blablabla.cs...
Ora, io devo assolutamente togliermi questa curiosità.
Qualcuno di voi ha mai scritto in vita sua un unico file sorgente di quelle dimensioni?
18/10/2007 ore 15.37

Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.

© 1998-2008 - ASP.NET, Media Center e tecnologia - Il blog di Daniele Bochicchio

TagCloud
.NET Framework, .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5, 10annidi, ADO.NET, AJAX, Architettura, ASP, ASP.NET, ASP.NET 2.0, ASP.NET 2.0 per tutti, ASP.NET 3.5, ASP.NET 3.5 per tutti, ASP.NET AJAX, ASP.NET MVC, ASPItalia.com, Cache, CSS, Custom Control, Database, Databinding, Datagrid, Deployment, HttpHandler, HttpModule, HttpRuntime, IIS, ISAPI, Javascript, LINQ, LINQ to SQL, LogParser, Master Pages, Media Center, Membership API, Microsoft Expression, Mono, MySQL, Object Oriented Programming, Off Topic, Office, Pattern, Profile API, Provider Model, Report, Roles API, Security, Silverlight, Silverlight 2.0, SQL Server, User Control, Visual Studio, Web Service, Windows CardSpace, Windows Client, Windows Live Services, Windows Mobile, Windows Presentation Foundation, Windows Server, Windows Vista, WinFS, XAML, XBox 360, XHTML, XML, XSLT
BLOG INFO
  • Post: 836
  • Commenti: 355
  • TrackBacks: 181
  • Feed blog e contenuti tecnici: RSS
  • Feed blog: RSS Atom OPML

MVP
CATEGORIE
I PIÙ LETTI DEL MESE
IN EVIDENZA