[Bad Coding/Designing Practices]: “Forzare” l’utilizzo di uno strumento software non rispettandone la “filosofia funzionale”

Bad Coding/Designing Practices, Ingegneria del Software 0 107

Subject
Software configuration/customization

Bad Practice
“Forzare” l’utilizzo di uno strumento software non rispettandone la “filosofia funzionale”

Explanation
Quando si decide di ricorrere ad uno strumento software per costruire una propria “soluzione” software, e non si utilizzano “correttamente” le funzioni, i costrutti o non si seguono le “best practice”, cercando anche di implementare comportamenti che non rientrano nella specificità dello strumento stesso. A volte, non si dedica il giusto tempo e la giusta attenzione alla conoscenza dello strumento.

Problem
Non rispettando i vincoli base e non seguendo le “best practice” dettate dallo strumento, oppure facendo abuso di personalizzazioni ed estensioni ad alta complessità, si può rischiare di perdere il controllo della “soluzione”. In alcuni casi può diventare particolarmente complesso il passaggio a release successive dello strumento stesso.
A volte, l’ignoranza sullo strumento può essere la causa dei problemi appena descritti.

Fix
Valutare e scegliere opportunamente lo strumento software che supporti il maggior numero di requisiti richiesti nel contesto funzionale specifico. Una volta scelto lo strumento, cercare di rispettarne i vincoli e seguire le “best practice” in modo da ottenere il massimo vantaggio competitivo dallo stesso (riduzione dei costi, aumento della produttività, maggiore affidabilità, time to market ridotto, qualità della soluzione, etc.).
Se ci si dovesse rendere conto che alcune “forzature” sullo strumento software sono causate da uno o più requisiti utente, non escludere la possibilità di una revesione parziale degli stessi (ove applicabile).
Aumentare quanto più possibile la conoscenza dello strumento e non accontentarsi di una conoscenza superficiale.

Note
L’attività di personalizzazione dello strumento software viene tipicamente svolta attraverso l’uso di linguaggi dichiarativi (linguaggi standard oppure specifici per lo strumento stesso, ad esempio un particolare “dialetto XML”), imperativi (script, procedure) e object oriented. L’utilizzo di uno o dell’altro approccio, o della loro combinazione, può essere influenzato dal “livello” dello strumento software stesso, che può essere di “alto livello” (ad esempio un applicativo di “WorkForce Management”, o di “Customer Relationship Management”, oppure di “Content Management”, etc.) oppure di “medio-basso livello” (ad esempio le piattaforme Java EE e .NET, un software di ETL, oppure le librerie e i framework, etc.). La personalizzazione può consistere in un’attività di “configurazione” (più presente su strumenti di “alto livello”) oppure in una vera e propria attività di “programmazione” (più presente su strumenti di “medio-basso livello”).

Scope
Librerie, Framework, Middleware, Applicativi

About the author / 

Salvatore Di Loro

Related Posts

Leave a reply

Your email address will not be published. Required fields are marked *

Twitter @sdiloro

Instagram

Flickr