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