Debito Tecnico #4: Risolverlo alla sorgente

by Andrea Maioli on 5 febbraio 2013

Nelle settimane precedenti abbiamo visto che sviluppare software genera necessariamente un Debito Tecnico che deve essere ripagato con gli interessi. Per non farsi schiacciare da questo debito è necessario stimarlo fin dall’origine e pianificarne il “piano di rientro”.

Ma questa non è una soluzione, è un modo per tamponare il problema. I 1000 miliardi di dollari di debito tecnico stimati da Gartner dovranno comunque essere ripagati. Ecco perché la Programmazione Relazionale di Instant Developer assume un’importanza così rilevante nella creazione di sistemi software.

La Programmazione Relazionale è una tecnica innovativa di generazione del codice grazie alla quale l’IDE di Instant Developer memorizza l’intero progetto software e l’intera codebase in un grafo di relazioni e dipendenze invece che in tanti file di testo. In questo modo tutti gli elementi del software rimangono collegati gli uni agli altri e ogni modifica fatta in un punto determina l’adattamento automatico di tutto il resto del sistema.

Ma come fa la Programmazione Relazionale a ridurre il Debito Tecnico? Riprendiamo la lista delle sue cause vista due settimane fa e vediamo cosa cambia quando si usa Instant Developer.

  1. Debito creato da mancanza di analisi. Spesso l’analisi non è completa perché non è possibile fare lavorare gli utenti su esempi concreti. Con Instant Developer è tutto più facile perché creare prototipi è quasi istantaneo e in questo modo si possono osservare i processi direttamente tramite esempi.
  2. Debito creato da mancanza di best practice. Il Visual Code è indipendente dalle tecnologie e dagli ambienti operativi. Sono i compilatori interni di Instant Developer a generare codice sorgente conforme alle best practice dei produttori di tecnologia.
  3. Debito da mancanza di integrazione con la codebase esistente. È qui che la Programmazione Relazionale dà il suo meglio! Ogni modifica fatta in un punto del progetto software determina una reingegnerizzazione automatica ed immediata di tutto il resto del sistema informativo.
  4. Debito da mancanza di suite di test. La Programmazione Relazionale garantisce che tutto il codice rimanga coerente, quindi elimina la necessità degli unit test. Inoltre, grazie al modulo di tracing di Instant Developer, si possono utilizzare le sessioni utente come sessioni di test funzionale, diminuendo così anche il debito che si crea non eseguendo o rimandando queste ultime.
  5. Debito da mancanza di documentazione tecnica. L’IDE di Instant Developer contiene strumenti di analisi del codice e delle dipendenze sia statici che dinamici che consentono di operare modifiche tenendo conto del codice esistente senza dover perdere tempo a scrivere e leggere lunghi documenti tecnici.

Questi non sono risultati teorici, ma è ciò che risulta dalle esperienze pratiche di chi usa Instant Developer, soprattutto da chi sviluppa codice di classe Enterprise.

Volete sviluppare senza indebitarvi? Approfondite come funziona la programmazione relazionale scaricando questo white-paper gratuito, oppure cominciate subito scaricando la versione Express di Instant Developer.

In questa serie:

{ 4 comments… read them below or add one }

1 Mauro Marini 6 febbraio 2013 alle 23:24

Indubbiamente la programmazione relazionale, con la sua rete di oggetti, introduce vantaggi significativi.
Resto sempre sorpreso di quello che accade quando l’assistenza di Progamma entra sul mio codice per scoprire i problemi che incontro. Va bene che sono bravi e abituati, ma il tempo che ci mettono a “navigare” e “capire” il mio ambito applicativo è incredibilmente breve. Non posso che attribuirlo al modo con cui il codice si presenta visivamente e si rende esplorabile.
Personalmente vengo da molti anni di sviluppo in Smalltalk che offre un ambiente totalmente riflessivo e simile in termini di relazioni, esplorazioni e reattività alle modifiche. Abbandonare ambienti che collaborano reattivamente con lo sviluppatore è un trauma e InDe è stata una scelta dettata anche dalla sensazione di regresso nell’uso di ambienti tradizionali di sviluppo..
Se questa è la leva marketing su cui Progamma punta per dare una identità distintiva ad InDe, ci sono tutti gli elementi per consolidare il posizionamento competitivo. Mi viene in mente quello che succede con gli smartphone nel passaggio da comandi vocali, che hanno tutto, a Siri che ha solo Apple. Nel primo caso si tratta banalmente di attivare a voce le funzioni già disponibili con i tasti. Siri, invece, ambisce a collaborare e interagire, conoscendo non solo le funzioni, ma anche i processi che l’utente potrebbe compiere. Progamma ha Sirri e quindi parte già avvantaggiata! :D
Ward Cunningham sosteneva che la vera ragione per cui Smalltalk è morto , è che era talmente potente che era troppo facile incasinare tutto. Ci voleva troppa disciplina. In un certo senso, questo è anche il rischio della Programmazione Relazionale.
Ad esempio, cancellando una variabile, l’ambiente mi “fa la cortesia” di toglierla dovunque in modo che non ci siano riferimenti errati, ma potrei anche non rendermi conto che perdo degli statement rilevanti e mi spariscono pezzi di logica. La disciplina prevede che io prima controlli chi usava quella variabile e lo strumento a disposizione è impeccabile, ma …non sempre uno è disciplinato.
Prima che Smalltalk andasse in pensione, il trend evolutivo era orientato verso potenti strumenti di rifattorizzazione del codice, aggiungendo analisi semantica alla manipolazione della rete relazionale tra oggetti eseguibili. L’obiettivo era supportare adattamenti del codice sempre più veloci e “protetti” (vedi extreme programming). Questo è un obiettivo, in parte già raggiunto con InDe, ma con un bel potenziale ancora da sfruttare.
Se posso permettermi di suggerire un consiglio, punterei sull’apprendimento e sviluppo esplorativo che vedo già nei vostri obiettivi quando osservo i collegamenti tra ambiente, documentazione, esempi “vivi” e esempi in codice. Penso a come aiutare chi si avvicina ad In.De ad usare l’ambiente in modo riflessivo e potenziare gli strumenti di supporto alla rifattorizzazione.
Sarebbe interessante aprire un thread sul forum chiedendo “quali sono le tre cose che vi hanno permesso maggiormente di contenere il debito tecnico”.

2 Riccardo Bianco 7 febbraio 2013 alle 08:39

“[...] era talmente potente che era troppo facile incasinare tutto”

Alcune volte mi sono trovato a fare la stessa considerazione, devo ammettere molto poche comunque. Forse, semplicemente, individuerei i punti in cui l’automatismo crea potenzialmente più danni e avvertirei il programmatore in caso l’automatismo scatti, chiedendo conferma. L’esempio in cui mi sono imbattuto qualche volta è il cambio di tipo di variabile (intero/float) eseguito come conseguenza di un’altra mia azione: prima di trovare l’errore ho impegato parecchio tempo.

3 Andrea Maioli 7 febbraio 2013 alle 09:09

Grazie dei contributi, come sempre spunto di riflessione su come migliorare.

4 Riccardo Bianco 7 febbraio 2013 alle 15:43

Ad onor del vero, il tempo risparmiato grazie alle relazioni tra gli oggetti e gli automatismi derivanti, supera di gran lunga il tempo perso nei pochi casi in cui questo mi ha creato problemi.

Leave a Comment

Previous post:

Next post: