Analisi, sviluppo, modifiche, cambiamenti. Stravolgimenti.
Ci sono decine e decine di testi che trattano argomenti spinosi della programmazione di un buon software, che insegnano – o danno linee guide – su come un buon developer debba sviluppare e creare il software affinchè sia facilmente manutenibile, espandibile, adattabile ad esigenze future, etc. etc. Concetti importanti e ai quali non riusciamo più a fare a meno consentono di rendere indipendente un componente software da un altro. Parlo in prima persona: quando sviluppo un software (compreso quello su cui sto lavorando in questi mesi su PPC/WM) penso a come separare la UI dal DAL, oppure le logiche di business dall’engine che uso per i report, il componente per la comunicazione seriale e così via. E’ importante, ovviamente, perchè se un giorno decidiamo – esempio a caso – di usare Crystal Report invece di SQL Server Reporting Services, il software deve essere modulare, al punto che posso sostituire un assembly con un altro pur mantenendo il dialogo fra i componenti (interfacce).
Ma c’è una cosa su cui ho sempre difficoltà. Il cambiamento deve essere un cambiamento in linea con quanto determinato dall’analisi iniziale. Il cambiamento non deve portare a ripensamenti dell’architettura tale per cui quello che prima era uno stupido e semplice client diventi addirittura un server. Questi non sono cambiamenti: sono stravolgimenti, ai quali sinceramente non so ancora reagire in modo naturale. Quando al team di sviluppo vengono comunicati questo tipo di cambiamenti, bisogna avere la mente lucida ed avere il coraggio di dire che le persone che inizialmente hanno dato il via ai lavori probabilmente non hanno assolutamente pensato al sistema nella sua completezza.
E’ qui che le cose cominciano ad andare male, perchè apportare stravolgimenti ad un progetto software significa attaccare pezzi, significare invertire le frecce dei diagramma di flusso, significa che quello che prima era un output adesso è un input. Un bel po’ di cose per essere sicuri di poter continuare a sviluppare secondo i criteri a cui ho accennato all’inizio del post, perchè magari bisogna adattarsi a queste modifiche in tempi rapidi, e non sempre si ha l’accortezza di seguire le buone maniere della programmazione. Ed i bytes ne risentono, soprattutto se parliamo di bytes di un device PPC/WM, dove le risorse sono limitate e bisogna stare un pochino attenti a quello che si fa.
Ma non solo: se all’analisi segue lo sviluppo, se allo sviluppo segue un cambiamento, e poi un altro, ed un altro ancora, poi c’è uno stravolgimento…chi ci assicura che dopo non seguirà un altro stravolgimento che invalida (più o meno parzialmente) il lavoro che sto facendo oggi e per il quale vengo pagato?
Technorati Tags: programming work
Send to Kindle