Scusi, mi rifà il programma?

Questo post è basato su fatti realmente accaduti.

E’ successo. E’ ricapitato. Per l’ennesima volta, è riaccaduta la stessa cosa.

Un potenziale cliente vi contatta, vi incontrate, chiaccherate per la prima volta su quello che dovrà fare il meraviglioso software che ha in testa. E per l’ennesima volta devi ricostruire, riprogettare da zero, un software già esistente, scritto lustri prima in MFC, o in Visual Basic 4.0, o in Access 97 o addirittura 2.0. E chiamano te per riconvertirlo e riprogettarlo in .NET, magari perchè si sono accorti che non sono più competitivi sul mercato, perchè il codice è diventato ingestibile, perchè vogliono avere l’app sotto iOS o Android, o per mille altri motivi. Non c’è documentazione, c’è solo un gruppetto di persone che sanno perfettamente cosa deve fare il software, ma non c’è nulla di scritto e di formalizzato. Non c’è nulla di male in tutto questo, d’altronde lavoro è lavoro.

Tu, con il tuo bravo e fidato Visual Studio, vorresti cominciare lo sviluppo di questo software magari con DDD, scrivendo le classi e pensando accuratamente il dominio applicativo, quindi – per farla breve – approcciando ad una metodologia code-first. Prima le classi, in seguito la logica, poi penserai al modello di persistenza. Ma il tuo cliente ragiona diversamente; come accadeva decenni fa (quando il suo software è stato scritto la prima volta) ragiona partendo dal database. Per lui è essenziale vedere lo schema del database, per capire se stai scrivendo la cosa giusta. Prima di vedere anche una sola linea di codice C#, vuole vedere le tabelle, le relazioni, i campi ed i nomi dei campi come piacciono a lui.

Di fronte ad una situazione di questo tipo, ci sono tante strade. Ne cito due.

1. Tu ragioni sempre e comunque code-first. Scrivi le classi e lasci che sia l’ORM (Entity Framework?) a generarti tutto il mondo della persistenza relazionale. Ma siccome per il cliente lo schema del database è fondamentale – dal quale dipende il Supremo Destino della nostra Galassia – allora cominci a litigare con attributi o con vagonate di codice, per educare l’ORM a generarti lo schema del db esattamente come lo vuole il cliente
2. Ti arrendi all’evidenza e cominci a progettare il database. Quindi segui il modello database-first. Fattibile, no? Al massimo, parlando di Entity Framework, una volta creato il database puoi farti comunque generare le classi tramite l’approccio “Code First from database”. Così al massimo puoi attivarti le migration…

Il discorso, a mio avviso è semplice. Se vuoi portare a casa la pagnotta, al cliente devi comunque dare retta. Se il tuo committente, magari perchè è stato educato male, ragiona partendo dal database, purtroppo non puoi farci nulla. Io poi parto da un semplice presupposto: se hai chiamato me, non vuoi semplicemente uno che digita o scrive codice, ma vuoi uno che ci metta la testa. Però non sempre si ha questa possibilità, per diversi motivi.

Detto questo, il primo approccio è code-first solo in apparenza. Tecnicamente cominci scrivendo un sacco di classi, ma in realtà nella tua testa sei costantemente traviato da ciò che dovrai ottenere come struttura sul database. E’ solo un palliativo, insomma. Scrivi una classe, e poi via…tonnellate di codice nel metodo OnModelCreating di Entity Framework per piegare ai tuoi voleri l’ORM. Burp, equivalente al ruttino.

Il secondo approccio è a tutti gli effetti database-first. E se il cliente ragiona in questo modo, che male c’è? Siamo pagati per scrivere un software o per fare gli accademici? Quindi, che male c’è ad aprire il Microsoft SQL Server Management Studio, stendere tutte le tabelle, campi, relazioni, e poi importarle via Entity Framework? In questo modo il cliente è soddisfatto, io ho le mie classi su cui poi cominciare a sviluppare. Se il progetto è di una certa importanza e/o durata, ci sarà magari tutto il tempo per guadagnare stima e fiducia verso il cliente, e ci saranno tutte le occasioni per indirizzarlo verso strade e percorsi più moderni allo sviluppo del software.