Come nasce un’applicazione vol.2
3 June 2006
Ciao a tutti,
Pubblico la seconda parte dell’articolo che ci terrà occupati nei prossimi giorni. In questa parte vedremo come definire un sistema di version tracking, che ci aiuterà a tenere traccia delle innumerevoli modifiche apportate alla nostra applicazione. Vedremo inoltre come non perdere di vista la nostra roadmap attraverso uno strumento semplice quanto indispensabile: il todo.
Il Version Tracking
Da piccolo sviluppatore di applicazioni Open Source, mi sono trovato più volte a perdermi tra le varie features da preparare, i bugs da correggere e i test da effettuare. Prendiamo quindi la nostra roadmap e assegnamo, ad esempio, alle funzioni core, la versione 1.0. Definiamo quindi come vogliamo differenziare le nostre release. Un esempio molto usato consiste nell’utilizzare tre numeri di versione, ai quali possiamo aggiungere delle informazioni aggiuntive. La nostra release quindi sarà strutturata come versione X.Y.Z *. X sarà quindi la versione del nostro core, contenente le funzioni strutturali dell’applicazione. Ad Y corrisponderanno le release di nuove funzioni aggiuntive, mentre Z segnalerà eventuali release con patch urgenti o correzioni di bug importanti. Classifichiamo inoltre ogni release in base al suo stadio di testing: alpha, beta e stable. Una alpha sarà generalmente testata in locale o comunque da un team appositamente scelto, una beta potrà essere già resa disponibile al pubblico, con comunque la consapevolezza di potersi imbattere in errori, mentre una stable (la dicitura di solito viene omessa) deve essere solida e priva di difetti immediati. Per le alpha e le beta è utile indicare inoltre la data dell’ultima modifica, meglio se in formato AAAAMMGG. Le modifiche in corso d’opera ad una versione non stable vanno segnalate come “beta N” (N=2,3,…), mentre le stable vanno droppate (rimosse) dal loro status di stable, fino alla certezza della rimozione del bug e della non insorgenza di altri errori.
Il TODO
Letteralmente, le “cose da fare”. Solitamente vengono rilasciate nel README assieme all’applicazione, e demarcano le features da aggiungere e il corrispondente numero di versione nelle quali queste funzioni appariranno. Seguiamo il TODO ed usiamolo come traccia, ma non irrigidiamoci: se la nostra fantasia ci suggerisce qualcosa, inseriamola. Se abbiamo un bug da correggere, che non ci sembra critico, inseriamolo nel TODO alla release ragionevolmente più vicina.
Nel prossimo articolo, vedremo come tener traccia dei bug della nostra applicazione, in modo da individuarli e correggerli nel modo più rapido e organico possibile.
Partorito da
Lascia un commento