Th3 Kn0wl3dg3
08-10-2007, 23:56
si certo, vi farò sapere come procede! grazie a tutti!!
View Full Version : Iniziare a programmare
Pagine :
1
[2]
^TiGeRShArK^
09-10-2007, 01:11
Uno parla di banane dicendo che non ci sono i semi e tu te ne vieni fuori affermando che "sì però c'è la buccia".
Praticamente TUTTA LA FRUTTA ha la buccia, quindi?
Quindi la tua osservazione è senza senso.
ultimo OT in questo thread GIURO!!! :D
però con tutto questo parlare di frutta a me viene da dire che mi piace la fi*a :O
(sia la buccia sia il contenuto :asd: )
:asd:
cmq tornando serio per un attimo.. (in effetti sto facendo uno sforzo incommensurabile x essere serio :D)
Secondo me vale sempre il classico (appena citato tra l'altro :D) "The right tool for the right job" :p
Per progetti di dimensioni medio-grandi (x la mia esperienze e x come vedo io i progetti medio grandi... ovvero sopra le 100k LOC) Java è meglio di python xkè già in compilazione evita di fare cazzate assurde con i tipi, xkè alla fine costringe a strutturare il progetto in una maniera ben ordinata (sopratutto usando tools come maven), xkè lo stile del codice può anche risultare migliore di quello di python usando gli strumenti giusti (ricordate il caro vecchio checkstyle che tanto mi ha fatto bestemmiare, vero? :asd: ) e sopratttto xkè alla fine x il supporto, la documentazione e l'aiuto disponibile alla comunità Java, soprattutto nel caso di bug critici in produzione non ha eguali confrontata con la comunità di python (sempre x quel poco che ho potuto vedere durante la mia esperienza :p).
Però, sempre per quello che ho vissuto finora, non avrei alcuna esitazione a consiglire python come linguaggio per iniziare a programmare...
Imho più un linguaggio è ad alto livello e + permette al programmatore di concentrarsi sugli algoritmi.
E alla fine, parlandoci chiaro, sono quelli la vera parte essenziale della programmazione.
Oltre alla forma mentis ovviamente :p
Un linguaggio che permette di concentrarsi sui concetti + che sulle righe di codice "inutili" permette di imparare meglio le cose necessarie.
L'unica pecca davvero grave che trovo in python è la mancanza di una documentazione adeguata :muro:
Cioè, a parte gli ottimi manuali utilizzati per apprendere le basi del linguaggio, poi ci si deve smenare davvero troppo per capire come funziona una maledetta libreria.
E a quel punto, sinceramente, preferisco scrivere + codice in java, mettendoci + tempo, ma impiegando sicuramente meno che per cercare di capire che cacchio voleva fare l'autore di quella libreria con la documentazione criptica :p
Concludendo...
il percorso ideale per me x iniziare sarebbe il seguente:
Python (o ruby o qualcosa di equivalente) --> Java --> all the rest :p
Praticamente TUTTA LA FRUTTA ha la buccia, quindi?
Quindi la tua osservazione è senza senso.
ultimo OT in questo thread GIURO!!! :D
però con tutto questo parlare di frutta a me viene da dire che mi piace la fi*a :O
(sia la buccia sia il contenuto :asd: )
:asd:
cmq tornando serio per un attimo.. (in effetti sto facendo uno sforzo incommensurabile x essere serio :D)
Secondo me vale sempre il classico (appena citato tra l'altro :D) "The right tool for the right job" :p
Per progetti di dimensioni medio-grandi (x la mia esperienze e x come vedo io i progetti medio grandi... ovvero sopra le 100k LOC) Java è meglio di python xkè già in compilazione evita di fare cazzate assurde con i tipi, xkè alla fine costringe a strutturare il progetto in una maniera ben ordinata (sopratutto usando tools come maven), xkè lo stile del codice può anche risultare migliore di quello di python usando gli strumenti giusti (ricordate il caro vecchio checkstyle che tanto mi ha fatto bestemmiare, vero? :asd: ) e sopratttto xkè alla fine x il supporto, la documentazione e l'aiuto disponibile alla comunità Java, soprattutto nel caso di bug critici in produzione non ha eguali confrontata con la comunità di python (sempre x quel poco che ho potuto vedere durante la mia esperienza :p).
Però, sempre per quello che ho vissuto finora, non avrei alcuna esitazione a consiglire python come linguaggio per iniziare a programmare...
Imho più un linguaggio è ad alto livello e + permette al programmatore di concentrarsi sugli algoritmi.
E alla fine, parlandoci chiaro, sono quelli la vera parte essenziale della programmazione.
Oltre alla forma mentis ovviamente :p
Un linguaggio che permette di concentrarsi sui concetti + che sulle righe di codice "inutili" permette di imparare meglio le cose necessarie.
L'unica pecca davvero grave che trovo in python è la mancanza di una documentazione adeguata :muro:
Cioè, a parte gli ottimi manuali utilizzati per apprendere le basi del linguaggio, poi ci si deve smenare davvero troppo per capire come funziona una maledetta libreria.
E a quel punto, sinceramente, preferisco scrivere + codice in java, mettendoci + tempo, ma impiegando sicuramente meno che per cercare di capire che cacchio voleva fare l'autore di quella libreria con la documentazione criptica :p
Concludendo...
il percorso ideale per me x iniziare sarebbe il seguente:
Python (o ruby o qualcosa di equivalente) --> Java --> all the rest :p
k0nt3
09-10-2007, 08:59
non sono daccordo sul fatto che più è alto il livello e meglio è.. anche in questo caso le motivazioni sono fragili.
i linguaggi come java, python ecc.. permettono di fare in maniera molto più semplice cose abbastanza complesse da fare in linguaggi come C e pascal per esempio. ma quando uno inizia a programmare tipicamente i suoi programmi fanno cose abbastanza stupide come calcolare le soluzioni di un'equazione di secondo grado, calcolare l'ipotenusa dati i due cateti, classificare i triangoli, implementare nibbles :asd: ecc..
da questo punto di vista C e pascal sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi e non sul colore della finestra, la disposizione dei pulsanti e altre inutilità varie. invece linguaggi come python e java ti sbattono in faccia sin dall'inizio concetti più avanzati come gli oggetti, le eccezioni ecc.. ovviamente IMHO
i linguaggi come java, python ecc.. permettono di fare in maniera molto più semplice cose abbastanza complesse da fare in linguaggi come C e pascal per esempio. ma quando uno inizia a programmare tipicamente i suoi programmi fanno cose abbastanza stupide come calcolare le soluzioni di un'equazione di secondo grado, calcolare l'ipotenusa dati i due cateti, classificare i triangoli, implementare nibbles :asd: ecc..
da questo punto di vista C e pascal sono semplicissimi da usare e ti permettono di introdurre solo i concetti strettamente necessari facendoti concentrare solamente sugli algoritmi e non sul colore della finestra, la disposizione dei pulsanti e altre inutilità varie. invece linguaggi come python e java ti sbattono in faccia sin dall'inizio concetti più avanzati come gli oggetti, le eccezioni ecc.. ovviamente IMHO
cdimauro
09-10-2007, 09:15
x ^TiGeRShArK^: http://www.hwupgrade.it/forum/showthread.php?p=19065068&posted=1#post19065068 :fiufiu:
cdimauro
09-10-2007, 09:30
x kont3: http://www.hwupgrade.it/forum/showthread.php?p=19065242&posted=1#post19065242 ;)
Nous
09-10-2007, 09:53
Ho 19 anni, quasi 20, e amo i computer e mi affascina tutto ciò che li riguarda. Vorrei iniziare a programmare ma per un niubbo come me in con tutti questi linguaggi non è facile. Con quale potrei iniziare considerando che comincio proprio da zero? Con Java, php, python, C......
Il mio consiglio è : il linguaggio passa, la metodologia resta.
Quindi studia la PROGETTAZIONE ad oggetti, l'UML e se ti incuriosisce dai un'occhio alle metodologie agili (XP), magari dopo aver visto waterfall o RUP.
Studia un pò di pattern, e poi il linguaggio sceglilo in base alle tue preferenze... un oggetto è un oggetto, che venga istanziato in C#, Java o Python.
Io personalmente Python lo detesto, le indentazioni mi sono odiose.
Il mio consiglio è : il linguaggio passa, la metodologia resta.
Quindi studia la PROGETTAZIONE ad oggetti, l'UML e se ti incuriosisce dai un'occhio alle metodologie agili (XP), magari dopo aver visto waterfall o RUP.
Studia un pò di pattern, e poi il linguaggio sceglilo in base alle tue preferenze... un oggetto è un oggetto, che venga istanziato in C#, Java o Python.
Io personalmente Python lo detesto, le indentazioni mi sono odiose.
cdimauro
09-10-2007, 10:15
De gustibus.
Io detesto l'UML, invece, che trovo del tutto inutile. Molto meglio costruirsi un modello in Python in poco tempo che perdere tempo in diagrammi che non rappresentano nulla (e che si possono tirare fuori a partire dal sorgente, con appositi tool).
Io detesto l'UML, invece, che trovo del tutto inutile. Molto meglio costruirsi un modello in Python in poco tempo che perdere tempo in diagrammi che non rappresentano nulla (e che si possono tirare fuori a partire dal sorgente, con appositi tool).
Nous
09-10-2007, 10:25
De gustibus.
Io detesto l'UML, invece, che trovo del tutto inutile. Molto meglio costruirsi un modello in Python in poco tempo che perdere tempo in diagrammi che non rappresentano nulla (e che si possono tirare fuori a partire dal sorgente, con appositi tool).
Beh, se l'UML lo generi dai sorgenti, lo generi come documentazione di quanto hai fatto..se lo generi prima, è un progetto di quello che dovrai fare.
La differenza è palese : invece di buttare giù classi senza costrutto, ti prendi una mezza giornate per pensare a come fare le cose. Per mia esperienza, una volta che l'UML funziona la scrittura del codice è una cosa banale, tant'è che spesso la faccio fare ad altri sulla mia progettazione. Inoltre, se progetti hai un riscontro visivo dei problemi (alto accoppiamento, bassa coesione, etc. etc.), mentre se scrivi e poi generi l'UML hai solo una documentazione degli errori che hai già compiuto, la cui soluzione a quel punto richiede più tempo rispetto a quello della progettazione. In altre parole, fossi in te mi abituerei a progettare ;)
Io detesto l'UML, invece, che trovo del tutto inutile. Molto meglio costruirsi un modello in Python in poco tempo che perdere tempo in diagrammi che non rappresentano nulla (e che si possono tirare fuori a partire dal sorgente, con appositi tool).
Beh, se l'UML lo generi dai sorgenti, lo generi come documentazione di quanto hai fatto..se lo generi prima, è un progetto di quello che dovrai fare.
La differenza è palese : invece di buttare giù classi senza costrutto, ti prendi una mezza giornate per pensare a come fare le cose. Per mia esperienza, una volta che l'UML funziona la scrittura del codice è una cosa banale, tant'è che spesso la faccio fare ad altri sulla mia progettazione. Inoltre, se progetti hai un riscontro visivo dei problemi (alto accoppiamento, bassa coesione, etc. etc.), mentre se scrivi e poi generi l'UML hai solo una documentazione degli errori che hai già compiuto, la cui soluzione a quel punto richiede più tempo rispetto a quello della progettazione. In altre parole, fossi in te mi abituerei a progettare ;)
mad_hhatter
09-10-2007, 10:35
De gustibus.
Io detesto l'UML, invece, che trovo del tutto inutile. Molto meglio costruirsi un modello in Python in poco tempo che perdere tempo in diagrammi che non rappresentano nulla (e che si possono tirare fuori a partire dal sorgente, con appositi tool).
prima regola del buon programmatore: prima di scrivere una sola riga di codice, pensa bene a ciò che fai...
non tutti i formalismi vanno bene ovunque, ma il buttarsi subito sul codice secondo me è sbagliato... all'inizio va anche bene, tanto gli esercizi sono dei piccoli giocattoli, ma se si cresce con questo modo di fare, quando si avrà a che fare con progetti complessi si aprtirà col piede sbagliato... non è necessario formalizzare il progetto della soluzione, ma analizzare bene il problema e le sue soluzioni PRIMA di scrivere codice è indispensabile: la soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
Io detesto l'UML, invece, che trovo del tutto inutile. Molto meglio costruirsi un modello in Python in poco tempo che perdere tempo in diagrammi che non rappresentano nulla (e che si possono tirare fuori a partire dal sorgente, con appositi tool).
prima regola del buon programmatore: prima di scrivere una sola riga di codice, pensa bene a ciò che fai...
non tutti i formalismi vanno bene ovunque, ma il buttarsi subito sul codice secondo me è sbagliato... all'inizio va anche bene, tanto gli esercizi sono dei piccoli giocattoli, ma se si cresce con questo modo di fare, quando si avrà a che fare con progetti complessi si aprtirà col piede sbagliato... non è necessario formalizzare il progetto della soluzione, ma analizzare bene il problema e le sue soluzioni PRIMA di scrivere codice è indispensabile: la soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
cdimauro
09-10-2007, 12:07
Beh, se l'UML lo generi dai sorgenti, lo generi come documentazione di quanto hai fatto..se lo generi prima, è un progetto di quello che dovrai fare.
Sì, eventualmente lo uso soltanto per la documentazione.
Per il progetto preferisco iniziare a lavorarci quanto prima partendo dalle specifiche.
La differenza è palese : invece di buttare giù classi senza costrutto, ti prendi una mezza giornate per pensare a come fare le cose.
Lo faccio già. Guru meditation. :D
La differenza è che poi non mi butto sull'UML, ma sul codice. ;)
Per mia esperienza, una volta che l'UML funziona la scrittura del codice è una cosa banale, tant'è che spesso la faccio fare ad altri sulla mia progettazione. Inoltre, se progetti hai un riscontro visivo dei problemi (alto accoppiamento, bassa coesione, etc. etc.), mentre se scrivi e poi generi l'UML hai solo una documentazione degli errori che hai già compiuto, la cui soluzione a quel punto richiede più tempo rispetto a quello della progettazione. In altre parole, fossi in te mi abituerei a progettare ;)
Assolutamente no. La differenza fra UML e scrittura immediata del codice dopo 15 giorni è che nel primo caso al cliente posso presentare dei disegnini e la sua espressione sarà "ah, va bene, sì, ok.... ma... quando prevedi di farmi vedere qualcosa?", mentre nel secondo caso sarà "Ah. Interessante, quindi questo funziona così, questo colì. Bene, bene, il progetto sta andando avanti velocemente. Sono contento".
UML = roba inutile. A maggior ragione quando le specifiche sono soggette a continue variazioni in corso d'opera, come capita normalmente e frequentissimamente nel campo dell'informatica.
Per questo preferisco scrivere codice "minimale" e "prototipale", da far evolvere fino al completamento del progetto.
La programmazione è per definizione un processo iterativo.
L'UML lo userei soltanto per progetti CRITICI (come un pacemaker, ad esempio, per cui bisogna costruire un'accurata analisi di tutti i casi, i domini delle funzioni, ecc. ecc., perché in gioco c'è la vita di una persona) e le cui specifiche sono sostanzialmente statiche / stabili.
Sì, eventualmente lo uso soltanto per la documentazione.
Per il progetto preferisco iniziare a lavorarci quanto prima partendo dalle specifiche.
La differenza è palese : invece di buttare giù classi senza costrutto, ti prendi una mezza giornate per pensare a come fare le cose.
Lo faccio già. Guru meditation. :D
La differenza è che poi non mi butto sull'UML, ma sul codice. ;)
Per mia esperienza, una volta che l'UML funziona la scrittura del codice è una cosa banale, tant'è che spesso la faccio fare ad altri sulla mia progettazione. Inoltre, se progetti hai un riscontro visivo dei problemi (alto accoppiamento, bassa coesione, etc. etc.), mentre se scrivi e poi generi l'UML hai solo una documentazione degli errori che hai già compiuto, la cui soluzione a quel punto richiede più tempo rispetto a quello della progettazione. In altre parole, fossi in te mi abituerei a progettare ;)
Assolutamente no. La differenza fra UML e scrittura immediata del codice dopo 15 giorni è che nel primo caso al cliente posso presentare dei disegnini e la sua espressione sarà "ah, va bene, sì, ok.... ma... quando prevedi di farmi vedere qualcosa?", mentre nel secondo caso sarà "Ah. Interessante, quindi questo funziona così, questo colì. Bene, bene, il progetto sta andando avanti velocemente. Sono contento".
UML = roba inutile. A maggior ragione quando le specifiche sono soggette a continue variazioni in corso d'opera, come capita normalmente e frequentissimamente nel campo dell'informatica.
Per questo preferisco scrivere codice "minimale" e "prototipale", da far evolvere fino al completamento del progetto.
La programmazione è per definizione un processo iterativo.
L'UML lo userei soltanto per progetti CRITICI (come un pacemaker, ad esempio, per cui bisogna costruire un'accurata analisi di tutti i casi, i domini delle funzioni, ecc. ecc., perché in gioco c'è la vita di una persona) e le cui specifiche sono sostanzialmente statiche / stabili.
cdimauro
09-10-2007, 12:13
prima regola del buon programmatore: prima di scrivere una sola riga di codice, pensa bene a ciò che fai...
Chiaro.
non tutti i formalismi vanno bene ovunque, ma il buttarsi subito sul codice secondo me è sbagliato... all'inizio va anche bene, tanto gli esercizi sono dei piccoli giocattoli, ma se si cresce con questo modo di fare, quando si avrà a che fare con progetti complessi si aprtirà col piede sbagliato... non è necessario formalizzare il progetto della soluzione, ma analizzare bene il problema e le sue soluzioni PRIMA di scrivere codice è indispensabile:
Vedi il mio messaggio a Nous.
la soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
La rifattorizzazione del codice è un processo naturale. SE serve.
Innanzitutto un buon programmatore ha un obiettivo fondamentale: ottenere la soluzione al suo problema. Il prima possibile, ovviamente. Per questo realizzare velocemente un prototipo è estremamente importante.
Una volta ottenuto il prototipo si può poi pensare di "affinarlo" in base ai risultati dei test, facendo uso di dati reali e/o appositamente preparati. Chiaramente i cambiamenti vanno fatti se e solo se se ne presenterà oggettivamente la necessità.
Tirare fuori un diagramma UML non ti dà alcun modello concreto con cui poter lavorare: sarà pure un progetto bellissimo, ma sempre sulla carta rimarrà.
Chiaro.
non tutti i formalismi vanno bene ovunque, ma il buttarsi subito sul codice secondo me è sbagliato... all'inizio va anche bene, tanto gli esercizi sono dei piccoli giocattoli, ma se si cresce con questo modo di fare, quando si avrà a che fare con progetti complessi si aprtirà col piede sbagliato... non è necessario formalizzare il progetto della soluzione, ma analizzare bene il problema e le sue soluzioni PRIMA di scrivere codice è indispensabile:
Vedi il mio messaggio a Nous.
la soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
La rifattorizzazione del codice è un processo naturale. SE serve.
Innanzitutto un buon programmatore ha un obiettivo fondamentale: ottenere la soluzione al suo problema. Il prima possibile, ovviamente. Per questo realizzare velocemente un prototipo è estremamente importante.
Una volta ottenuto il prototipo si può poi pensare di "affinarlo" in base ai risultati dei test, facendo uso di dati reali e/o appositamente preparati. Chiaramente i cambiamenti vanno fatti se e solo se se ne presenterà oggettivamente la necessità.
Tirare fuori un diagramma UML non ti dà alcun modello concreto con cui poter lavorare: sarà pure un progetto bellissimo, ma sempre sulla carta rimarrà.
Nous
09-10-2007, 12:18
Assolutamente no. La differenza fra UML e scrittura immediata del codice dopo 15 giorni è che nel primo caso al cliente posso presentare dei disegnini e la sua espressione sarà "ah, va bene, sì, ok.... ma... quando prevedi di farmi vedere qualcosa?", mentre nel secondo caso sarà "Ah. Interessante, quindi questo funziona così, questo colì. Bene, bene, il progetto sta andando avanti velocemente. Sono contento".
Uhmm..ma chi ci mette 15 giorni a fare una serie di diagrammi UML? Siamo seri, suvvia..un diagramma delle classi ti prende al massimo una giornata, senza scendere troppo nel dettaglio...serve "solo" a definire gli oggetti e le relazioni tra gli oggetti (ho usato apposta la definizione di programmazione ad oggetti ;))
UML = roba inutile. A maggior ragione quando le specifiche sono soggette a continue variazioni in corso d'opera, come capita normalmente e frequentissimamente nel campo dell'informatica.
Per questo preferisco scrivere codice "minimale" e "prototipale", da far evolvere fino al completamento del progetto.
La programmazione è per definizione un processo iterativo.
Vedrai il giorno in cui dovrai rimettere mano ad un sistema sviluppato 3 anni fa, come l'UML sarà stato inutile :)
Certo che le specifiche cambiano, le architetture cambiano...nelle iterazioni aggiungi sempre una revisione della progettazione, vedrai che non potrai che ottenere un lavoro migliore.
L'UML lo userei soltanto per progetti CRITICI (come un pacemaker, ad esempio, per cui bisogna costruire un'accurata analisi di tutti i casi, i domini delle funzioni, ecc. ecc., perché in gioco c'è la vita di una persona) e le cui specifiche sono sostanzialmente statiche / stabili.
In altre parole la qualità del tuo lavoro dipende dal contesto in cui lavori?
Per me no, l'UML lo faccio anche per un banalissimo programma che magari sviluppo a casa e poi regalo.
Uhmm..ma chi ci mette 15 giorni a fare una serie di diagrammi UML? Siamo seri, suvvia..un diagramma delle classi ti prende al massimo una giornata, senza scendere troppo nel dettaglio...serve "solo" a definire gli oggetti e le relazioni tra gli oggetti (ho usato apposta la definizione di programmazione ad oggetti ;))
UML = roba inutile. A maggior ragione quando le specifiche sono soggette a continue variazioni in corso d'opera, come capita normalmente e frequentissimamente nel campo dell'informatica.
Per questo preferisco scrivere codice "minimale" e "prototipale", da far evolvere fino al completamento del progetto.
La programmazione è per definizione un processo iterativo.
Vedrai il giorno in cui dovrai rimettere mano ad un sistema sviluppato 3 anni fa, come l'UML sarà stato inutile :)
Certo che le specifiche cambiano, le architetture cambiano...nelle iterazioni aggiungi sempre una revisione della progettazione, vedrai che non potrai che ottenere un lavoro migliore.
L'UML lo userei soltanto per progetti CRITICI (come un pacemaker, ad esempio, per cui bisogna costruire un'accurata analisi di tutti i casi, i domini delle funzioni, ecc. ecc., perché in gioco c'è la vita di una persona) e le cui specifiche sono sostanzialmente statiche / stabili.
In altre parole la qualità del tuo lavoro dipende dal contesto in cui lavori?
Per me no, l'UML lo faccio anche per un banalissimo programma che magari sviluppo a casa e poi regalo.
cdimauro
09-10-2007, 12:47
Uhmm..ma chi ci mette 15 giorni a fare una serie di diagrammi UML? Siamo seri, suvvia..un diagramma delle classi ti prende al massimo una giornata, senza scendere troppo nel dettaglio...serve "solo" a definire gli oggetti e le relazioni tra gli oggetti (ho usato apposta la definizione di programmazione ad oggetti ;))
Se, come si diceva prima, si parla di progetti non banali, non credo che sia necessario un giorno per completare un diagramma delle classi.
Vedrai il giorno in cui dovrai rimettere mano ad un sistema sviluppato 3 anni fa, come l'UML sarà stato inutile :)
Certo che le specifiche cambiano, le architetture cambiano...nelle iterazioni aggiungi sempre una revisione della progettazione, vedrai che non potrai che ottenere un lavoro migliore.
Sono 26 anni che programmo, con l'UML c'ho lavorato (e studiato) all'università, e ho accumulato abbastanza esperienza per affermare quanto ho scritto prima. ;)
Per quanto mi riguarda l'UML è da relegare ai casi particolari che ho descritto.
In tutti gli altri casi preferisco di gran lunga la metodologia "agile": http://it.wikipedia.org/wiki/Metodologia_agile che si presta a ottenere risultati concreti in meno tempo, riducendo al minimo il rischio di fallimento del progetto (particolarmente elevato se lavorassi come suggerisci tu).
In altre parole la qualità del tuo lavoro dipende dal contesto in cui lavori?
Per me no, l'UML lo faccio anche per un banalissimo programma che magari sviluppo a casa e poi regalo.
Sì, dipende sempre dal contesto. Finora fortunatamente non m'è mai capitato di lavorare a uno dei rari casi in cui serve formalizzare del tutto il modello del progetto prima di metter mani al codice, e sono decisamente più produttivo...
Se, come si diceva prima, si parla di progetti non banali, non credo che sia necessario un giorno per completare un diagramma delle classi.
Vedrai il giorno in cui dovrai rimettere mano ad un sistema sviluppato 3 anni fa, come l'UML sarà stato inutile :)
Certo che le specifiche cambiano, le architetture cambiano...nelle iterazioni aggiungi sempre una revisione della progettazione, vedrai che non potrai che ottenere un lavoro migliore.
Sono 26 anni che programmo, con l'UML c'ho lavorato (e studiato) all'università, e ho accumulato abbastanza esperienza per affermare quanto ho scritto prima. ;)
Per quanto mi riguarda l'UML è da relegare ai casi particolari che ho descritto.
In tutti gli altri casi preferisco di gran lunga la metodologia "agile": http://it.wikipedia.org/wiki/Metodologia_agile che si presta a ottenere risultati concreti in meno tempo, riducendo al minimo il rischio di fallimento del progetto (particolarmente elevato se lavorassi come suggerisci tu).
In altre parole la qualità del tuo lavoro dipende dal contesto in cui lavori?
Per me no, l'UML lo faccio anche per un banalissimo programma che magari sviluppo a casa e poi regalo.
Sì, dipende sempre dal contesto. Finora fortunatamente non m'è mai capitato di lavorare a uno dei rari casi in cui serve formalizzare del tutto il modello del progetto prima di metter mani al codice, e sono decisamente più produttivo...
Nous
09-10-2007, 13:01
In tutti gli altri casi preferisco di gran lunga la metodologia "agile": http://it.wikipedia.org/wiki/Metodologia_agile che si presta a ottenere risultati concreti in meno tempo, riducendo al minimo il rischio di fallimento del progetto (particolarmente elevato se lavorassi come suggerisci tu).
Avevo capito, infatti ho scritto ad ogni iterazione di mettere mano al progetto ;)
Sono un seguace dell'XP da un pò di anni, ho conosciuto molti dei guru di XP e qualcuno fa come dico io (qualcuno no)...alcuni li ho conosciuti in conferenze, altri andandoli a trovare nelle loro aziende, altri su ML...conosco molti dell'XPGroup di Milano :)
Non ho mai scritto di fare tutto il progetto fino al minimo dettaglio...però anche a voler gestire il cambiamento, l'improvvisazione non fa mai bene.
Decidiamo l'architettura, i packages, le classi (chi fa cosa)...dopodichè il cambiamento è o una modifica della funzionalità (e allora il progetto va bene, cambia l'algoritmo interno ma non l'interfaccia della classe) oppure un'aggiunta /rimozione di una funzionalità...e allora o rimuovo la classe/package corrispondente (e dal progetto vedo subito gli accoppiamenti e le dipendenze con le altre classi, così posso prevenire il propagarsi di regressioni o di errori) o ne aggiungo, e dal progetto vedo subito dove aggiungerla.
My two cents ;)
Avevo capito, infatti ho scritto ad ogni iterazione di mettere mano al progetto ;)
Sono un seguace dell'XP da un pò di anni, ho conosciuto molti dei guru di XP e qualcuno fa come dico io (qualcuno no)...alcuni li ho conosciuti in conferenze, altri andandoli a trovare nelle loro aziende, altri su ML...conosco molti dell'XPGroup di Milano :)
Non ho mai scritto di fare tutto il progetto fino al minimo dettaglio...però anche a voler gestire il cambiamento, l'improvvisazione non fa mai bene.
Decidiamo l'architettura, i packages, le classi (chi fa cosa)...dopodichè il cambiamento è o una modifica della funzionalità (e allora il progetto va bene, cambia l'algoritmo interno ma non l'interfaccia della classe) oppure un'aggiunta /rimozione di una funzionalità...e allora o rimuovo la classe/package corrispondente (e dal progetto vedo subito gli accoppiamenti e le dipendenze con le altre classi, così posso prevenire il propagarsi di regressioni o di errori) o ne aggiungo, e dal progetto vedo subito dove aggiungerla.
My two cents ;)
cdimauro
09-10-2007, 13:48
Non è questione di improvvisazione: un programmatore deve trovare la soluzione al problema in base ai requisiti attuali, e con l'idea (e la pratica) che cambiano spesso non può permettersi di progettare classi, package, etc. in ottica "stabile" o, peggio ancora, "futura" ("questo lo aggiungo perché mi potrà servire").
Diciamo che fin dall'inizio si progetta "il minimo indispensabile", e col tempo lo si fa evolvere; è il processo iterativo di cui parlavi anche tu.
Improvvisare ha un senso di negatività che, IMHO, non si confà al lavoro di un professionista.
Quanto all'affrontare i cambiamenti, hai esposto il tuo punto di vista che è apprezzabile, sì, ma non "oggettivo": è il risultato della tua esperienza, che però è abbastanza diversa dalla mia (ad esempio le dipendenze e gli accoppiamenti preferisco renderli sotto forma di test).
Diciamo che fin dall'inizio si progetta "il minimo indispensabile", e col tempo lo si fa evolvere; è il processo iterativo di cui parlavi anche tu.
Improvvisare ha un senso di negatività che, IMHO, non si confà al lavoro di un professionista.
Quanto all'affrontare i cambiamenti, hai esposto il tuo punto di vista che è apprezzabile, sì, ma non "oggettivo": è il risultato della tua esperienza, che però è abbastanza diversa dalla mia (ad esempio le dipendenze e gli accoppiamenti preferisco renderli sotto forma di test).
Nous
09-10-2007, 13:53
(ad esempio le dipendenze e gli accoppiamenti preferisco renderli sotto forma di test).
I test sono un must, unitario e funzionali...ma non è che ti danno un'idea della complessità ciclomatrica del codice, o del rispetto dei pattern alta coesione - basso accoppiamento (ad esempio) ;)
Cmq ok, abbiamo due idee diverse dello stesso mestiere :)
I test sono un must, unitario e funzionali...ma non è che ti danno un'idea della complessità ciclomatrica del codice, o del rispetto dei pattern alta coesione - basso accoppiamento (ad esempio) ;)
Cmq ok, abbiamo due idee diverse dello stesso mestiere :)
cdimauro
09-10-2007, 14:01
Per il calcolo della complessità ciclomatica esistono apposti strumenti (comunque anche la vista è uno di questi :D).
Per il calcolo del livello di accoppiamento / coesione, non so. Qui vado "a naso", in base alla mia esperienza.
Comunque, sì, abbiamo idee abbastanza diverse. :p
Per il calcolo del livello di accoppiamento / coesione, non so. Qui vado "a naso", in base alla mia esperienza.
Comunque, sì, abbiamo idee abbastanza diverse. :p
mad_hhatter
09-10-2007, 15:01
non puoi nemmeno lavorare solo con i requisiti attuali: devi tener conto di dove sono probabili variazioni e progettare il tutto per minimizzarne gli effetti... con una visione globale, magari grafica, hai un'idea migliore rispetto al quadro offerto dal solo codice
inoltre la comunicazione con il team non la puoi veicolare solo attraverso il codice, altrimenti i colleghi devono perdersi in dettagli trascurabili a seconda della prospettiva
inoltre, come diceva Nous, se riprendi in mano codice vecchio diventi matto senza uno schema progettuale (non importa che sia in UML).
inoltre la comunicazione con il team non la puoi veicolare solo attraverso il codice, altrimenti i colleghi devono perdersi in dettagli trascurabili a seconda della prospettiva
inoltre, come diceva Nous, se riprendi in mano codice vecchio diventi matto senza uno schema progettuale (non importa che sia in UML).
cdimauro
09-10-2007, 15:17
Leggiti il link che ho postato prima sulla metodologia agile.
Per il resto, se mi serve una visione globale i diagrammi UML li posso tirare fuori al volo dal codice, con la certezza che saranno perfettamente aggiornati col codice attuale.
Quanto ai progetti vecchi, se sono stati scritti bene si possono riprendere in mano in qualunque momento. Casualmente m'è capitato di farlo con un'applicazione Delphi in questo periodo, che non toccavo più dai primi del 2004.
Per il resto, se mi serve una visione globale i diagrammi UML li posso tirare fuori al volo dal codice, con la certezza che saranno perfettamente aggiornati col codice attuale.
Quanto ai progetti vecchi, se sono stati scritti bene si possono riprendere in mano in qualunque momento. Casualmente m'è capitato di farlo con un'applicazione Delphi in questo periodo, che non toccavo più dai primi del 2004.
^TiGeRShArK^
09-10-2007, 17:08
La soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
Ma il refactoring infatti VA fatto.
Nessuna progettazione può prevedere tutti i casi, e solo a mano a mano che si approfondisce il problema scrivendo codice si visualizzeranno i limiti della nostra progettazione.
D'altronde è inutile aggiungere tutte le features possibili e analizzare migliaia di casi che probabilmente non ci serviranno mai se invece si fa molto prima a scrivere il minimo codice funzionante e poi ad aggiungere funzionalità quando realemente servono.
E in quest'ottica il refactoring è assolutamente imprescindibile.
Inoltre è anche necessario per aumentare la leggibilità e la qualità del codice, dato che per quanto l'applicazione possa essere progettata perfettamente (cosa tra l'altro impossibile praticamente visto il continuo mutare dei requisiti, le difficoltà di comunicazione tra gli esseri umani e quant'altro), alla fine il codice migliore non sarà mai quello scritto la prima volta.
Invece tramite continui rimaneggiamenti e refactoring il codice raggiungerà la sua forma migliore e non farà bestemmiare in una lingua morta a scelta tutti gli altri componenti del team. :D
Ma il refactoring infatti VA fatto.
Nessuna progettazione può prevedere tutti i casi, e solo a mano a mano che si approfondisce il problema scrivendo codice si visualizzeranno i limiti della nostra progettazione.
D'altronde è inutile aggiungere tutte le features possibili e analizzare migliaia di casi che probabilmente non ci serviranno mai se invece si fa molto prima a scrivere il minimo codice funzionante e poi ad aggiungere funzionalità quando realemente servono.
E in quest'ottica il refactoring è assolutamente imprescindibile.
Inoltre è anche necessario per aumentare la leggibilità e la qualità del codice, dato che per quanto l'applicazione possa essere progettata perfettamente (cosa tra l'altro impossibile praticamente visto il continuo mutare dei requisiti, le difficoltà di comunicazione tra gli esseri umani e quant'altro), alla fine il codice migliore non sarà mai quello scritto la prima volta.
Invece tramite continui rimaneggiamenti e refactoring il codice raggiungerà la sua forma migliore e non farà bestemmiare in una lingua morta a scelta tutti gli altri componenti del team. :D
^TiGeRShArK^
09-10-2007, 17:13
Vedrai il giorno in cui dovrai rimettere mano ad un sistema sviluppato 3 anni fa, come l'UML sarà stato inutile :)
Certo che le specifiche cambiano, le architetture cambiano...nelle iterazioni aggiungi sempre una revisione della progettazione, vedrai che non potrai che ottenere un lavoro migliore.
In altre parole la qualità del tuo lavoro dipende dal contesto in cui lavori?
Per me no, l'UML lo faccio anche per un banalissimo programma che magari sviluppo a casa e poi regalo.
E in quel caso si potrebbe benissimo generare l'UML dal codice se proprio se ne sente la mancanza.
Io dal canto mio mi trovo ottimamente con gli strumenti di navigazione e visualizzazione del codice forniti da eclipse che mi hanno permesso di essere operativo in brevissimo tempo su una codebase davvero enorme.
Avessi divuto perdere tempo a studiarmi tutti i diagrammi UML (ovviamente presenti nell'apposito repository :p) probabilmente starei ancora lì a bestemmiare cercando di capirci qualcosa :D
Cmq ovviamente in taluni casi l'UML facilita il compito, e infatti quando tramite l'analisi del codice, mi serviva in fretta una sintesi di determinate relazioni tra oggetti andavo a guardare i diagrami.
Ma di certo in generale è bene sporcarsi le mani sul codice e capire in maniera MOLTO + approfondita come funzionano i vari oggetti piuttosto che limitarsi ad un superficiale sguardo all'UML :p
Certo che le specifiche cambiano, le architetture cambiano...nelle iterazioni aggiungi sempre una revisione della progettazione, vedrai che non potrai che ottenere un lavoro migliore.
In altre parole la qualità del tuo lavoro dipende dal contesto in cui lavori?
Per me no, l'UML lo faccio anche per un banalissimo programma che magari sviluppo a casa e poi regalo.
E in quel caso si potrebbe benissimo generare l'UML dal codice se proprio se ne sente la mancanza.
Io dal canto mio mi trovo ottimamente con gli strumenti di navigazione e visualizzazione del codice forniti da eclipse che mi hanno permesso di essere operativo in brevissimo tempo su una codebase davvero enorme.
Avessi divuto perdere tempo a studiarmi tutti i diagrammi UML (ovviamente presenti nell'apposito repository :p) probabilmente starei ancora lì a bestemmiare cercando di capirci qualcosa :D
Cmq ovviamente in taluni casi l'UML facilita il compito, e infatti quando tramite l'analisi del codice, mi serviva in fretta una sintesi di determinate relazioni tra oggetti andavo a guardare i diagrami.
Ma di certo in generale è bene sporcarsi le mani sul codice e capire in maniera MOLTO + approfondita come funzionano i vari oggetti piuttosto che limitarsi ad un superficiale sguardo all'UML :p
Nous
09-10-2007, 17:18
Ma il refactoring infatti VA fatto.
[CUT]
Ragazzi, quando dico che seguo le metodologie agili dico che per me Testing e Refactoring sono imprescindibili. Semplicemente, l'XP ha il difetto che rende agili a discapito della documentazione di progetto, cosa assolutamente non piacevole per le grosse aziende che di documentazione ci vivono. I processi sono incrementali, ma se al processo standard si aggiunge una cosa che ci serve non è che non si fa più XP....il refactoring è indispensabile, la progettazione attenta (non maniacale, attenta) lo rende circoscritto all'algoritmo e non all'architettura...il vantaggio è enorme, perchè nel codice ad oggetti gli algoritmi sono comunque semplici rispetto ad un programma procedurale. La documentazione che mi danno gli unit test, le interfaccie, la JavaDoc (o chi per essa) non basta a garantirmi tranquillità durante il processo, specie se il progetto cresce molto nel tempo ed è diviso tra teams diversi per aree di competenza. Non posso portare in una riunione gli unit test, dirgli che le luci sono verdi quindi tutto funziona...poi ok, l'UML non vi piace pazienza...fare i CRC, fate uno schizzo su un tovagliolo di carta...
[CUT]
Ragazzi, quando dico che seguo le metodologie agili dico che per me Testing e Refactoring sono imprescindibili. Semplicemente, l'XP ha il difetto che rende agili a discapito della documentazione di progetto, cosa assolutamente non piacevole per le grosse aziende che di documentazione ci vivono. I processi sono incrementali, ma se al processo standard si aggiunge una cosa che ci serve non è che non si fa più XP....il refactoring è indispensabile, la progettazione attenta (non maniacale, attenta) lo rende circoscritto all'algoritmo e non all'architettura...il vantaggio è enorme, perchè nel codice ad oggetti gli algoritmi sono comunque semplici rispetto ad un programma procedurale. La documentazione che mi danno gli unit test, le interfaccie, la JavaDoc (o chi per essa) non basta a garantirmi tranquillità durante il processo, specie se il progetto cresce molto nel tempo ed è diviso tra teams diversi per aree di competenza. Non posso portare in una riunione gli unit test, dirgli che le luci sono verdi quindi tutto funziona...poi ok, l'UML non vi piace pazienza...fare i CRC, fate uno schizzo su un tovagliolo di carta...
Nous
09-10-2007, 17:20
Avessi divuto perdere tempo a studiarmi tutti i diagrammi UML (ovviamente presenti nell'apposito repository :p) probabilmente starei ancora lì a bestemmiare cercando di capirci qualcosa :D
Se per te è una perdita di tempo...ma programmare ad oggetti senza progettare ad oggetti per me è un errore.
Ma di certo in generale è bene sporcarsi le mani sul codice e capire in maniera MOLTO + approfondita come funzionano i vari oggetti piuttosto che limitarsi ad un superficiale sguardo all'UML :p
Stai scherzando ??????
Programmazione procedurare = algoritmi e strutture dati.
Programmazione ad oggetti = oggetti ed interazioni tra oggetti
Tu mi stai dicendo che ti butti sull'algoritmica invece che sulle interazioni tra oggetti...è gravissimo, per me.
Se per te è una perdita di tempo...ma programmare ad oggetti senza progettare ad oggetti per me è un errore.
Ma di certo in generale è bene sporcarsi le mani sul codice e capire in maniera MOLTO + approfondita come funzionano i vari oggetti piuttosto che limitarsi ad un superficiale sguardo all'UML :p
Stai scherzando ??????
Programmazione procedurare = algoritmi e strutture dati.
Programmazione ad oggetti = oggetti ed interazioni tra oggetti
Tu mi stai dicendo che ti butti sull'algoritmica invece che sulle interazioni tra oggetti...è gravissimo, per me.
^TiGeRShArK^
09-10-2007, 17:24
non puoi nemmeno lavorare solo con i requisiti attuali: devi tener conto di dove sono probabili variazioni e progettare il tutto per minimizzarne gli effetti... con una visione globale, magari grafica, hai un'idea migliore rispetto al quadro offerto dal solo codice
è umanamente impossibile tenere conto di TUTTI gli aspetti che si dovranno affrontare (a meno di contesti particolari ovviamente).
Puoi progettare una casa in questa maniera dato che le sue specifiche sono per definizione immutabili, ma per un software, il cui processo di creazione è per definizione dinamico e deve adattarsi agli sbalzi d'umore del committente tentare di considerare tutti i possibli casi non si traduce in altro che in una perdita di tempo e anzi addirittura potrebbe risultare dannoso perchè si sono fatte ipotesi molto forti in uno stadio in cui ancora non si è affrontato il problema nel dettaglio ma solo in generale.
In questo modo è possibile addirittura ritrovarsi ad imboccare una strada senza uscita perchè anzikè mettere le mani sul codice e sbattere la testa contro i problemi si è preferito affidarsi a supposizioni e teorie che in prima istanza sembravano la cosa è corretta del mondo, ma che in pratica non risultano essere così ottimali come si pensava in quel momento.
Invece l'esplorazione pratica delle varie soluzioni tramite spike o prototipi o chiamateli come vi pare, tende ovviamente a minimizzare questi problemi dato che is possono saggiare quali siano nella realtà i problemi da affrontare nelle varie scelte disponibili.
inoltre la comunicazione con il team non la puoi veicolare solo attraverso il codice, altrimenti i colleghi devono perdersi in dettagli trascurabili a seconda della prospettiva
Questo è sostanzialmente vero, ma come sempre dipende dalla prospettiva.
Se si ha bisogno solo di comunicare in generale l'architettura allora il codice diventa superfluo e i diagrammi UML svolgono benissimo il loro lavoro, però se invece bisogna scegliere nel dettaglio io preferisco molto di + un codice scritto con i sacri crismi ma senza uno straccio di UML che lo documenti (che ricordo è sempre possibile generale quando si vuole) rispetto ad un codice perfettamente documentato con tanto di documenti di raccolta dei requisiti, di analisi, di diagrammi UML ma che poi è stato scritto con i piedi perchè si sono dovuti fare i salti mortali per consegnare in tempo il progetto vista l'enorme quantità di tempo dedicata a quelle prime fasi (e ovviamente tralasciamo il testing che spesso, nella migliore delle ipotesi, viene fatto con i piedi :muro: ).
è umanamente impossibile tenere conto di TUTTI gli aspetti che si dovranno affrontare (a meno di contesti particolari ovviamente).
Puoi progettare una casa in questa maniera dato che le sue specifiche sono per definizione immutabili, ma per un software, il cui processo di creazione è per definizione dinamico e deve adattarsi agli sbalzi d'umore del committente tentare di considerare tutti i possibli casi non si traduce in altro che in una perdita di tempo e anzi addirittura potrebbe risultare dannoso perchè si sono fatte ipotesi molto forti in uno stadio in cui ancora non si è affrontato il problema nel dettaglio ma solo in generale.
In questo modo è possibile addirittura ritrovarsi ad imboccare una strada senza uscita perchè anzikè mettere le mani sul codice e sbattere la testa contro i problemi si è preferito affidarsi a supposizioni e teorie che in prima istanza sembravano la cosa è corretta del mondo, ma che in pratica non risultano essere così ottimali come si pensava in quel momento.
Invece l'esplorazione pratica delle varie soluzioni tramite spike o prototipi o chiamateli come vi pare, tende ovviamente a minimizzare questi problemi dato che is possono saggiare quali siano nella realtà i problemi da affrontare nelle varie scelte disponibili.
inoltre la comunicazione con il team non la puoi veicolare solo attraverso il codice, altrimenti i colleghi devono perdersi in dettagli trascurabili a seconda della prospettiva
Questo è sostanzialmente vero, ma come sempre dipende dalla prospettiva.
Se si ha bisogno solo di comunicare in generale l'architettura allora il codice diventa superfluo e i diagrammi UML svolgono benissimo il loro lavoro, però se invece bisogna scegliere nel dettaglio io preferisco molto di + un codice scritto con i sacri crismi ma senza uno straccio di UML che lo documenti (che ricordo è sempre possibile generale quando si vuole) rispetto ad un codice perfettamente documentato con tanto di documenti di raccolta dei requisiti, di analisi, di diagrammi UML ma che poi è stato scritto con i piedi perchè si sono dovuti fare i salti mortali per consegnare in tempo il progetto vista l'enorme quantità di tempo dedicata a quelle prime fasi (e ovviamente tralasciamo il testing che spesso, nella migliore delle ipotesi, viene fatto con i piedi :muro: ).
^TiGeRShArK^
09-10-2007, 17:30
Se per te è una perdita di tempo...ma programmare ad oggetti senza progettare ad oggetti per me è un errore.
Stai scherzando ??????
Programmazione procedurare = algoritmi e strutture dati.
Programmazione ad oggetti = oggetti ed interazioni tra oggetti
Tu mi stai dicendo che ti butti sull'algoritmica invece che sulle interazioni tra oggetti...è gravissimo, per me.
Un buon test documenta molto meglio il comportamento dell'applicazione di uno sguardo ad un diagramma UML, perchè il test dipinge esattamente quello che ci si aspetta dall'aplicazione secondo le intenzioni del programmatore.
E cmq ti assicuro che quando devi andare a correggere errori nel codice scritto con i piedi da altri te ne sbatti delle interazioni con gli oggetti...
Cerchi solo di trovare il problema.
Ovviamente NON potendo usare il debug per me l'unica soluzione era il codice, non certo l'UML.
L'UML ti da appunto un'idea dell'interazione tra gli oggetti.
Ma se tu devi capire il motivo di un certo comportamento non lo vedi certo da un diagramma UML, ma devi andare a scavare nel codice (bug-digging lo chiamo io :D)
EDIT ops ..
m'ero perso la prima parte :p
e chi dice che non si debba progettare ad oggetti? :D
quello è implicito.
Una volta che si ha ben chiaro il problema, dopo aver analizzato anche a livello pratico le varie soluzioni possibili, è possibile dar forma alla propria applicazione.
Ma ovviamente ricordando sempre che quello che si pensa in quel momento è scritto sulla sabbia e deve essere sempre possibile cambiarlo.
La progettazione nell'informatica, sempre a parte determinati contesti, NON può essere assolutamente una cosa rigida, ma deve per forza di cose adattarsi continuamente alle condizioni al contorno.
Stai scherzando ??????
Programmazione procedurare = algoritmi e strutture dati.
Programmazione ad oggetti = oggetti ed interazioni tra oggetti
Tu mi stai dicendo che ti butti sull'algoritmica invece che sulle interazioni tra oggetti...è gravissimo, per me.
Un buon test documenta molto meglio il comportamento dell'applicazione di uno sguardo ad un diagramma UML, perchè il test dipinge esattamente quello che ci si aspetta dall'aplicazione secondo le intenzioni del programmatore.
E cmq ti assicuro che quando devi andare a correggere errori nel codice scritto con i piedi da altri te ne sbatti delle interazioni con gli oggetti...
Cerchi solo di trovare il problema.
Ovviamente NON potendo usare il debug per me l'unica soluzione era il codice, non certo l'UML.
L'UML ti da appunto un'idea dell'interazione tra gli oggetti.
Ma se tu devi capire il motivo di un certo comportamento non lo vedi certo da un diagramma UML, ma devi andare a scavare nel codice (bug-digging lo chiamo io :D)
EDIT ops ..
m'ero perso la prima parte :p
e chi dice che non si debba progettare ad oggetti? :D
quello è implicito.
Una volta che si ha ben chiaro il problema, dopo aver analizzato anche a livello pratico le varie soluzioni possibili, è possibile dar forma alla propria applicazione.
Ma ovviamente ricordando sempre che quello che si pensa in quel momento è scritto sulla sabbia e deve essere sempre possibile cambiarlo.
La progettazione nell'informatica, sempre a parte determinati contesti, NON può essere assolutamente una cosa rigida, ma deve per forza di cose adattarsi continuamente alle condizioni al contorno.
Nous
09-10-2007, 18:48
Un buon test documenta molto meglio il comportamento dell'applicazione di uno sguardo ad un diagramma UML, perchè il test dipinge esattamente quello che ci si aspetta dall'aplicazione secondo le intenzioni del programmatore.
E cmq ti assicuro che quando devi andare a correggere errori nel codice scritto con i piedi da altri te ne sbatti delle interazioni con gli oggetti...
Cerchi solo di trovare il problema.
Ovviamente NON potendo usare il debug per me l'unica soluzione era il codice, non certo l'UML.
L'UML ti da appunto un'idea dell'interazione tra gli oggetti.
Ma se tu devi capire il motivo di un certo comportamento non lo vedi certo da un diagramma UML, ma devi andare a scavare nel codice (bug-digging lo chiamo io :D)
EDIT ops ..
m'ero perso la prima parte :p
e chi dice che non si debba progettare ad oggetti? :D
quello è implicito.
Una volta che si ha ben chiaro il problema, dopo aver analizzato anche a livello pratico le varie soluzioni possibili, è possibile dar forma alla propria applicazione.
Ma ovviamente ricordando sempre che quello che si pensa in quel momento è scritto sulla sabbia e deve essere sempre possibile cambiarlo.
La progettazione nell'informatica, sempre a parte determinati contesti, NON può essere assolutamente una cosa rigida, ma deve per forza di cose adattarsi continuamente alle condizioni al contorno.
Mi sa che stiamo dicendo le stesse cose, ma in modo che l'altro abbia torto :asd:
Dai, sono d'accordo con te ma ho ragione io :O
E cmq ti assicuro che quando devi andare a correggere errori nel codice scritto con i piedi da altri te ne sbatti delle interazioni con gli oggetti...
Cerchi solo di trovare il problema.
Ovviamente NON potendo usare il debug per me l'unica soluzione era il codice, non certo l'UML.
L'UML ti da appunto un'idea dell'interazione tra gli oggetti.
Ma se tu devi capire il motivo di un certo comportamento non lo vedi certo da un diagramma UML, ma devi andare a scavare nel codice (bug-digging lo chiamo io :D)
EDIT ops ..
m'ero perso la prima parte :p
e chi dice che non si debba progettare ad oggetti? :D
quello è implicito.
Una volta che si ha ben chiaro il problema, dopo aver analizzato anche a livello pratico le varie soluzioni possibili, è possibile dar forma alla propria applicazione.
Ma ovviamente ricordando sempre che quello che si pensa in quel momento è scritto sulla sabbia e deve essere sempre possibile cambiarlo.
La progettazione nell'informatica, sempre a parte determinati contesti, NON può essere assolutamente una cosa rigida, ma deve per forza di cose adattarsi continuamente alle condizioni al contorno.
Mi sa che stiamo dicendo le stesse cose, ma in modo che l'altro abbia torto :asd:
Dai, sono d'accordo con te ma ho ragione io :O
mad_hhatter
09-10-2007, 18:49
è umanamente impossibile tenere conto di TUTTI gli aspetti che si dovranno affrontare (a meno di contesti particolari ovviamente).
Puoi progettare una casa in questa maniera dato che le sue specifiche sono per definizione immutabili, ma per un software, il cui processo di creazione è per definizione dinamico e deve adattarsi agli sbalzi d'umore del committente tentare di considerare tutti i possibli casi non si traduce in altro che in una perdita di tempo e anzi addirittura potrebbe risultare dannoso perchè si sono fatte ipotesi molto forti in uno stadio in cui ancora non si è affrontato il problema nel dettaglio ma solo in generale.
In questo modo è possibile addirittura ritrovarsi ad imboccare una strada senza uscita perchè anzikè mettere le mani sul codice e sbattere la testa contro i problemi si è preferito affidarsi a supposizioni e teorie che in prima istanza sembravano la cosa è corretta del mondo, ma che in pratica non risultano essere così ottimali come si pensava in quel momento.
Invece l'esplorazione pratica delle varie soluzioni tramite spike o prototipi o chiamateli come vi pare, tende ovviamente a minimizzare questi problemi dato che is possono saggiare quali siano nella realtà i problemi da affrontare nelle varie scelte disponibili.
Questo è sostanzialmente vero, ma come sempre dipende dalla prospettiva.
Se si ha bisogno solo di comunicare in generale l'architettura allora il codice diventa superfluo e i diagrammi UML svolgono benissimo il loro lavoro, però se invece bisogna scegliere nel dettaglio io preferisco molto di + un codice scritto con i sacri crismi ma senza uno straccio di UML che lo documenti (che ricordo è sempre possibile generale quando si vuole) rispetto ad un codice perfettamente documentato con tanto di documenti di raccolta dei requisiti, di analisi, di diagrammi UML ma che poi è stato scritto con i piedi perchè si sono dovuti fare i salti mortali per consegnare in tempo il progetto vista l'enorme quantità di tempo dedicata a quelle prime fasi (e ovviamente tralasciamo il testing che spesso, nella migliore delle ipotesi, viene fatto con i piedi :muro: ).
sono d'accordo su tutto... solo che come al solito ci vuole il giusto compromesso e il giusto mix di metodologie... non esiste una metodologia ottimale in ogni situazione.
è vero però che cercare di visualizzare le aree in cui è possibile prevedere che possa esserci una variazione nei requisiti permette di disegnare il codice in modo da limitare l'impatto di tale variazione al suo verificarsi senza però che sia necessario aggiungere feature inutili prima che la variazione stessa si manifesti
Puoi progettare una casa in questa maniera dato che le sue specifiche sono per definizione immutabili, ma per un software, il cui processo di creazione è per definizione dinamico e deve adattarsi agli sbalzi d'umore del committente tentare di considerare tutti i possibli casi non si traduce in altro che in una perdita di tempo e anzi addirittura potrebbe risultare dannoso perchè si sono fatte ipotesi molto forti in uno stadio in cui ancora non si è affrontato il problema nel dettaglio ma solo in generale.
In questo modo è possibile addirittura ritrovarsi ad imboccare una strada senza uscita perchè anzikè mettere le mani sul codice e sbattere la testa contro i problemi si è preferito affidarsi a supposizioni e teorie che in prima istanza sembravano la cosa è corretta del mondo, ma che in pratica non risultano essere così ottimali come si pensava in quel momento.
Invece l'esplorazione pratica delle varie soluzioni tramite spike o prototipi o chiamateli come vi pare, tende ovviamente a minimizzare questi problemi dato che is possono saggiare quali siano nella realtà i problemi da affrontare nelle varie scelte disponibili.
Questo è sostanzialmente vero, ma come sempre dipende dalla prospettiva.
Se si ha bisogno solo di comunicare in generale l'architettura allora il codice diventa superfluo e i diagrammi UML svolgono benissimo il loro lavoro, però se invece bisogna scegliere nel dettaglio io preferisco molto di + un codice scritto con i sacri crismi ma senza uno straccio di UML che lo documenti (che ricordo è sempre possibile generale quando si vuole) rispetto ad un codice perfettamente documentato con tanto di documenti di raccolta dei requisiti, di analisi, di diagrammi UML ma che poi è stato scritto con i piedi perchè si sono dovuti fare i salti mortali per consegnare in tempo il progetto vista l'enorme quantità di tempo dedicata a quelle prime fasi (e ovviamente tralasciamo il testing che spesso, nella migliore delle ipotesi, viene fatto con i piedi :muro: ).
sono d'accordo su tutto... solo che come al solito ci vuole il giusto compromesso e il giusto mix di metodologie... non esiste una metodologia ottimale in ogni situazione.
è vero però che cercare di visualizzare le aree in cui è possibile prevedere che possa esserci una variazione nei requisiti permette di disegnare il codice in modo da limitare l'impatto di tale variazione al suo verificarsi senza però che sia necessario aggiungere feature inutili prima che la variazione stessa si manifesti
cdimauro
09-10-2007, 20:31
E' difficile "prevedere" le variazioni: le specifiche cambiano frequentemente, e non possiamo certo intuire dove ci sarà da modificare qualcosa.
Per questo è meglio partire con un'applicazione minimale, ridotta ai minimi termini e che soddisfa le specifiche correnti: in questo modo non si perde troppo tempo dietro a roba intuile ed è più facile "reagire" ai cambiamenti.
x Nous: a me sembra, piuttosto, che a "Tiger" piaccia lavorare come me; infatti ha pure detto che i diagrammi UML, se servono, si possono generare al volo dal codice corrente. ;)
Per questo è meglio partire con un'applicazione minimale, ridotta ai minimi termini e che soddisfa le specifiche correnti: in questo modo non si perde troppo tempo dietro a roba intuile ed è più facile "reagire" ai cambiamenti.
x Nous: a me sembra, piuttosto, che a "Tiger" piaccia lavorare come me; infatti ha pure detto che i diagrammi UML, se servono, si possono generare al volo dal codice corrente. ;)
Nous
10-10-2007, 00:19
x Nous: a me sembra, piuttosto, che a "Tiger" piaccia lavorare come me; infatti ha pure detto che i diagrammi UML, se servono, si possono generare al volo dal codice corrente. ;)
Ciò è male :O
Ragazzi, è ovvio che se ho a che fare con software legacy o robaccia fatta da altri il diagramma UML me lo genero anche...ma il mio lavoro non è bello se me lo fanno i tool automatici :asd:
Ciò è male :O
Ragazzi, è ovvio che se ho a che fare con software legacy o robaccia fatta da altri il diagramma UML me lo genero anche...ma il mio lavoro non è bello se me lo fanno i tool automatici :asd:
cdimauro
10-10-2007, 08:43
Ciò è male :O
Ragazzi, è ovvio che se ho a che fare con software legacy o robaccia fatta da altri il diagramma UML me lo genero anche...ma il mio lavoro non è bello se me lo fanno i tool automatici :asd:
Infatti non glielo faccio fare nemmeno ai tool automatici: non li uso e basta. :asd:
Ragazzi, è ovvio che se ho a che fare con software legacy o robaccia fatta da altri il diagramma UML me lo genero anche...ma il mio lavoro non è bello se me lo fanno i tool automatici :asd:
Infatti non glielo faccio fare nemmeno ai tool automatici: non li uso e basta. :asd:
k0nt3
10-10-2007, 10:21
la programmazione è una disciplina molto vasta e non esiste un solo metodo per fare le cose.
l'unica cosa nota è che scartare uno strumento (quale può essere UML) a priori è un errore.
generare diagrammi dal codice ha scopo meramente documentativo, mentre UML è stato creato per supportare la progettazione, quindi direi che non è una pratica corretta
l'unica cosa nota è che scartare uno strumento (quale può essere UML) a priori è un errore.
generare diagrammi dal codice ha scopo meramente documentativo, mentre UML è stato creato per supportare la progettazione, quindi direi che non è una pratica corretta
cdimauro
10-10-2007, 10:24
Generare i diagrammi non serve soltanto per la documentazione, ma anche per aver una visione generale del progetto (nel caso dovesse servire).
Nous
10-10-2007, 10:26
Generare i diagrammi non serve soltanto per la documentazione, ma anche per aver una visione generale del progetto (nel caso dovesse servire).
Inoltre fa figo :O
Inoltre fa figo :O
k0nt3
10-10-2007, 10:27
Generare i diagrammi non serve soltanto per la documentazione, ma anche per aver una visione generale del progetto (nel caso dovesse servire).
cioè documentare :fagiano:
cioè documentare :fagiano:
cdimauro
10-10-2007, 11:29
Inoltre fa figo :O
Anche.
cioè documentare :fagiano:
Anche.
:D
Anche.
cioè documentare :fagiano:
Anche.
:D
non sò!
07-11-2007, 15:11
ciao a tutti, ho fatto una ricerca ma non ho trovato ciò che mi interessava...
devo fare un programmino in java che visualizzi le temperature lette dai sensori del computer e magari che mostri il tipo di hardware installato(caratteristiche). sapreste dirmi se vi sono delle librerie particolari per interrogare tali sensori?o il riferimento per leggerli?:help:
grazie delle risposte
ps come avrete capito dal linguaggio tecnico utilizzato sono più che neofita in tale campo (per adessso ho solo programmato un distributore di alimenti, tipo quelli delle scuole):D
devo fare un programmino in java che visualizzi le temperature lette dai sensori del computer e magari che mostri il tipo di hardware installato(caratteristiche). sapreste dirmi se vi sono delle librerie particolari per interrogare tali sensori?o il riferimento per leggerli?:help:
grazie delle risposte
ps come avrete capito dal linguaggio tecnico utilizzato sono più che neofita in tale campo (per adessso ho solo programmato un distributore di alimenti, tipo quelli delle scuole):D
variabilepippo
07-11-2007, 15:14
Come ti è stato detto anche QUI (http://www.hwupgrade.it/forum/showthread.php?t=1596516) non puoi fare richieste off-topic scegliendo un thread a caso tra quelli esistenti, apri una nuova discussione.
non sò!
07-11-2007, 15:30
Come ti è stato detto anche QUI (http://www.hwupgrade.it/forum/showthread.php?t=1596516) non puoi fare richieste off-topic scegliendo un thread a caso tra quelli esistenti, apri una nuova discussione.
no non è una domanda a caso! scusa questo 3d non è: "iniziare a programmare"?! io praticamente sò a malapena cos'è una classe applicazione!!!
mi potresti spiegare con un topic così quale sarebbe una domanda opportuna?:)
e poi quelli che parlano di trasformate di fourier e segnali non sono off-topic??!!:read:
:ops:scusa non ho letto tutto:D mi sono accorto dopo dell'altro link
scusami:ave:
no non è una domanda a caso! scusa questo 3d non è: "iniziare a programmare"?! io praticamente sò a malapena cos'è una classe applicazione!!!
mi potresti spiegare con un topic così quale sarebbe una domanda opportuna?:)
e poi quelli che parlano di trasformate di fourier e segnali non sono off-topic??!!:read:
:ops:scusa non ho letto tutto:D mi sono accorto dopo dell'altro link
scusami:ave:
cionci
07-11-2007, 15:44
Come già ti è stato detto, apri una nuova discussione ed attendi che ti rispondano lì ;)
non sò!
07-11-2007, 15:47
fatto fatto!:)
volevo solo sapere perchè era off-topic. non ero polemico...solo titolo informativo per non errare in futuro:D grazie cmq
volevo solo sapere perchè era off-topic. non ero polemico...solo titolo informativo per non errare in futuro:D grazie cmq
variabilepippo
07-11-2007, 15:55
volevo solo sapere perchè era off-topic. non ero polemico...solo titolo informativo grazie cmq
Perché questa discussione è stata avviata da un utente che chiedeva consigli generici su quale linguaggio di programmazione studiare e dunque non vedo quale sia il legame con la richiesta di interfacciarsi a dei sensori in Java. In gergo la tua domanda è "off-topic", se tutti facessero la stessa cosa il forum diventerebbe in brevissimo tempo un bordello (passatemi il termine). :)
Perché questa discussione è stata avviata da un utente che chiedeva consigli generici su quale linguaggio di programmazione studiare e dunque non vedo quale sia il legame con la richiesta di interfacciarsi a dei sensori in Java. In gergo la tua domanda è "off-topic", se tutti facessero la stessa cosa il forum diventerebbe in brevissimo tempo un bordello (passatemi il termine). :)
fek
07-11-2007, 16:13
prima regola del buon programmatore: prima di scrivere una sola riga di codice, pensa bene a ciò che fai...
"Any design effort that takes more than 30 minutes is a waste of time" - Eric Gunnerson
E' la mia firma in ufficio :)
non tutti i formalismi vanno bene ovunque, ma il buttarsi subito sul codice secondo me è sbagliato... all'inizio va anche bene, tanto gli esercizi sono dei piccoli giocattoli, ma se si cresce con questo modo di fare, quando si avrà a che fare con progetti complessi si aprtirà col piede sbagliato... non è necessario formalizzare il progetto della soluzione, ma analizzare bene il problema e le sue soluzioni PRIMA di scrivere codice è indispensabile: la soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
Ma sai che sono in disaccordo con te su TUTTA la linea, ma proprio ogni singola parola.
Stai sostanzialmente difendendo il concetto di Big Design Up Front, che dopo vent'anni a fare questo lavoro ho concluso essere l'origine del novanta per cento dei mali del mondo (o almeno tutti quelli legati alla programmazione).
Ormai da anni ho un approccio totalmente diverso a quello che descrivi tu:
- Non penso MAI al design globale per piu' di dieci minuti, di solito faccio mente locale di tutte le soluzioni possibili che a grandi linee mi risolvono il problema e poi scelgo sempre la piu' semplice che mi viene in mente. Se non mi viene in mente una soluzione semplice in qualche minuto, allora semplifico il problema iniziale, pongo dei limiti dove posso, taglio quello che non serve e poi mi butto subito a scrivere codice.
- Ogni minuto che passo a pensare e non a scrivere codice per me e' un minuto che perdo per avvicinarmi alla soluzione.
- Appena possibile (ovvero subito) inizio a scrivere codice "esplorativo", provo qualche soluzione e guardo il problema che si risolve per avere piu' idee sulla soluzione stessa: nel 99% dei casi il solo iniziare a scrivere codice mi da' idee nuove alle quali non avrei mai pensato.
- Il vedere anche solo parte della soluzione in termini di codice e non di un'astrazione diversa e' assolutamente fondamentale.
- A ogni passetto della soluzione, la semplifico, ovvero faccio refactoring del codice: fare refactoring non e' qualcosa del quale vuoi abbassare le probabilita' che accada, ma l'essenza stessa di un design evolutivo, non e' una fase, ma parte integrante di come io scrivo il design di un'architettura. Se il design mi esce in maniera naturale dal refactoring, e' il segnale che sono sulla strada giusta: quando cerco io di imporre il design al codice invece di vederlo "nascere da solo", mi infilo sempre in un disastro. Ormai e' quasi matematico. Fare refactoring e semplificare il codice e' l'attivita' che ormai piu' mi piace.
- Quando si ha a che fare con progetti complessi, il Big Design Up Front e' un disastro perche' e' umanamente impossibile trovare la soluzione ottimale prima di aver scritto il codice, perche' si tende a sovraingegnerizzare SEMPRE, perche' venti persone che sovraingegnerizzano e' la ricetta per il disastro (anche se sono solo 19 piu' un povero cristo come me che fa lo spazzino e rifattorizza continuamente il codice altrui).
- Sono arrivato ad un tale livello di pragmatismo che non scrivo una singola riga di codice a meno che non sia strettamente indispensabile alla soluzione del problema che ho, fino ad arrivare a non fissare di proposito bug dei quali conosco l'esistenza fino a che non li ho visti verificarsi.
In conclusione: e' indispensabile smettere di pensare ore al design prima di scrivere codice, e' indispensabile scrivere codice il prima possibile, e' indispensabile smettere di sovraingegnerizzare le soluzione. Keep It Simple Sweetie.
Il risultato e' scrivere la meta' del codice funzionante e testato al doppio della velocita'.
"Any design effort that takes more than 30 minutes is a waste of time" - Eric Gunnerson
E' la mia firma in ufficio :)
non tutti i formalismi vanno bene ovunque, ma il buttarsi subito sul codice secondo me è sbagliato... all'inizio va anche bene, tanto gli esercizi sono dei piccoli giocattoli, ma se si cresce con questo modo di fare, quando si avrà a che fare con progetti complessi si aprtirà col piede sbagliato... non è necessario formalizzare il progetto della soluzione, ma analizzare bene il problema e le sue soluzioni PRIMA di scrivere codice è indispensabile: la soluzione infatti deve passare per vari gradi di dettaglio e buttarsi subito sul codice significa occuparsi da subito in dettagli che potrebbero non portare alla soluzione ottimale aumentando le probabilità di dover fare refactoring
Ma sai che sono in disaccordo con te su TUTTA la linea, ma proprio ogni singola parola.
Stai sostanzialmente difendendo il concetto di Big Design Up Front, che dopo vent'anni a fare questo lavoro ho concluso essere l'origine del novanta per cento dei mali del mondo (o almeno tutti quelli legati alla programmazione).
Ormai da anni ho un approccio totalmente diverso a quello che descrivi tu:
- Non penso MAI al design globale per piu' di dieci minuti, di solito faccio mente locale di tutte le soluzioni possibili che a grandi linee mi risolvono il problema e poi scelgo sempre la piu' semplice che mi viene in mente. Se non mi viene in mente una soluzione semplice in qualche minuto, allora semplifico il problema iniziale, pongo dei limiti dove posso, taglio quello che non serve e poi mi butto subito a scrivere codice.
- Ogni minuto che passo a pensare e non a scrivere codice per me e' un minuto che perdo per avvicinarmi alla soluzione.
- Appena possibile (ovvero subito) inizio a scrivere codice "esplorativo", provo qualche soluzione e guardo il problema che si risolve per avere piu' idee sulla soluzione stessa: nel 99% dei casi il solo iniziare a scrivere codice mi da' idee nuove alle quali non avrei mai pensato.
- Il vedere anche solo parte della soluzione in termini di codice e non di un'astrazione diversa e' assolutamente fondamentale.
- A ogni passetto della soluzione, la semplifico, ovvero faccio refactoring del codice: fare refactoring non e' qualcosa del quale vuoi abbassare le probabilita' che accada, ma l'essenza stessa di un design evolutivo, non e' una fase, ma parte integrante di come io scrivo il design di un'architettura. Se il design mi esce in maniera naturale dal refactoring, e' il segnale che sono sulla strada giusta: quando cerco io di imporre il design al codice invece di vederlo "nascere da solo", mi infilo sempre in un disastro. Ormai e' quasi matematico. Fare refactoring e semplificare il codice e' l'attivita' che ormai piu' mi piace.
- Quando si ha a che fare con progetti complessi, il Big Design Up Front e' un disastro perche' e' umanamente impossibile trovare la soluzione ottimale prima di aver scritto il codice, perche' si tende a sovraingegnerizzare SEMPRE, perche' venti persone che sovraingegnerizzano e' la ricetta per il disastro (anche se sono solo 19 piu' un povero cristo come me che fa lo spazzino e rifattorizza continuamente il codice altrui).
- Sono arrivato ad un tale livello di pragmatismo che non scrivo una singola riga di codice a meno che non sia strettamente indispensabile alla soluzione del problema che ho, fino ad arrivare a non fissare di proposito bug dei quali conosco l'esistenza fino a che non li ho visti verificarsi.
In conclusione: e' indispensabile smettere di pensare ore al design prima di scrivere codice, e' indispensabile scrivere codice il prima possibile, e' indispensabile smettere di sovraingegnerizzare le soluzione. Keep It Simple Sweetie.
Il risultato e' scrivere la meta' del codice funzionante e testato al doppio della velocita'.
^TiGeRShArK^
07-11-2007, 17:23
Se il design mi esce in maniera naturale dal refactoring, e' il segnale che sono sulla strada giusta: quando cerco io di imporre il design al codice invece di vederlo "nascere da solo", mi infilo sempre in un disastro. Ormai e' quasi matematico. Fare refactoring e semplificare il codice e' l'attivita' che ormai piu' mi piace.
quoto tutto, ma soprattutto questa parte :p
Per me scrivere codice è come intagliare il legno.
Prendi un pezzo di corteccia in mano, la guardi e inizi ad intagliare.
Solo a mano a mano che lavori vedi cosa il legno vuole diventare.
Mi è capitato diverse volte di aver iniziato il lavoro convinto che uscisse qualcosa che avevo in mente chiaramente e invece poi, mentre passava il tempo, mi accorgevo che il risultato del moi lavoro sarebbe stato tutt'altro.
Scrivere codice è molto simile.
Solo modellandolo passo passo è possibile ottenere la forma migliore.
Se ci si fissa troppo sull'idea iniziale si rischia di perdere molte altre strade che si aprono davanti a mano a mano che il percorso di coding prosegue.
Questa ovviamente è solo la mia visione, forse un pò artistica e romantica, della programmazione.
Però volevo dare i miei 2 cent... :p
quoto tutto, ma soprattutto questa parte :p
Per me scrivere codice è come intagliare il legno.
Prendi un pezzo di corteccia in mano, la guardi e inizi ad intagliare.
Solo a mano a mano che lavori vedi cosa il legno vuole diventare.
Mi è capitato diverse volte di aver iniziato il lavoro convinto che uscisse qualcosa che avevo in mente chiaramente e invece poi, mentre passava il tempo, mi accorgevo che il risultato del moi lavoro sarebbe stato tutt'altro.
Scrivere codice è molto simile.
Solo modellandolo passo passo è possibile ottenere la forma migliore.
Se ci si fissa troppo sull'idea iniziale si rischia di perdere molte altre strade che si aprono davanti a mano a mano che il percorso di coding prosegue.
Questa ovviamente è solo la mia visione, forse un pò artistica e romantica, della programmazione.
Però volevo dare i miei 2 cent... :p
mad_hhatter
07-11-2007, 17:40
"Any design effort that takes more than 30 minutes is a waste of time" - Eric Gunnerson
E' la mia firma in ufficio :)
Ma sai che sono in disaccordo con te su TUTTA la linea, ma proprio ogni singola parola.
Stai sostanzialmente difendendo il concetto di Big Design Up Front, che dopo vent'anni a fare questo lavoro ho concluso essere l'origine del novanta per cento dei mali del mondo (o almeno tutti quelli legati alla programmazione).
Ormai da anni ho un approccio totalmente diverso a quello che descrivi tu:
- Non penso MAI al design globale per piu' di dieci minuti, di solito faccio mente locale di tutte le soluzioni possibili che a grandi linee mi risolvono il problema e poi scelgo sempre la piu' semplice che mi viene in mente. Se non mi viene in mente una soluzione semplice in qualche minuto, allora semplifico il problema iniziale, pongo dei limiti dove posso, taglio quello che non serve e poi mi butto subito a scrivere codice.
- Ogni minuto che passo a pensare e non a scrivere codice per me e' un minuto che perdo per avvicinarmi alla soluzione.
- Appena possibile (ovvero subito) inizio a scrivere codice "esplorativo", provo qualche soluzione e guardo il problema che si risolve per avere piu' idee sulla soluzione stessa: nel 99% dei casi il solo iniziare a scrivere codice mi da' idee nuove alle quali non avrei mai pensato.
- Il vedere anche solo parte della soluzione in termini di codice e non di un'astrazione diversa e' assolutamente fondamentale.
- A ogni passetto della soluzione, la semplifico, ovvero faccio refactoring del codice: fare refactoring non e' qualcosa del quale vuoi abbassare le probabilita' che accada, ma l'essenza stessa di un design evolutivo, non e' una fase, ma parte integrante di come io scrivo il design di un'architettura. Se il design mi esce in maniera naturale dal refactoring, e' il segnale che sono sulla strada giusta: quando cerco io di imporre il design al codice invece di vederlo "nascere da solo", mi infilo sempre in un disastro. Ormai e' quasi matematico. Fare refactoring e semplificare il codice e' l'attivita' che ormai piu' mi piace.
- Quando si ha a che fare con progetti complessi, il Big Design Up Front e' un disastro perche' e' umanamente impossibile trovare la soluzione ottimale prima di aver scritto il codice, perche' si tende a sovraingegnerizzare SEMPRE, perche' venti persone che sovraingegnerizzano e' la ricetta per il disastro (anche se sono solo 19 piu' un povero cristo come me che fa lo spazzino e rifattorizza continuamente il codice altrui).
- Sono arrivato ad un tale livello di pragmatismo che non scrivo una singola riga di codice a meno che non sia strettamente indispensabile alla soluzione del problema che ho, fino ad arrivare a non fissare di proposito bug dei quali conosco l'esistenza fino a che non li ho visti verificarsi.
In conclusione: e' indispensabile smettere di pensare ore al design prima di scrivere codice, e' indispensabile scrivere codice il prima possibile, e' indispensabile smettere di sovraingegnerizzare le soluzione. Keep It Simple Sweetie.
Il risultato e' scrivere la meta' del codice funzionante e testato al doppio della velocita'.
spunti molto interassanti (e alcuni sorprendenti :) ). Ti ringrazio, sono frasi preziose.
quello che vorrei chiederti è: come fai a scrivere codice se non hai deciso chi fa cosa? (chi = oggetto / modulo) Come fai a scrivere codice senza aver stabilito le interazioni tra entità (e quindi le funzionalità degli stessi)?
a scanso di equivoci, non sono assolutamento polemico: sto cercando di capire i vari modelli di processo di sviluppo di un software (purtroppo a ing info a padova non fanno ste cose e invece a me affascinano da matti)
grazie per la discussione!
E' la mia firma in ufficio :)
Ma sai che sono in disaccordo con te su TUTTA la linea, ma proprio ogni singola parola.
Stai sostanzialmente difendendo il concetto di Big Design Up Front, che dopo vent'anni a fare questo lavoro ho concluso essere l'origine del novanta per cento dei mali del mondo (o almeno tutti quelli legati alla programmazione).
Ormai da anni ho un approccio totalmente diverso a quello che descrivi tu:
- Non penso MAI al design globale per piu' di dieci minuti, di solito faccio mente locale di tutte le soluzioni possibili che a grandi linee mi risolvono il problema e poi scelgo sempre la piu' semplice che mi viene in mente. Se non mi viene in mente una soluzione semplice in qualche minuto, allora semplifico il problema iniziale, pongo dei limiti dove posso, taglio quello che non serve e poi mi butto subito a scrivere codice.
- Ogni minuto che passo a pensare e non a scrivere codice per me e' un minuto che perdo per avvicinarmi alla soluzione.
- Appena possibile (ovvero subito) inizio a scrivere codice "esplorativo", provo qualche soluzione e guardo il problema che si risolve per avere piu' idee sulla soluzione stessa: nel 99% dei casi il solo iniziare a scrivere codice mi da' idee nuove alle quali non avrei mai pensato.
- Il vedere anche solo parte della soluzione in termini di codice e non di un'astrazione diversa e' assolutamente fondamentale.
- A ogni passetto della soluzione, la semplifico, ovvero faccio refactoring del codice: fare refactoring non e' qualcosa del quale vuoi abbassare le probabilita' che accada, ma l'essenza stessa di un design evolutivo, non e' una fase, ma parte integrante di come io scrivo il design di un'architettura. Se il design mi esce in maniera naturale dal refactoring, e' il segnale che sono sulla strada giusta: quando cerco io di imporre il design al codice invece di vederlo "nascere da solo", mi infilo sempre in un disastro. Ormai e' quasi matematico. Fare refactoring e semplificare il codice e' l'attivita' che ormai piu' mi piace.
- Quando si ha a che fare con progetti complessi, il Big Design Up Front e' un disastro perche' e' umanamente impossibile trovare la soluzione ottimale prima di aver scritto il codice, perche' si tende a sovraingegnerizzare SEMPRE, perche' venti persone che sovraingegnerizzano e' la ricetta per il disastro (anche se sono solo 19 piu' un povero cristo come me che fa lo spazzino e rifattorizza continuamente il codice altrui).
- Sono arrivato ad un tale livello di pragmatismo che non scrivo una singola riga di codice a meno che non sia strettamente indispensabile alla soluzione del problema che ho, fino ad arrivare a non fissare di proposito bug dei quali conosco l'esistenza fino a che non li ho visti verificarsi.
In conclusione: e' indispensabile smettere di pensare ore al design prima di scrivere codice, e' indispensabile scrivere codice il prima possibile, e' indispensabile smettere di sovraingegnerizzare le soluzione. Keep It Simple Sweetie.
Il risultato e' scrivere la meta' del codice funzionante e testato al doppio della velocita'.
spunti molto interassanti (e alcuni sorprendenti :) ). Ti ringrazio, sono frasi preziose.
quello che vorrei chiederti è: come fai a scrivere codice se non hai deciso chi fa cosa? (chi = oggetto / modulo) Come fai a scrivere codice senza aver stabilito le interazioni tra entità (e quindi le funzionalità degli stessi)?
a scanso di equivoci, non sono assolutamento polemico: sto cercando di capire i vari modelli di processo di sviluppo di un software (purtroppo a ing info a padova non fanno ste cose e invece a me affascinano da matti)
grazie per la discussione!
fek
07-11-2007, 17:59
spunti molto interassanti (e alcuni sorprendenti :) ). Ti ringrazio, sono frasi preziose.
quello che vorrei chiederti è: come fai a scrivere codice se non hai deciso chi fa cosa? (chi = oggetto / modulo) Come fai a scrivere codice senza aver stabilito le interazioni tra entità (e quindi le funzionalità degli stessi)?
a scanso di equivoci, non sono assolutamento polemico: sto cercando di capire i vari modelli di processo di sviluppo di un software (purtroppo a ing info a padova non fanno ste cose e invece a me affascinano da matti)
grazie per la discussione!
Grazie a te :)
Quello che faccio si chiama Design Evolutivo e parte dal presupposto che il design si evolve man mano che scrivi il codice, e con il design emergono le classi e le relazioni fra di esse attraverso il refactoring. E' l'esatto opposto dell'imporre una struttura al codice dall'alto.
Quando non sto scrivendo test-driven (ovvero, purtroppo, quando sono al lavoro), di solito butto giu' un po' di codice abbastanza velocemente commettendo qualunque peccato anche mortale con il solo scopo di ottenere velocemente una soluzione al problema che mi pongo. Non mi interessa che la soluzione sia perfetta, sia veloce, sia robusta, o tanto meno che sia bella: mi interessa avere velocemente qualcosa che piu' o meno funzioni. Di solito e' una soluzione quasi totalmente procedurale.
Dopo qualche minuto guardo il codice e inizio ad estrarre metodi e a semplificarlo: in questa fase il codice mi sta dicendo come vuole essere modellato e mi sta "suggerendo" la sua struttura. Mi ritrovo con un insieme di metodi in una classe, li osservo e cerco di capire quali metodi e con quali dati formano una nuova classe candidata per essere estratta. Estraggo le classi, guardo quali relazioni fra di loro mi suggeriscono, semplifico il codice, diciamo che in questa fase lo oop-izzo ed inizio a ragionare in termini di relazioni fra oggetti. Il risultato e' sempre codice piu' semplice di quello iniziale.
Ora ti descrivo i passi, ma durante il lavoro normale le varie fasi vanno avanti quasi in parallelo: scrivo codice, nel frattempo lo rifattorizzo, estraggo i metodi, li sposto, muovo classi, scrivo un altro po' di codice.
Dopo un po' di tempo mi ritrovo con una manciata di classi in relazione fra di loro e le classi tendono ad essere molto disaccoppiate e coese, proprio perche' cerco di non imporre un design dall'alto e di non sovraingegnerizzare mai.
Quando scrivo test-driven i passi sono ancora piu' brevi e non scrivo quasi mai piu' di due o tre righe di codice senza un po' di refactoring o un nuovo test. Scrivere test-driven e' molto piu' rilassante e "ritmato", perche' non ho bisogno delle fasi di debugging ed ho un approccio alla soluzione piu' sicuro.
quello che vorrei chiederti è: come fai a scrivere codice se non hai deciso chi fa cosa? (chi = oggetto / modulo) Come fai a scrivere codice senza aver stabilito le interazioni tra entità (e quindi le funzionalità degli stessi)?
a scanso di equivoci, non sono assolutamento polemico: sto cercando di capire i vari modelli di processo di sviluppo di un software (purtroppo a ing info a padova non fanno ste cose e invece a me affascinano da matti)
grazie per la discussione!
Grazie a te :)
Quello che faccio si chiama Design Evolutivo e parte dal presupposto che il design si evolve man mano che scrivi il codice, e con il design emergono le classi e le relazioni fra di esse attraverso il refactoring. E' l'esatto opposto dell'imporre una struttura al codice dall'alto.
Quando non sto scrivendo test-driven (ovvero, purtroppo, quando sono al lavoro), di solito butto giu' un po' di codice abbastanza velocemente commettendo qualunque peccato anche mortale con il solo scopo di ottenere velocemente una soluzione al problema che mi pongo. Non mi interessa che la soluzione sia perfetta, sia veloce, sia robusta, o tanto meno che sia bella: mi interessa avere velocemente qualcosa che piu' o meno funzioni. Di solito e' una soluzione quasi totalmente procedurale.
Dopo qualche minuto guardo il codice e inizio ad estrarre metodi e a semplificarlo: in questa fase il codice mi sta dicendo come vuole essere modellato e mi sta "suggerendo" la sua struttura. Mi ritrovo con un insieme di metodi in una classe, li osservo e cerco di capire quali metodi e con quali dati formano una nuova classe candidata per essere estratta. Estraggo le classi, guardo quali relazioni fra di loro mi suggeriscono, semplifico il codice, diciamo che in questa fase lo oop-izzo ed inizio a ragionare in termini di relazioni fra oggetti. Il risultato e' sempre codice piu' semplice di quello iniziale.
Ora ti descrivo i passi, ma durante il lavoro normale le varie fasi vanno avanti quasi in parallelo: scrivo codice, nel frattempo lo rifattorizzo, estraggo i metodi, li sposto, muovo classi, scrivo un altro po' di codice.
Dopo un po' di tempo mi ritrovo con una manciata di classi in relazione fra di loro e le classi tendono ad essere molto disaccoppiate e coese, proprio perche' cerco di non imporre un design dall'alto e di non sovraingegnerizzare mai.
Quando scrivo test-driven i passi sono ancora piu' brevi e non scrivo quasi mai piu' di due o tre righe di codice senza un po' di refactoring o un nuovo test. Scrivere test-driven e' molto piu' rilassante e "ritmato", perche' non ho bisogno delle fasi di debugging ed ho un approccio alla soluzione piu' sicuro.
mad_hhatter
07-11-2007, 18:09
Grazie a te :)
Quello che faccio si chiama Design Evolutivo e parte dal presupposto che il design si evolve man mano che scrivi il codice, e con il design emergono le classi e le relazioni fra di esse attraverso il refactoring. E' l'esatto opposto dell'imporre una struttura al codice dall'alto.
Quando non sto scrivendo test-driven (ovvero, purtroppo, quando sono al lavoro), di solito butto giu' un po' di codice abbastanza velocemente commettendo qualunque peccato anche mortale con il solo scopo di ottenere velocemente una soluzione al problema che mi pongo. Non mi interessa che la soluzione sia perfetta, sia veloce, sia robusta, o tanto meno che sia bella: mi interessa avere velocemente qualcosa che piu' o meno funzioni. Di solito e' una soluzione quasi totalmente procedurale.
Dopo qualche minuto guardo il codice e inizio ad estrarre metodi e a semplificarlo: in questa fase il codice mi sta dicendo come vuole essere modellato e mi sta "suggerendo" la sua struttura. Mi ritrovo con un insieme di metodi in una classe, li osservo e cerco di capire quali metodi e con quali dati formano una nuova classe candidata per essere estratta. Estraggo le classi, guardo quali relazioni fra di loro mi suggeriscono, semplifico il codice, diciamo che in questa fase lo oop-izzo ed inizio a ragionare in termini di relazioni fra oggetti. Il risultato e' sempre codice piu' semplice di quello iniziale.
Ora ti descrivo i passi, ma durante il lavoro normale le varie fasi vanno avanti quasi in parallelo: scrivo codice, nel frattempo lo rifattorizzo, estraggo i metodi, li sposto, muovo classi, scrivo un altro po' di codice.
Dopo un po' di tempo mi ritrovo con una manciata di classi in relazione fra di loro e le classi tendono ad essere molto disaccoppiate e coese, proprio perche' cerco di non imporre un design dall'alto e di non sovraingegnerizzare mai.
Quando scrivo test-driven i passi sono ancora piu' brevi e non scrivo quasi mai piu' di due o tre righe di codice senza un po' di refactoring o un nuovo test. Scrivere test-driven e' molto piu' rilassante e "ritmato", perche' non ho bisogno delle fasi di debugging ed ho un approccio alla soluzione piu' sicuro.
MOLTO interessante! stai parlando di XP/agile methods o è qualcosa di diverso?
porca miseria, devo trovare il tempo per leggere qualche libro sulle metodologie di sviluppo...
ti ringrazio molto, mi dispiace non essere in grado di sostenere una discussione sul tema...
Quello che faccio si chiama Design Evolutivo e parte dal presupposto che il design si evolve man mano che scrivi il codice, e con il design emergono le classi e le relazioni fra di esse attraverso il refactoring. E' l'esatto opposto dell'imporre una struttura al codice dall'alto.
Quando non sto scrivendo test-driven (ovvero, purtroppo, quando sono al lavoro), di solito butto giu' un po' di codice abbastanza velocemente commettendo qualunque peccato anche mortale con il solo scopo di ottenere velocemente una soluzione al problema che mi pongo. Non mi interessa che la soluzione sia perfetta, sia veloce, sia robusta, o tanto meno che sia bella: mi interessa avere velocemente qualcosa che piu' o meno funzioni. Di solito e' una soluzione quasi totalmente procedurale.
Dopo qualche minuto guardo il codice e inizio ad estrarre metodi e a semplificarlo: in questa fase il codice mi sta dicendo come vuole essere modellato e mi sta "suggerendo" la sua struttura. Mi ritrovo con un insieme di metodi in una classe, li osservo e cerco di capire quali metodi e con quali dati formano una nuova classe candidata per essere estratta. Estraggo le classi, guardo quali relazioni fra di loro mi suggeriscono, semplifico il codice, diciamo che in questa fase lo oop-izzo ed inizio a ragionare in termini di relazioni fra oggetti. Il risultato e' sempre codice piu' semplice di quello iniziale.
Ora ti descrivo i passi, ma durante il lavoro normale le varie fasi vanno avanti quasi in parallelo: scrivo codice, nel frattempo lo rifattorizzo, estraggo i metodi, li sposto, muovo classi, scrivo un altro po' di codice.
Dopo un po' di tempo mi ritrovo con una manciata di classi in relazione fra di loro e le classi tendono ad essere molto disaccoppiate e coese, proprio perche' cerco di non imporre un design dall'alto e di non sovraingegnerizzare mai.
Quando scrivo test-driven i passi sono ancora piu' brevi e non scrivo quasi mai piu' di due o tre righe di codice senza un po' di refactoring o un nuovo test. Scrivere test-driven e' molto piu' rilassante e "ritmato", perche' non ho bisogno delle fasi di debugging ed ho un approccio alla soluzione piu' sicuro.
MOLTO interessante! stai parlando di XP/agile methods o è qualcosa di diverso?
porca miseria, devo trovare il tempo per leggere qualche libro sulle metodologie di sviluppo...
ti ringrazio molto, mi dispiace non essere in grado di sostenere una discussione sul tema...
fek
07-11-2007, 18:34
MOLTO interessante! stai parlando di XP/agile methods o è qualcosa di diverso?
porca miseria, devo trovare il tempo per leggere qualche libro sulle metodologie di sviluppo...
ti ringrazio molto, mi dispiace non essere in grado di sostenere una discussione sul tema...
Sto in realta' descrivendo come lavoro io, che e' fortemente ispirato alle metodologie agili adattate all'ambiente lavorativo dove sono che di agile ha proprio nulla (e da qui nascono un po' di conflitti con il resto del team), ed e' il risultato di un po' di anni di esperienza lavorativa su code base mastodontiche, qualche milione di righe di codice, di cui alcune centinaia di migliaia mie.
porca miseria, devo trovare il tempo per leggere qualche libro sulle metodologie di sviluppo...
ti ringrazio molto, mi dispiace non essere in grado di sostenere una discussione sul tema...
Sto in realta' descrivendo come lavoro io, che e' fortemente ispirato alle metodologie agili adattate all'ambiente lavorativo dove sono che di agile ha proprio nulla (e da qui nascono un po' di conflitti con il resto del team), ed e' il risultato di un po' di anni di esperienza lavorativa su code base mastodontiche, qualche milione di righe di codice, di cui alcune centinaia di migliaia mie.
marco.r
08-11-2007, 12:57
Quando non sto scrivendo test-driven (ovvero, purtroppo, quando sono al lavoro), di solito butto giu' un po' di codice abbastanza velocemente commettendo qualunque peccato anche mortale con il solo scopo di ottenere velocemente una soluzione al problema che mi pongo. Non mi interessa che la soluzione sia perfetta, sia veloce, sia robusta, o tanto meno che sia bella: mi interessa avere velocemente qualcosa che piu' o meno funzioni. Di solito e' una soluzione quasi totalmente procedurale.
Sembra piu' o meno quello che faccio io. Cosa per la quale mi scontro ogni tanto coi colleghi, un paio dei quali sono piu' orientati verso i massimi sistemi :cry: . La cosa da un lato e' divertente perche' loro arrivano con schemi diagrammi e pseudo-specifiche alle riunioni, mentre io magari con un prototipo funzionante, dall'altro pero' sono delle lotte visto che spesso cerco di proporre delle soluzioni che siano anche implementabili facilmente, e mi sento ribattere che sono dettagli implementativi (che ovviamente poi mi devo smazzare io... ).
Sembra piu' o meno quello che faccio io. Cosa per la quale mi scontro ogni tanto coi colleghi, un paio dei quali sono piu' orientati verso i massimi sistemi :cry: . La cosa da un lato e' divertente perche' loro arrivano con schemi diagrammi e pseudo-specifiche alle riunioni, mentre io magari con un prototipo funzionante, dall'altro pero' sono delle lotte visto che spesso cerco di proporre delle soluzioni che siano anche implementabili facilmente, e mi sento ribattere che sono dettagli implementativi (che ovviamente poi mi devo smazzare io... ).
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.