riflessioni personali: organizzazione e metodi di lavoro

[cionci]

Angus: ti va di dare un'occhiata al nostro repository, se vai nella sottosezione ci sono tutte le istruzioni

[Angus]

Originariamente inviato da cionci

Angus: ti va di dare un'occhiata al nostro repository, se vai nella sottosezione ci sono tutte le istruzioni

Certo che mi va! Ho evitato di farlo finora perchè in ufficio sono assediato dai turchi (analisti funzionali) e la prossima scadenza è venerdì
Invece il pc di casa è ancora inballato per il trasloco in corso

[Giakino]

Tornando un pò all'argomento, oggi ho visto un libro che a prima vista m'ispira molto, qualcuno lo conosce?
"Ingegneria del codice" di Steve McConnell
http://education.mondadori.it/Libri/...=88-04-54034-6

Interessato ai vari commenti...prima di spendere (eventualmente inutilmente) 80 eu

Che poi ho anche letto su un libro di uml che XP è una cosa "pericolosa" per il fatto che c'è poca progettazione inizialmente e si "butta" codice così come capita Ma che comunque (XP) può andar bene per piccoli/medi progetti con team di alto livello e organizzazione al massimo...

[71104]

Originariamente inviato da Giakino

Tornando un pò all'argomento, oggi ho visto un libro che a prima vista m'ispira molto, qualcuno lo conosce?
"Ingegneria del codice" di Steve McConnell
http://education.mondadori.it/Libri/...=88-04-54034-6

Interessato ai vari commenti...prima di spendere (eventualmente inutilmente) 80 eu

Che poi ho anche letto su un libro di uml che XP è una cosa "pericolosa" per il fatto che c'è poca progettazione inizialmente e si "butta" codice così come capita Ma che comunque (XP) può andar bene per piccoli/medi progetti con team di alto livello e organizzazione al massimo...

l'autore di quel libro non conosce fek

[Giakino]

Ehehe, probabile
Parteciperei volentieri a diamonds, mi piace come cosa. L'unico problema è che attualmente il tempo a disposizione è sempre pochissimo e comunque sono ancora in fase di studio di java, che dato il tempo procede lento
Attendo poi commenti per l'altro libro

[VICIUS]

Originariamente inviato da Giakino

Tornando un pò all'argomento, oggi ho visto un libro che a prima vista m'ispira molto, qualcuno lo conosce?
"Ingegneria del codice" di Steve McConnell
http://education.mondadori.it/Libri/...=88-04-54034-6

Interessato ai vari commenti...prima di spendere (eventualmente inutilmente) 80 eu

Che poi ho anche letto su un libro di uml che XP è una cosa "pericolosa" per il fatto che c'è poca progettazione inizialmente e si "butta" codice così come capita Ma che comunque (XP) può andar bene per piccoli/medi progetti con team di alto livello e organizzazione al massimo...

Spettacolare come libro. Da leggere assolutamente. Anche se forse 80€ mi sembrano veramente troppi. Io l'ho pagato circa 28 sterline.

ciao

[fek]

Originariamente inviato da 71104

io dovrei ringraziare fek per varie cose che ho imparato da lui, sia insegnatemi esplicitamente che implicitamente.

Non avevo letto prima, che bel complimento, grazie

[Giakino]

Originariamente inviato da VICIUS

Spettacolare come libro. Da leggere assolutamente. Anche se forse 80€ mi sembrano veramente troppi. Io l'ho pagato circa 28 sterline.

ciao

Azz...28 £ --> circa 41 €
Il problema sarebbe solo che in inglese ci metterei una vita per capire fuori qualcosa, quindi a questo punto meglio in italiano...anche se dovrei iniziare a leggere un pò di manuali in inglese, fanno solo bene..
A parte il prezzo (forse un pò esagerato), quindi mi consigli di prenderlo ? Hai trovato qualcosa di scritto con cui non sei proprio d'accordo (es dice una cosa quando in realtà non è così et similiar)?

Il grande fek, che onore averti in questo topic A questo punto però attendo anche tuoi commenti su tutto

[fek]

Originariamente inviato da Ozn ZzZ

Se ho capito bene,vorresti fare dei programmi software efficenti senza neanche utilizzare un minimo di documentazione UML?

Si'. L'unica documentazione sempre aggiornata il codice. Il resto e' documentazione sempre e comunque non aggiornata, che ha un costo mantenere e che non fornisce alcun valore al cliente.

Io invidio chi ci riesce,e stai pur certo che di "luminari" del settore che riescono ad utilizzare extreme programming ce ne sono,ma sono davvero mosche bianche.

Non sono proprio mosche bianche, diciamo che pian piano stanno diventando la maggioranza, a partire da:
http://www.thoughtworks.com/index.html

In pochissimi anni e' passata dall'essere una piccola azienda di software all'essere una multinazionale con sedi in tutto il pianeta. E usano solo metodologie agili di sviluppo.

Non penso ci si possa illudere di fare dei progetti utilizzando metodologie agili tranne se non si e' sotto determinate condizioni.

Io penso che non ci si possa illudere di fare dei progetti di una certa qualita' con la speranza di consegnargli in tempo e di dare valore al cliente cercando di progettare tutto a priori, magari attraverso documenti UML ed una metodologia Waterfall. A parte in rarissimi casi, quando le specifiche sono immutabili e perfettamente formalizzate. Ovvero in una strettissima minoranza dei casi, e di solito non in situazioni di mercato, dove l'economia stessa impone continui cambiamenti ai requisiti, tali da rendere anti economiche metodologie di sviluppo con una curva dei costi classica.

Io non so al giorno d'oggi quale sia il cliente che preferisca spendere soldi per mesi senza vedere uno straccio di applicazione, ma solo gran documentazione che non gli risolve alcun problema. L'alternativa e' vedere un'applicazione che inizia a risolvergli i problemi fin dal primo ciclo, dopo un paio di settimane.

E qui ti sorge spontanea la domanda.Ma e' cosi facile creare un team di sviluppo che riesca ad intervenire sul codice scritto da altri e a sviluppare lo stesso progetto software senza fare uso di "scartoffie UML" che descrivano un percorso guida?

Se pensi che un gruppo di ragazzi sostanzialmente alle prime armi in quanto a programmazione, guidati da me che non ho certo grande esperienza da Coach, ci riesce piuttosto bene proprio su questo forum, devo dire che non e' cosi' difficile mettere in pratica un po' di XP

P.s. Se ti interessa l'argomento c'e' questo libro Giancarlo Succi, Michele Marchesi, Extreme Programming Examined

Ce n'e' un altro interessante: Extreme Programming Refactored, che in sintesi nega ogni singola pratica dell'XP. Una lettura utile.

[fek]

Originariamente inviato da Ozn ZzZ

Farlo all'inizio penso sia un supporto che ti eviti "orrori" nella generazione del codice .
Come si fa a fare un software per la gestione di un magazzino dell'iperstanda o un virtual store senza fare a monte uno studio concettuale.Il rischio di perdersi per strada penso sia elevatissimo.Si rischia di accorgersi solo alla fine dell'inconsistenza del proprio prodotto

E' l'esatto contrario invece. Nessun cliente capisce uno schema UML per quanto dettagliato e non e' in grado di sapere se il design stesso ricalca i suoi bisogni, risolve i suoi problemi, segue le sue specifiche (che spesso neppure e' in grado di formulare correttamente). E se dopo mesi passati a scrivere documentazione e design ci si aggorge che il design non risolve il problema perche' alla prima demo il cliente esce con un: "ma non e' quello che chiedevo io"?

Si butta tutto e si riparte.

E se cambiano le specifiche perche' cambia il mercato?

Si butta tutto e si riparte.

Al contrario, se il cliente vede ogni due settimane un'applicazione con la quale puo' sperimentare e "giocare", e' in grado di capire immediatamente se l'applicazione si sta indirizzando verso il suo obiettivo o meno. E puo' dare indicazioni tempestive per "guidare" il resto dello sviluppo. E puo' cambiare le specifiche sapendo che il team di sviluppo adotta pratiche tali da appiattire la curva dei costi e cambiare il design a costi virtualmente costanti durante tutto l'arco dello sviluppo.

E' semplicemente un modo piu' economico di scrivere software piu' robusto e che corrisponde alle richieste del cliente.

[fek]

Originariamente inviato da end.is.forever

Chi deve costruire un palazzo sicuramente prima di prendere in mano i suoi strumenti (o molto più spesso di dire a qualcun'altro di farlo), sicuramente farà un progetto, e avrà una sua metodologia per pensare cosa fare, ma soprattutto per descrivere a chi lo paga in che modo agirà e perchè ha deciso di optare per una scelta invece che un'altra.

Esempio classico: quando si costruisce un ponte, lo si progetta fin nei minimi dettagli e poi lo si costruisce. Ed e' un procedimento che funziona da centinaia di anni.

Ma... scrivere software non e' come costruire un ponte

E' un procedimento totalmente differente, perche' le specifiche dei ponti o delle case non cambiano in continuazione, i requisiti sono facilmente formalizzabili, i calcoli delle tempistiche sono anch'essi legati a formule piuttosto precise.

Tutto questo nel software non esite, se non in situazioni particolari e infrequenti. Le specifiche nel software cambiano in continuazione, i requisiti si modificano, non solo, nella maggior parte dei casi non possono essere formalizzati, perche' neppure il cliente li conosce fino a che non vede l'applicazione girare.

La sintesi e': non si puo' costruire un software come si costruisce un ponte perche' sono "oggetti" inerentemente differenti e necessitano di metodologie differenti. Nel software servono metodologie che permettano di calcolare in maniera il piu' precisa possibile il costo di sviluppo a partire dalle specifiche del cliente che mutano in continuazione. Dev'essere possibile dire al cliente "Se tu vuoi questo nelle prossime due settimane, ti costa questo, se vuoi quello, ti costa quello, quello in due settimane non e' possibile, o lo dividi o chiedi altro". Sulla base di questi dati il cliente sceglie di volta in volta le feature che rappresentano per lui il maggior valore economico a fronte della spesa.

Nel software non funziona dire "Tu vuoi l'applicazione che faccia tutto questo e io te la faccio in 6 mesi". Che poi diventano 12 e all'ottavo mese il cliente smette di pagare e va da un'altra parte...

[fek]

Originariamente inviato da Angus

E' una lama a doppio taglio... Ma non voglio star qui a discutere di quale sia la migliore strategia, ho già espresso il mio parere.
Da quello che dici vai molto orgoglioso della struttura del codice che sta venendo fuori 'da sola'. Ma finora sembra che col refactoring vi preoccupiate di eliminare lo 'spaghetti-code', ma in quale momento cercate di capire se la struttura ad alto livello è buona o no? Per buona intendo non ridondante, con codice centralizzato, e facilmente manutenibile ed estensibile?
C'è qualcuno che se ne occupa?

Ce ne occupiamo principalmente io e Vicius che abbiamo un'idea "molto generale" del design globale. Sappiamo dall'esperienza che la game logic deve essere separata dall'engine logic, ma non ci spingiamo oltre. Il codice ci dice "come vuole essere sistemato" in base alle specifiche che il Customer ci da' e il suo input al termine di ogni Ciclo (input a partire dall'applicazione che esamina).

Ad ogni punto noi guardiamo lo stato del progetto e cerchiamo di semplificarlo, magari mi accorgo che un certo numero di classi inizia ad assomigliare ad un qualche Design Pattern ed a quel punto inizio un refactoring che diriga il codice verso quel Design Pattern (non lo impongo a priori), perche' so che quel DP mi da' alcuni vantaggi e mi semplifica la struttura logica magari.

E' un design continuo (si chiama evolutivo). Usare una metodologia agile non significa non fare design, ma significa farlo in continuazione ad ogni passo dello sviluppo, e capire come il codice vuole essere strutturato.

Questo articolo di Martin Fowler spiega il concetto molto meglio di come posso fare io:

http://www.martinfowler.com/articles/designDead.html

(Lui e' un pochino piu' bravo di me come divulgatore )

[fek]

Originariamente inviato da Angus

Credo che finora il TDD abbia faticato ad emergere semplicemente perchè i framework attuali non sono stati accompagnati da tool all'altezza. Col tempo mi aspetto che il TDD diventi una cosa talmente naturale e automatizzata da fare che non ci renderemo neanche più conto di usarlo.
Ora sto decisamente vaneggiando, mi fermo qui.

Verissimo. Fare TDD in C++ senza tool di refactoring decenti ad esempio (Ref++ e' ok, ma non all'altezza dei tool di refactoring di Java), il framework di unit testing me lo sono scritto da solo (in TDD ), non e' certo una passeggiata al parco ed inizia a non essere cosi' attraente rispetto a metodologie piu' classiche. Il C++ e' una brutta bestia.

Ma quando si passa a Java (C#/SmallTalk/etc), i costi di refactoring crollano grazie ai tool, i costi di unit testing sono bassissimi e i benefici dell'avere test che non solo aiutano il refactoring ma documentano il codice stesso, formalizzano i requisiti, comunicano i bug. Tanti vantaggi per un po' di codice in piu'

[The3DProgrammer]

Originariamente inviato da fek

E' l'esatto contrario invece. Nessun cliente capisce uno schema UML per quanto dettagliato e non e' in grado di sapere se il design stesso ricalca i suoi bisogni, risolve i suoi problemi, segue le sue specifiche (che spesso neppure e' in grado di formulare correttamente). E se dopo mesi passati a scrivere documentazione e design ci si aggorge che il design non risolve il problema perche' alla prima demo il cliente esce con un: "ma non e' quello che chiedevo io"?

Si butta tutto e si riparte.

E se cambiano le specifiche perche' cambia il mercato?

Si butta tutto e si riparte.

Al contrario, se il cliente vede ogni due settimane un'applicazione con la quale puo' sperimentare e "giocare", e' in grado di capire immediatamente se l'applicazione si sta indirizzando verso il suo obiettivo o meno. E puo' dare indicazioni tempestive per "guidare" il resto dello sviluppo. E puo' cambiare le specifiche sapendo che il team di sviluppo adotta pratiche tali da appiattire la curva dei costi e cambiare il design a costi virtualmente costanti durante tutto l'arco dello sviluppo.

E' semplicemente un modo piu' economico di scrivere software piu' robusto e che corrisponde alle richieste del cliente.

e vallo a spiegare ad alcuni prof universitari!!

ho dovuto fare un annetto fa un progetto di sistema informativo (solo design UML e database, con qualke maskera x l'anagrafica ecc) proprio mentre in quel periodo stavo sviluppando un gestionale three tier x un'azienda milanese (High medical technologies SRL) con MFC/DAO 3.5. Con poseidon ne è venuto fuori un file da 20 MB su cui ho lavorato 3 mesi x realizzare il design di un sottoinsieme delle funzionalità del sw che stavo realizzando (ricordo che il prof pretendeva 3 modelli, uno di business in cui si valutavano le effettive richieste del cliente con annessa catena del valore di Porter ed altre amenità varie, modello concettuale e realizzativo). Conclusioni: ho terminato prima il sw che il progetto

cmq, oggettivamente, a posteriori devo dire che a qualkosa è servito, anche se IMHO un lavoro del genere prima dello sviluppo vero è proprio è improponibile

[fek]

Originariamente inviato da The3DProgrammer

e vallo a spiegare ad alcuni prof universitari!!

ho dovuto fare un annetto fa un progetto di sistema informativo (solo design UML e database, con qualke maskera x l'anagrafica ecc) proprio mentre in quel periodo stavo sviluppando un gestionale three tier x un'azienda milanese (High medical technologies SRL) con MFC/DAO 3.5. Con poseidon ne è venuto fuori un file da 20 MB su cui ho lavorato 3 mesi x realizzare il design di un sottoinsieme delle funzionalità del sw che stavo realizzando (ricordo che il prof pretendeva 3 modelli, uno di business in cui si valutavano le effettive richieste del cliente con annessa catena del valore di Porter ed altre amenità varie, modello concettuale e realizzativo). Conclusioni: ho terminato prima il sw che il progetto

cmq, oggettivamente, a posteriori devo dire che a qualkosa è servito, anche se IMHO un lavoro del genere prima dello sviluppo vero è proprio è improponibile

Lo feci anch'io per l'esame di Ingegneria del Software II: sei mesi di analisi dei requisiti, documenti, diagrammi UML, senza una riga di codice, perche' la professoressa si vantava di questa peculiarita'.

E' stato un esame utilissimo perche' mi ha insegnato fondamentalmente due cose: il software non si costruisce in quel modo, e le donne non devono costruire software

[jappilas]

Originariamente inviato da fek

Lo feci anch'io per l'esame di Ingegneria del Software II: sei mesi di analisi dei requisiti, documenti, diagrammi UML, senza una riga di codice, perche' la professoressa si vantava di questa peculiarita'.

E' stato un esame utilissimo perche' mi ha insegnato fondamentalmente due cose: il software non si costruisce in quel modo, e le donne non devono costruire software

stessa cosa che mi ha suggerito il fatto di avere avuto una donna a Fondamenti d' Informatica II ...

[71104]

la nozione te la posso generalizzare così, e bada bene solo per esperienza personale, non sono maschilista: le donne che programmano fanno ridere
prova a leggere i sorgenti scritti da una donna, fanno ridere per davvero, sono tutti incasinati indentazione completamente sballata, errori dappertutto...
la mia esercitatrice di Algoritmi 1 è una perfetta scema che dice che alle sue lezioni lei programma in pseudocodice perché non vuole perdere tempo a ragionare sulla sintassi del C... MA CHE RAZZA DI DISCORSO, si vede benissimo che è na sega
oltrettutto lo pseudolinguaggio che usa lei è tutto particolare... vabbè va', velo pietoso...

[71104]

Originariamente inviato da fek

Non avevo letto prima, che bel complimento, grazie

di niente, lo meriti: grazie a te un programmatore nel mondo è diventato più produttivo
porti sempre argomenti interessanti sul forum, e anche quando non sono d'accordo su quello che dici mi fai comunque ragionare, e questo non fa mai male a nessuno

[71104]

Originariamente inviato da fek

E' l'esatto contrario invece. Nessun cliente capisce uno schema UML per quanto dettagliato e non e' in grado di sapere se il design stesso ricalca i suoi bisogni, risolve i suoi problemi, segue le sue specifiche (che spesso neppure e' in grado di formulare correttamente). E se dopo mesi passati a scrivere documentazione e design ci si aggorge che il design non risolve il problema perche' alla prima demo il cliente esce con un: "ma non e' quello che chiedevo io"?

Si butta tutto e si riparte.

E se cambiano le specifiche perche' cambia il mercato?

Si butta tutto e si riparte.

Al contrario, se il cliente vede ogni due settimane un'applicazione con la quale puo' sperimentare e "giocare", e' in grado di capire immediatamente se l'applicazione si sta indirizzando verso il suo obiettivo o meno. E puo' dare indicazioni tempestive per "guidare" il resto dello sviluppo. E puo' cambiare le specifiche sapendo che il team di sviluppo adotta pratiche tali da appiattire la curva dei costi e cambiare il design a costi virtualmente costanti durante tutto l'arco dello sviluppo.

E' semplicemente un modo piu' economico di scrivere software piu' robusto e che corrisponde alle richieste del cliente.

ottimo, ottimo: mi ritrovo perfettamente in queste parole, vuol dire che sono un buon allievo!! mwhauhauwhauwhauwhauwa

[71104]

Originariamente inviato da fek

Verissimo. Fare TDD in C++ senza tool di refactoring decenti ad esempio (Ref++ e' ok, ma non all'altezza dei tool di refactoring di Java), il framework di unit testing me lo sono scritto da solo (in TDD ), non e' certo una passeggiata al parco ed inizia a non essere cosi' attraente rispetto a metodologie piu' classiche. Il C++ e' una brutta bestia.

Ma quando si passa a Java (C#/SmallTalk/etc), i costi di refactoring crollano grazie ai tool, i costi di unit testing sono bassissimi e i benefici dell'avere test che non solo aiutano il refactoring ma documentano il codice stesso, formalizzano i requisiti, comunicano i bug. Tanti vantaggi per un po' di codice in piu'

come dicevo però sul TDD ancora non mi trovo d'accordo: secondo me questi test che stiamo facendo hanno un costo troppo elevato che rallenta più che percettibilmente lo sviluppo del lavoro. è innegabile che il codice di Diamonds senza i test si dimezza, e a quanto pare non sempre questi test hanno funzionato a dovere (vedi l'esperienza del sistema di coordinate: ci ha dimostrato una cosa che ritenevo praticamente impossibile, cioè che i programmi possono "funzionare per caso" non avevo mai visto un programma funzionare così ).
il problema della documentazione secondo me è diverso: tu dici che la documentazione può essere completamente eliminata in favore dei test, i quali formalizzano il comportamento del programma al suo posto; io dico non proprio: secondo me in mancanza di test la documentazione ci deve essere, ma ad un altro livello: a livello funzionale.
esempio pratico, in Diamonds non bisogna documentare che abbiamo una classe Engine intesa come motore grafico del gioco basato su OpenGL; mentre invece bisogna documentare che il sistema di coordinate ha l'origine posto in alto a sinistra e l'asse delle Y orientato verso il basso.
la documentazione non deve coprire aspetti concettuali, imho deve coprire aspetti esclusivamente funzionali; è per questo che ho aperto nella sottosezione il thread "Diamonds knowledge" chiedendo di metterlo in rilievo.