Siamo uno Studio di Ingegneria, e sviluppiamo il software con criteri e metodologie ingegneristici.
Il team si attiene ad un insieme di regole i cui obiettivi sono:

• l'alta qualità del software prodotto
• la facile comprensione delle soluzioni software implementate
• la manutenibilità (intesa come facilità di evoluzioni) del software
• la minimizzazione dei tempi di sviluppo

Abbiamo sviluppato pattern specifici di programmazione ed adottato soluzioni standard che tutti gli sviluppatori IdeaWeb devono conoscere ed utilizzare. Il pattern comprende sia una libreria che implementa le funzioni base, sia i principi con cui si personalizza il comportamento di una tabella.
Abbiamo definito degli standard e delle regole interne volte ad organizzare in modo preciso vari aspetti nello sviluppo software.

Esempi di PATTERN:

• Gestione delle tabelle dati. Il pattern comprende: paginazione, filtri, totali, eventi della tabella. Gli eventi della tabella stabiliscono le regole di sincronia con i dati, le chiamate Ajax ed i ricaricamenti
• Tabella elenco/dettaglio (pattern Master/Detail)
• Generazione PDF
• Menu e ruoli: come le pagine devono implementare un comportamento polimorfo in base al ruolo (campi/dati visibili, operazioni inibite, voci di menù abilitate/disabilitate)
• Dipendenze sulle chiamate Ajax in cascata
• Rappresentazione di un generico albero di informazioni a database (esempi: albero delle categorie prodotti, albero di struttura di un preventivo in capitoli > sezioni > paragrafi...). Il pattern implementa l'informazione di un albero in record in db relazionale indicando come si risolvono i problemi di performances collegati ad una ricerca sull'albero (ad esempio contare o elencare i prodotti sottostanti una categoria che non sia foglia).
• Su come si implementa una stampa PDF (header e footer, copertina, sommario)
• Su come si gestisce il dato in lingua sul DB e sulle pagine WEB
• Su come gestire i dati in Application Cache
• Su come scrivere su LOG e notificare gli errori
• Come si implementa una procedura che allinea dati da una fonte esterna (l'importazione di anagrafiche prodotti o anagrafiche clienti è cosa piuttosto semplice. Ma importare i documenti, i movimenti di magazzino da una altra struttura dati ha generalmente una sua complessità).

Esempi di SOLUZIONI STANDARD adottate:

• Autenticazione al sistema tramite Cookies criptato
• Sicurezza e permessi di accesso alle cartelle secondo Autenticazione Form
• Unica libreria per generazione PDF
• Integrazione dati: Web services tra C# e C#, Json tra C# e Javascript

Esempi di REGOLE

• Sulla normalizzazione dei dati a database, sugli indici e sulla nomenclatura
• L'uso di un pattern diversi, di algoritmi ex novo, di soluzioni diverse sono proibiti se non necessari e, nel caso, devono essere sottoposti al responsabile tecnico ed autorizzati.
• Nessuna libreria esterna non ufficiale (in particolare *.js)
• AMBIENTE DI SVILUPPO uguale ed uniforme per ogni sviluppatore. Lo sviluppatore o il responsabile tecnico deve potersi sedere sulla postazione di un collega e lavorare come se fosse sulla sua postazione.
• Il codice deve essere naturalmente chiaro. La documentazione ed i commenti devono essere ridotti al minimo.
• Usare CSS per la user experience. Evitare il javascript se il risultato si può ottenere via CSS
• Durante lo sviluppo ogni DB deve essere sempre ricreabile da zero. E' obbligatorio avere a disposizione una procedura di generazione del DB e dei dati di configurazione base, oppure di una procedura che "pulisce" i dati creando la situazione di istante zero in un db su cui si sta sviluppando. Il costo di tenere allineata una di queste due procedure è ampiamente compensato dal tempo che si risparmia in bug fixing per anomalie che derivano da dati sporchi/incoerenti compreso l'istante in cui il DB deve essere rilasciato in produzione.
• Il codice dei pattern deve essere preso dal repository del pattern, non da codice sviluppato in precedenza
• L'ambiente di produzione deve essere identico all'ambiente di sviluppo, salvo impossibilità. Le differenze necessarie devono essere indicate a partire dal file di configurazione principale. Nell'ambiente di sviluppo il file web.config deve essere contiguo al file web.config.server con chiaro senso dei due file.
• Tutti usano FileZilla per gli upload/download FTP con la stessa identica configurazione. Tutti usano notepad++ come editor extra ide. Tutti usano TotalCommander per copiare files, confrontare cartelle, confrontare sorgenti.
• Tutti i server hanno la medesima configurazione, le medesime librerie nella stessa versione, salvo la naturale rotazione di sistema operativo, web server, DB server. Salvo impossibilità (il cliente necessita si usi il suo server).

Il nostro principale obiettivo è rendere minimo il tempo di sviluppo software.
Questo obiettivo si ottiene con software elegante e naturale. Il codice deve essere di immediata comprensione all'analista ed allo sviluppatore. Le soluzioni standard, i pattern ed il rispetto delle regole consentono di ottenere questo risultato.
Non esistono metriche per poter esprimere in modo oggettivo eleganza e semplicità del software IDeaWeb. Tuttavia lo affermiamo: il codice software ideaweb è organizzato secondo regole precise ed intuitive, risulta elegante e semplice, anche laddove le funzioni che implementa sono complesse.

Allo stato attuale circa il 10% del software sviluppato in IdeaWeb è ex-novo, il 90% del software è modifica di software esistente. La questione più importante è quindi la manutenibilità del software.
Ribadiamo che l'aspetto più importante è la COMPRENSIONE DEL CODICE SVILUPPATO: deve essere corretta e rapida, per poter progettare la modifica e conoscere i punti di impatto e di correzione senza perdere implicazioni che si manifestano solo dopo l'intervento, che spesso costringono a successivi interventi.
Quando gli interventi si susseguono in cascata - modifico A che impatta su B, intervengo su B e creo un problema in C... - e/o si ha la sensazione di perdita di controllo del codice..."la frittata è fatta". Quel codice non è più manutenibile. L'unico approccio conveniente è la completa rifattorizzazione che metta ordine. Ma l'errore è stato portarsi a quel punto.
Il software è complicato per le carenze nella formazione dello sviluppatore, e per la mancanza di supervisione sullo sviluppatore di poca o media esperienza. Anche lo sviluppatore junior, se opportunamente indirizzato e controllato, può codificare in qualità: ne va moderata l'esuberanza e la creatività a favore dell'apprendimento dei fondamentali. Come per la musica: prima si imparano bene le noiose scale, ricercando ed apprezzando la perfezione del gesto. Poi si passa alle composizioni. Ottimizziamo anche i tempi di setup di macchine e dei progetti.

• Il tempo di setup di una macchina di sviluppo su cui sia installato esclusivamente Windows è di circa 2 ore, e comprende lo IDE, i database MySql e SQL server, gli strumenti di gestione FTP.
• Per disporre di un progetto funzionante in ambiente di sviluppo/debug, il tempo è dato dal recupero dei files (qualche secondo), dalla creazione del DB (importazione del dump del DB...da qualche secondo ad un paio di minuti) e dal lancio dell'IDE (qualche secondo). Uno sviluppatore che non ha mai lavorato su un progetto ha il codice del progetto sul proprio pc in esecuzione sull'IDE nel giro di qualche minuto.
• Nel caso sia necessario avere i dati di produzione per investigare su una situazione segnalata dal cliente, il tempo è determinato dalla copia dei file di produzione, estrazione dump del database ed importazione. In genere anche per questo caso è questione di minuti.
• Per attivare un server di produzione, quasi esclusivamente in cloud, sono richieste un paio di configurazioni che si compiono in 1 minuto

L'attuale schema di lavoro in IdeaWeb è il risultato di un lungo processo di valutazione e sperimentazione. Abbiamo provato anche soluzioni Open Source che sono state abbandonate (Vtiger per il gestionale, un software php) migrando i clienti su altre piattaforme.

Abbiamo preso in considerazione svariati principi di lavoro.
Ad esempio, il concetto MVC. L'abbiamo però riscontrato inadeguato, in quanto serve a normare principi che possono essere normati in modo più efficiente.
Un esempio: la tabella prodotto ha il campo "colore" che deve essere mostrato nel dettaglio prodotto.
Questo il codice che ci si aspetta deva essere implementato:

• [Colore: < div id="colore">< / div>] (aggiunta in vista HTML dell'etichetta
• [element.getElementById("colore").InnerText = reader["colore"];] (valorizzazione dell'etichetta nel caso select * from prodotto)
• Si modificano 1 o 2 files massimo.

In MVC? Provate a farlo e contate i files che modificate e le righe di codice che scrivete...

Le software house che non hanno proprie regole di organizzazione del codice, adottando MVC compiono un enorme passo in avanti, non c'è dubbio. Però vince la corsa il pilota con l'auto tarata sulle condizioni ambientali e sul suo stile di guida, non il pilota con l'auto di serie.