[Linux-Biella] Ingegneria Informatica

[Mastro]

Paolo Ciarrocchi ha scritto:

 > On 4/4/06, Mastro <daniele.bilug a gmail.com> wrote:
 > [...]
 >>>> eh eh.. si il motivo è come al solito che non avete ancora capito che
 >>>> cos'è ingegneria informatica...
 >>> Non è che ci sia così tanto da capire...
 >>>
 >>>
 >> ah si? forse non hai letto l'altra mail che ho scritto "[Linux Biella]
 >> Ingegneria Informatica"! per ora mi ha risposto solo Paul TT..
 >> leggila e poi rispondi di nuovo a quest'ultima mia affermazione..
 >
 > Daniele, cosa si insegna a Ingegneria Informatica e' chiaro a chi ha
 > frequentato un corso di Ingegneria, le altre persone spesso la
 > confondono con la "pura programmazione".

ho già provato a descrivere quello che si insegna nell'altro post...
a cui tu mi hai risposto qui sotto facendoti una domanda

(non allego tutto il mio spiegone perchè penso lo abbiate ricevuto tutti..)

Paolo Ciarrocchi ha scritto:

> On 4/3/06, Mastro <daniele.bilug a gmail.com> wrote:
> [...]
>> domande? :P
> 
> Si.
> Cosa e' la programmazione estrema?

Programmazione Estrema o eXtreme Programming in inglese (si abbrevia XP 
e bigM non centra una mazza..)

premettendo che me le sono studiate da solo alla veloce e che quindi non 
sono un esperto mondiale... un giorno spero di trovare il tempo di 
studiarmele bene... diciamo che per ora mi sono fatto un idea...

intanto vi do dei link....
la programmazione estrema è semplicemente una metodologia di 
programmazione per team di medie dimensioni che se applicata dovrebbe 
migliorare la qualità del codice e quindi la facilità di aggiornamento e 
assenza di bug... fa parte delle così dette metodologie di 
programmazione agile (o leggera) e non è l'unica, ma solo la più 
famosa.. anzi in realtà sarebbe utile conoscerle tutte...

vi consiglio questo testo:

http://martinfowler.com/articles/newMethodology.html

o la sua traduzione italiana

http://www.marcopapacchini.com/agility/nuovametodologia.html

parlano delle metodologie Agili e accennano all'XP

qui invece trovate link ad articoli dedicati ad XP:

http://www.tecnoteca.it/upgrade/aprile_2002

in queste pagine troverete tutto ciò che c'è da sapere ma provo a farvi 
un piccolo sunto..

l'XP non dice nulla di nuovo.. prende molte pratiche di buona 
programmazione e le mette assieme "estremizzandole"

il tutto parte dalla "user stories" cioè da quello che il cliente ci 
dice di volere (che poi non è mai quello che vuole) da qui si fa un 
progetto e si implementa, il più velocemente possibile..
cioè si deve fare la cosa + semplice per ottenere lo scopo senza 
preoccuparsi del futuro.. però si devono aggiungere piccole modifiche 
alla volta, non si devono fare straordinari e ci si deve riposare 
regolarmente, mantenere le cose semplici e usare metafore quando 
necessario. Quindi ci si ritrova dal cliente per sentire la sua nuova 
storia circa a metà lavoro (quando l'utente vede già qualcosa capisce 
meglio cosa vuole) e qui si cicla..

programmando:
si deve cominciare scrivendo i test, e solo dopo i metodi o le classi 
vere e proprie..

si deve programmare a coppie, ad esempio si programma per un oretta, poi 
ci si scambia e si guarda il lavoro dell'altro, le coppie vanno cambiate 
regolarmente (ovviamente questo funziona su programmatori con esperienze 
paragonabili)

tutti devono avere accesso a tutto il codice e poterlo modificare, con 
la regola che prima di effettuare la modifica scrivano il test per la 
modifica..

seguire una guida di stile unificata (stesso tipo di indentamente ecc.. 
ecc..)

refactoring.. sono tutte quelle modifiche che non aggiungono 
funzionalità ma che sono necessarie per modificare il funzionamento del 
codice o per aggiungervi funzionalità, direi che l'XP si basa su questo, 
perchè se scrivete codice senza preoccuparvi del futuro è inevitabile 
che dovrete riadattarlo.. ci sono tecniche di refactoring che permettono 
di stravolgere in poco tempo la struttura del codice senza cambiarne la 
funzionalità ma aumentandone di molto l'espandibilità


tutto questo dovrebbe far si che il costo di aggiornamento del software 
cresca logaritmicamente anzichè esponenzialmente..

poi ci si scontra con altre cose come il principio di sostituzione di 
Liskov: in poche parole dice che il test di una superclasse DEVE essere 
valido anche per tutte le sottoclassi.. in sostanza serve a capire 
quando è meglio usare un interfaccia o una classe astratta..

non mischiare più comportamenti in un unica classe ma mantenerli 
separati ecc...

in oltre c'è uno studio matematico della rigidità del codice che si basa 
sulle dipendenze tra classi... io ve lo risparmierei.. salvo che 
qualcuno non lo voglia sentire.

un'ultima precisazione sui test (o collaudo): non hanno molto senso su 
moduli grafici... in quel caso funziona meglio l'osservazione diretta...

spero di aver risposto alla tua domanda..
-- 
ciao
-----------------
Mastro (Daniele)