development

Refactoring

Siccome mi capita di sentir parlare di “refactoring” o “rifattorizzare” a ogni dannata modifica, giova ricordare che la pratica in oggetto non riguarda la correzione degli errori di codice e/o di analisi, bensì è quella volta a ridurre debito tecnico…

In ingegneria del software, il refactoring (o code refactoring) è una “tecnica strutturata per modificare la struttura interna di porzioni di codice senza modificarne il comportamento esterno“,[1] applicata per migliorare alcune caratteristiche non funzionali del software quali la leggibilità, la manutenibilità, la riusabilità, l’estensibilità del codice nonché la riduzione della sua complessità, eventualmente attraverso l’introduzione a posteriori di design pattern.[2] Si tratta di un elemento importante delle principali metodologie emergenti di sviluppo del software (soprattutto object-oriented), per esempio delle metodologie agili, dell’extreme programming, e del test driven development.

Intro al CVS…

INTRO

CVS e’ un sistema di controllo di versione nato alla fine degli anni ottanta, basato su un precedente software analogo (RCS).

CVS e’ essenzialmente un sistema che permette di tener traccia delle modifiche apportate ai sorgenti di vari progetti, mantenendo una sorta di ‘database centrale’ di tale sorgenti (il ‘repository’).
Per fare cio’ si serve di un programma (un unico eseguibile chiamato anch’esso ‘cvs’) che si occupa di trasferire i file da e per il repository, gestendo le modifiche apportate in base alle differenze tra la copia locale del sorgente e la copia presente nel repository (proprio come un
comando ‘diff’).
L’architettura di lavoro vede quindi 2 ambienti: la propria copia locale appunto, dove si editano, compilano e testano i file dei progetti, ed il repository, che ha la funzione di contenitore dei sorgenti testati/approvati.
ATTENZIONE! Cvs non include un sistema di testing, ne’ di compilazione, e non va a sostituire la comunicazione tra gli sviluppatori; non fornisce pertanto automatismi
sulle decisioni da prendere in base alle modifiche apportate
(in parole povere: se in due si e’ modificato lo stesso sorgente, e vi sono dei conflitti su tali modifiche, cvs non e’ in grado di suggerire quale versione sia da considerare “buona” o migliore, ma devono essere gli sviluppatori a confrontarsi e decidere quali sono le modifiche da tenere).

Cvs e’ free software; indirizzi di riferimento:
http://www.cyclic.com
http://www.loria.fr/~molli/cvs-index.html
http://cvshome.org/

Ecco il minitutorial vero e proprio… e’ particolarmente pensato a chi opera su
piattaforme *nix, ma se si escludono i comandi di sistema, la configurazione di cvs e’ pressoche’ identica anche su win32 ed altre piattaforme.

MODALITA’ CVS

Vi sono due modalita’ fondamentali di lavoro con cvs: con repository locale o con
repository remoto (detta anche ‘client/server’).
A determinare la modalita’ di lavoro e’ il contenuto della variabile d’ambiente $CVSROOT (%CVSROOT% su win) settata sul client, oppure l’equivalente opzione “-d …” data al comando.

A sua volta poi la modalita’ con repository remoto puo’ essere effettuata con diversi metodi di accesso:
pserver (autenticazione normale con pwd in chiaro), via rsh o ssh, mediante GSSAPI (autent. Kerberos)

LAVORARE CON CVS

Possiamo dire che, dal punto di vista dello sviluppatore, cvs si integra nel lavoro quotidiano alla perfezione, e la sua adozione e’ possibile in pressoche’ qualunque ambiente di sviluppo in circolazione, sia esso software libero o proprietario (pensate che e’ possibile anche sostituire VisualSourceSafe con cvs all’interno dell’ambiente di sviluppo Visual Studio della Microsoft).

All’atto pratico, pochi semplici gesti in piu’ rispetto allo sviluppo senza controllo di versione, e tutto il lavoro si arricchisce di enormi possibilita’ ed impagabili comodita’:


il normale ciclo di lavoro si compone di 4 fasi fondamentali: messa in stato di “editing” di uno o piu’ sorgenti interessati alle modifiche, modifiche vere e proprie sui file, test, conferma (“commit”) delle modifiche con un commento adeguato (il commit togliera’ lo stato di editing dai sorgenti confermati);
– prima di lavorare su un sorgente, e’ buona norma aver aggiornato la propria copia locale, per diminuire la probabilita’ di dover fronteggiare conflitti rispetto a modifiche di altri sviluppatori;
– e’ possbile, giocando con le varie possibilita’ che le opzioni di cvs offrono, ottenere facilmente un changelog accurato; o il dettaglio granulare delle modifiche fatte da una revisione all’altra, per non parlare dei grafici che possono essere generati in base al log tree e che rendono in maniera molto efficace l’andamento dello sviluppo di un progetto;
– last but not least… lavorare con cvs significa, per un team, non essere mai fermi, in quanto e’ possibile (ed anzi: e’ il suo forte) lo sviluppo concorrenziale dello stesso sorgente, dal momento che le modifiche e i test avvengono in ambienti fisicamente separati (le “sandboxes”).

CONFIGURAZIONE CVS: Il repository

– Come utente root, creare utente ‘cvs’ con gruppo primario ‘cvs’;
– creare una directory ‘repository’ all’interno della home dir. dell’utente cvs;

-assicurarsi che tutti gli utenti che debbano accedere al repository appartengano (anche solo come gruppo secondario) al gruppo ‘cvs’.
– Impostare i permessi del repository a ‘770’ (rwxrwx—), ed anche il bit s sul gruppo (“chmod g+s /home/cvs/repository”): questo fa si’ che i nuovi file creati nel repository appartegano allo stesso gruppo a cui appartiene la dir. repository stessa anziche’ al gruppo dell’utente che ha aggiunto i nuovi file.

A questo punto bisogna inizializzare il repository (questa operazione crea una struttura particolare di directory e di file amministrativi che servono all’eseguibile ‘cvs’ per lavorare)
il comando di inizializzazione e’: cvs -d “dir_del_repository” init
esso viene lanciato, dall’amministratore del repository, solo la prima volta che si va a configurare il repository.

CONFIGURAZIONE CVS: La copia locale (detta anche ‘sandbox’ o ‘working copy’)

Cvs
per lavorare ha bisogno della variabile di shell CVSROOT che indichi la modalita’ di accesso al repository, oppure ogni comando deve avere come primo parametro “-d dir_del_repository”

– Settaggio variabile d’ambiente

nel caso di repository locale:
$ export $CVSROOT=dir_del_repository

nel caso di repository remoto, il formato di tale variabile sara’:
:metodo_accesso:utente@hostname:dir/del/repository

dove dir/del/repository e’ sempre il path reale del repository sulla macchina remota (‘server’)

– Inserimento di un nuovo progetto sotto cvs

$ creazione della directory del progetto nella propria home
$ cd directory del progetto
$ cvs import “dir_del_progetto” nomeutente start
$ rmdir dir_del_progetto

poi usare

$ cvs -r co dir_del_progetto

per avere la copia del progetto sotto cvs

PRINCIPALI COMANDI CVS

– cominciare a lavorare e prendere le ultime versioni aggiornate
da lanciare nella directory padre della copia locale (crea automaticamente la directory del progetto)
$ cvs -r checkout “nomeprogetto” -dP

– aggiungere un nuovo file al repository
$ creare il file
$ cvs add “nomefile”

– se il file e’ binario
$ cvs add -kb “nomefile”

– togliere un file
$ cvs remove -d “nomefile”

– confermare i cambiamenti (modifiche ai sorgenti, aggiunta o rimozione di file)
$ cvs commit -> apre vi per la scrittura del log

oppure
$ cvs commit -m”messaggio di log”

– chiedere i log
$ cvs log [nomefile]

– chiedere lo stato dei file
$ cvs status [nomefile]

– cancellare un progetto locale (nella directory padre del progetto)
$ cvs release -d “progetto”

– fissare una versione
il nome della versione deve essere senza “.”: ad esempio, rel-1-0
$ cvs rtag “nome_versione” “nomeprogetto”

– prendere tutto il progetto per la distribuzione con i file piu’ recenti
$ cvs export -r HEAD “nomeprogetto”

– prendere tutto il progetto per la distribuzione di una certa versione
$ cvs export -r “nome_versione” “nomeprogetto”

– vedere le versioni
$ cvs history -xT -a

EDITING DEI FILE

– Editing normale

$ cvs edit [nomedelfile]
$ vi [nomedelfile]
$ cvs unedit [nomedelfile]
oppure se si vogliono anche confermare i cambiamenti
$ cvs commit

– edit con lock
$ cvs admin -l [nomedelfile]
$ vi [nomedelfile]
$ cvs admin -u [nomedelfile]

(!) prima di editare il progetto e’ bene dare il comando
$ cvs update

per avere le ultime versioni dei file

——————————————————

Risorse

1) CVS Home (http://cvshome.org/)
2) “Installing adn Configuring CVS on RedHat Linux 7 as an SCM Repository” (http://www7b.software.ibm.com/wsdd/library/techarticles/0205_yu/yu.html)
3) LinCVS (http://lincvs.org/)
4) Cervisia (http://cervisia.sourceforge.net/)

——————————————————

Copyright e Autorizzazione:
Copyright (2002-2003) by Domenico Ferrari (aka dome) and Marco Frattola (aka sbarrax).

La copia e la distribuzione integrale dell’ articolo sono permessi in qualsiasi forma e mezzo a condizione che l’indicazione del copyright e questa nota siano riportate.
Per qualsiasi segnalazione mandate email all’indirizzo: framar@sbarrax.it
——————————————————