Sviluppo nel mondo MS (aprile 2017)

Disclaimer: non ho idea di cosa sto parlando, sono in una fase di brainstorming e potrei dire le più alte stupidaggini.

Quindi se io volessi sviluppare un’app partendo da foglio bianco nel 2017 restando nell’ecosistema degli strumenti Microsoft posso scegliere tra:

  • .NET Framework 4.6(.2): il famosissimo Framework standard e completissimo che tutti conosciamo per applicazioni e web sistema operativo Windows centriche;
  • .NET Core: evoluzione del .NET Framework (che non ho capito se si fermerà alla versione 4.6.2). Ridisegnato, open-source, per applicazioni server/console (?) multi-piatta (Windows, macOS, Linux) (ASP.NET Core). Non ci sono GUI multi-piattaforma (WPF, tipo).
  • Xamarin per applicazioni mobile multi-piattaforma.
  • UWP: Parte del .NET Core per sviluppare app che attraversano tutte le varianti del SO Windows 10 (da Enterprise a IoT, Mobile e Xbox One compresi).

Mettiamola graficamente (grazie blog Microsoft)

Immagine

La cosa incredibile è che con Visual Studio e C# si possono attraversare tutte queste tecnologie. Fantastico.

Senza menzionare tencologie/integrazioni con motori grafici quali Unity (con cui fare giochi, applicazioni VR/AR) e potenza del cloud (Azure che è un mondo vastissimo solo quello).

Advertisements

Pollice verde

Per me il software è come una pianta.

Una delle metafore più diffuse per descrivere ai non addetti ai lavori come avviene la costruzione di un software e la sua complessità è quella di paragonarla alla costruzione di una casa. È una metafora che regge, niente di sbagliato. Tuttavia è limitata perché a un certo punto la casa finisce e diventa “rigida”. Non è più così modificabile, non è più possibile fare determinate aggiunte o togliere pezzi.

Proprio per evitare questa sensazione di rigidità io preferisco la metafora della pianta. L’inizio dello sviluppo è come piantare il seme. Poi arriva un minimo di arbusto ma perché si regga dritto è necessario aiutarlo con un bastone di sostegno. Poi si comincia ad avere un certa solidità, con un tronco e i primi rami più importanti. Il processo avviene con calma, con cura, dobbiamo amare la nostra piantina e sfoggiare le nostri doti migliori da pollice verde. Poi è un’esplosione di rami, foglie, che possono sempre crescere in ogni direzione e in ogni momento. Ma attenzione. Alcuni rami si possono ammalare, altri vanno potati. La pianta va continuamente curata, sfrondando dove c’è bisogno.

Per questo il software è come un albero. È un qualcosa che continua a mutare e il buon team di sviluppo ne conosce pregi e difetti. Sa quali sono le parti da potare e lo fa senza indugi. Sa quali sono le parti che si reggono su un sostegno e le fa crescere per renderle più robuste.

E voi? Che paragone usate per spiegare come si costruisce e mantiene un software?

Una promessa in incognito

Valutare approssimativamente il valore numerico di una grandezza. – Treccani.it, Vocabolario online.

Quando qualcuno ci chiede una stima riguardo a quanto ci vuole per sviluppare, ci sembra che ci stia chiedendo un’indicazione approssimativa delle ore uomo? Abbiamo l’impressione che la risposta che diamo possa essere approssimativa? Che possiamo poi cambiare idea e rifinire la nostra risposta?

incognito-modalità

Probabilmente no. Aggiungerei poi che tale risposta potrebbe esploderci in mano quando lo sviluppo non avviene entro i tempi stimati. Perché? Perché quando un manager solitamente chiede una “stima” sta in realtà chiedendo un impegno o un piano per raggiungere un obiettivo. La distinzione tra stima, obiettivi e impegni è fondamentale per capire cosa è una stima, cosa non è, e come rendere migliori le prossime che faremo.

La stima è, rigorosamente, quello che dice il vocabolario. Un obiettivo è una frase che indica un obiettivo di business che si vuole raggiungere (es.: questa funzione deve essere completata entro il primo giugno perché la mostreremo in una fiera). Un impegno è una promessa di rilasciare determinate funzionalità con uno specifico livello di qualità entro una certa data. Una stima può essere lo stesso di un impegno, può essere più aggressiva o più conservativa. Non diamo per scontato che l’impegno debba essere uguale alla stima.

Molti dirigenti/manager non hanno il bagaglio tecnico per distinguere tra stima, obiettivo e impegno. Diventa perciò dovere del responsabile tecnico di tradurre la richiesta del dirigente in termini più specifici.

Gold-plating

Qualche settimana fa non conoscevo questo termine.

Avete presente quel momento in cui si sta sviluppando qualcosa e il pensiero comincia a prendere la tangente: “Ma se succedesse anche questo allora c’è bisogno di quest’altro. A questo punto all’ora potrei implementare questa funzione!”. Oppure: “Aggiungiamo anche questa funzione perché magari può succedere che…”. Quando sentiamo queste frasi dette da qualcun altro o che girano per la nostra testa dovremmo immediatamente tirare il freno a mano. Quello che sta succedendo è, molto probabilmente, gold-plating. Stiamo facendo più del richiesto.

Quando sviluppiamo un software che sia su commessa o che sia per essere proposto nel mercato, dovremmo fare ogni sforzo possibile per implementare solo ed esclusivamente quelle funzioni che sono state analizzate e confermate in fasi precedenti allo sviluppo. Se stiamo affrontando un esercizio accademico, o per studio, allora ci può stare ma non esistono altre eccezioni.

I motivi?

  • Potremmo sviluppare qualcosa di non gradito;
  • Potremmo addentrarci nello sviluppo di qualcosa che, involontariamente, peggiora la situazione del progetto perché più complessa del previsto;
  • Si compromette la buona riuscita del progetto perché si sta dedicando tempo a qualcosa che  non era stato inserito nella pianificazione;
  • Potremmo scatenare effetti collaterali in altre parti del software a cui non abbiamo pensato;
  • Aumentano i costi;
  • Il committente non sta pagando per quelle righe di codice.

Il concetto del gold-plating non si applica solo a livello di progetto ma a tutti gli strati di una progettazione software:

  • Se stiamo sviluppando una classe potremmo inserire funzioni non strettamente di sua competenza;
  • In una interfaccia utente potremmo mettere troppe funzioni che ne complicano l’utilizzo;
  • In una tabella di un db potremmo mettere colonne che causano ridondanze che devono essere mantenute per niente.
  • Un metodo di una classe potrebbe voler fare troppe cose e diventare un monolite.

Come programmatori dovremmo sempre essere sull’attenti quando stiamo implementando qualcosa: meno scriviamo e meno danni facciamo, meno danni facciamo e più è alta la probabilità di fare qualcosa che funziona.