Le malattie professionali del programmatore :: 03 Il Morbo di Magnet

Il Morbo di Magnet è la terza malattia che affrontiamo.

Un po' di storia

I primi casi sono stati segnalati nel libro Clean Code: A Handbook of Agile Software Craftsmanship.

Sintomi

Il morbo trova le radici dai buoni propositi del programmatore:

evitare che ci siano difficoltà nel reperire nozioni importanti (sia di dominio che tecnologiche) riguardanti il software che si sta scrivendo





Per questo motivo spesso ne sono affetti bravi programmatori, technical leader o ex project manager.

Si manifesta con tentativi eccessivi di accentrare le informazioni in un unico punto senza che ci si renda conto che per ottenere quel obbiettivo si richiedono delle azioni specifiche e superflue quali ad es. l'indicizzazione delle informazioni in un unico oggetto/file/etc...

Faccio un esempio che mi è capitato proprio l'anno scorso... Scenario: applicazione REST. Se c'è un'anomalia deve esser fatto sapere al client in modo da consentirgli di mostrare un messaggio ben preciso.

Immaginiamo di avere un'anomalia denominata HoBevutoTroppoException. Posso far sapere al client dell'accaduto, creando una reponse JSON con un attributo che abbia come valore il nome dell'eccezione. Ad es.

{ "error": "HoBevutoTroppoException",
  "barili": 5,
  "tempi_di_recupero": "infinite" }

In questo modo, durante la costruzione di una nuova feature, potrei lanciare una VomitoException e non ci sarebbe niente da fare se non creare l'eccezione stessa.

Il malato di Morbo di Magnet invece non riesce a "leggere" questa flessibilità nella soluzione indicata sopra. Deve aver una classe o un file (se dice che vuole un XML è gravissimo) dove censire l'exception e assegnarli cosa?!?!?!?!? ATTENZIONEEEE:

     
 un ERROR COOOOOOOODE!!!






EVVIVAAAAAAAAA, ma sì... perchè un numero, in fondo, vale più di mille parole!!! vuoi mettere la chiarezza di un errore 21784, eh???? Pensate ora all'imbarazzo del programmatore che, dovendo creare una nuova exception, non solo deve darle un nome appropriato, ma anche un numero ed andarlo a censire in quel posto là (... aspetta dove c@##o era quel file?). Per non parlare del numero che deve essere univoco e lì via alla fantasia...

"usiamo i range di valori!: da 0 a 200 per le bevute, da 201 a 500 per il dolori al pistolino"







ma daiiiii...
Ah e poi pensate che bello: se dovete creare una nuova exception e vi dimenticate di censire l'error code accadono due cose:

1. non va una mazza
2. vi beccate una romanzina "eh cavolo, ma l'architettura era chiara" 

ma certo, era chiaramente una M... ehm... una Meraviglia nella tua testa, ma noi poveri programmatori con una flebile memoria abbiamo la necessità di aver pochissime cose da ricordare. Quindi questa burocrazia per sviluppare un software sarebbe la prima cosa da evitare.



I medesimi sintomi si possono presentare anche sulla parte di configuration. Tipo EJB che non vanno se non li censisci in un server.services... mah... se ho creato degli EJB spero proprio di averlo fatto perchè servivano ;-) devo anche censirli?!?

Cure

Se si tratta di un technical leader o di un ex project manager, provate con:

 

"queste attività da scimmia o le fai tu o CITA (che è un modo alternativo di dire a ssòreta)"






col tempo, facendo costantemente queste operazioncine di M... ehm... di Molteplice utilita' (nella sua testa), potrebbe rendersi conto della noia a cui sono stati sottoposti i suoi colleghi e cominciare a valutare soluzioni alternative.

Se si tratta di un programmatore, via di modifica senza ascoltarlo!!! :-D

Le malattie professionali del programmatore :: 02 La Sindrome di Setter

Continuiamo la serie di post sulle malattie professionali del programmatore.
Parliamo della Sindrome di Setter.

Un po' di storia

Casi di questa sindrome sono segnalati fin da tempi remoti.

Sintomi

La Sindrome di Setter è come un "raffreddore". Ogni tanto lo prendi.
E' facile: hai un database, 4-5 tabelle, inciampi su una business logic semplice (oggi) o "fatta semplice" e...

PRESAAAAAAA!!!

Gli oggetti diventano la traduzione 1-1 dei record di una tabella. Puoi cambiare ogni campo come vuoi. Si accompagna di solito con la Managerite, perchè appena la business logic si complica, quell'oggetto (ma perchè non chiamarlo RECORD?) non vorrai mica che "contenga della business logic"... EH NO! Allora nascono gli oggetti con nome <oggetto>Manager (ah e ovviamente stateless mi raccomando eh!).
Da questo momento in poi: degrado esponenziale del dominio e diminuzione drastica della possibilità di comprendere in futuro:
    "perchè cappero avevamo fatto questa applicazione?!?"
    "BOH!"
    "meglio rifarla da capo..."
    "EH?!?"
Scusate, ma se non si è riusciti a scrivere un'applicazione leggibile, come si puo' pensare che la cosa non si ripeterà in futuro?

Cure

La cura si chiama refactoring, ma è un'arte che non si puo' spiegare in un post.
Sono invece interessanti le manovre preventive che non coinvolgono solo noi programmatori, ma anche altri soggetti coinvolti nei progetti.
Ne suggeriamo alcune:

• alle parole: "guarda è una cavolata... abbiamo già anche il data model" è richiesto alcoltellamento dell'individuo
• se alla domanda: "ma cosa deve fare questa applicazione?", la risposta che vi vien data è "mah... c'è un DB, 4 oggettini, un frontend... dici di usare Hibernate o JDBC?" è necessario tapparsi le orecchie e urlare a squarciagola BLAH BLAH BLAH (come nella foto, ma mi raccomando... la lingua di fuori!)
• se è farina del vostro sacco dipende dalla vostra preparazione:
• se siete Juñor: non preoccupatevi... altamente suggerita la lettura del libro Domain-Driven Design: Tackling Complexity in the Heart of Software, perchè con i suoi ubiquitous language e building blocks si riesce a non cadere in questa trappola. Fatevi aiutare a sistemare la situazione da qualcuno con un po' più di esperienza... ma non nel (suo) periodo influenzale
• se siete Señor: refactoring immediato ora e subito. Non c'è tempo da perdere. La frittata è stata fatta... ok, capita, ma è il momento di risolverla e devi farlo tu anche a costo di far straordinari!

Ora scusatemi, ma... ehm... ho del lavoro arretrato e devo fare gli straordinari;)

JSLint: String.replace senza problemi

Ultimamente mi sono trovato nella situazione di dover effettuare il replace di alcuni caratteri in una String.
Il codice più o meno era questo:


    User.prototype.escapedLogin = function () {
        'use strict';

        return this.login.replace(/\\/, '\$');
    };


Il test funzionava perfettamente:


    it("is able to escape login", function() {
        var user = new User("XXX\\r.simoni");
        expect(user.escapedLogin()).toBe("XXX$r.simoni");
    });


ma JSLint mi segnalava:

    Unexpected '\$'

La documentazione di JSLint aiuta tantissimo in questi casi, infatti con la frase:


"Regular expressions are written in a terse and cryptic notation. JSLint looks for problems that may cause portability problems. It also attempts to resolve visual ambiguities by recommending explicit escapement.
JavaScript's syntax for regular expression literals overloads the / character. To avoid ambiguity, JSLint expects that the character preceding a regular expression literal is a ( or = or : or , character."



ho anche capito, perchè c'è la fame nel mondo e le stagioni di oggi non sono più quelle di una volta.
Alla fine, dopo estenuanti ricerche sulla rete (... ed infiniti minuti passati davanti alla macchinetta del caffè), ho scoperto che bastava usare:

    ...
    return this.login.replace(/\\/, "$");


Quindi non si deve far l'escape del simbolo $.
Ho provato però ad usare '$', ma continuava a dare errore?!?

... ma che bello JSLint!!!