Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

best practice

12 views
Skip to first unread message

Wildcat

unread,
Mar 8, 2012, 3:51:34 AM3/8/12
to
salve a tutti,
chiedo venia (se OT) ma soprattutto consiglio.

da poco mi sono avvicinato alla programmazione, fantastico, ma ho
decisamente delle difficoltà nell'impostare progetti nuovi. Finchè mi
sono adoperato a fare programmini di prova tutto ok per non dire alla
grande, ma ora che sono alle prese con un progettino che a dire la
verità non è neanche mastodontico vado in panne. L'idea di base è
chiara, poi comincio a scrivere i primi oggetti ma ad un certo punto mi
accorgo di scrivere cose che non servono, passo dati inutili o altro di
peggio.
Come si affronta un nuovo progetto in maniera corretta? Che tools usate
a questo scopo? Una buona lettura a riguardo?
Ho letto diverse cose su UML, ma provando ad utilizzarlo non mi sembra
che questo mi agevoli la vita.
grazie a tutti
saluti

Giulio Petrucci

unread,
Mar 8, 2012, 7:41:46 AM3/8/12
to
Ciao Wildcat,

On 08/03/2012 09:51, Wildcat wrote:
[cut]
> Come si affronta un nuovo progetto in maniera corretta? Che tools usate
> a questo scopo? Una buona lettura a riguardo?
> Ho letto diverse cose su UML, ma provando ad utilizzarlo non mi sembra
> che questo mi agevoli la vita.

Consigli metodologici:
1. le basi teoriche sono importanti (qui di libri ne hai quanti ne vuoi
:-)).
2. leggere è più importante che scrivere: leggere del *buon* codice (e
ti assicuro che se ne trova parecchio) è altamente formativo, come pure
la frequentazione di community dove circolano persone competenti (tipo
questo NG qui :-))
3. Shu-Ha-Ri: il processo didattico deve essere una graduale presa di
coscienza degli strumenti. Al primo livello (Shu) acquisisci "copiando"
una fonte, al secondo livello (Ha) inizi a discostarti dalla mera
riproduzione del modello, infine (Ri) padroneggi la materia e la cali
nella realtà secondo i tuoi scopi.

Consigli pratici:
1. se sei da solo a lavorare, le difficoltà aumentano: lavorare in team
è la cosa migliore, specialmente se si segue una metodologia "agile";
2. i principi "cardine" sono sempre utili
(http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)) e vanno
sempre tenuti a mente;
3. prima di scrivere il codice è bene pensare, analizzare
dettagliatamente il problema e...
4. ...non avere la pretesa di avere la soluzione ottimale al primo
colpo: esiste il refactoring! :-)

Detto questo, i tool sono - appunto - "attrezzi" che servono alla mente
per attualizzare il proprio pensiero. Personalmente uso Visual Studio
Express Edition e basta (se lavoro in .NET, per tutto il resto c'è Emacs
:-)).
L'UML è un ottimo modo per realizzare degli sketch che diano una visione
di massima del problema, ma secondo me la pretesa (che alcuni hanno) di
documentare tutto nel minimo dettaglio può essere controproducente.

Tutto
Rigorosamente
IMVHO
:-)

Ciao,
Giulio

--

Wildcat

unread,
Mar 8, 2012, 8:30:35 AM3/8/12
to
Grazie dei consigli Giulio, li stampo e me li metto in bella vista.
In effetti sono da solo a lavorare, ma in concreto probabilmente ho solo
bisogno di trovare un metodo mio per inquadrare correttamente il
problema, tutto è chiaro finchè non si inizia a scrivere... :( e
probabilmente in questa fase poi inizio a perdere la cognizione
dell'obiettivo.
Questa mattina mi sono messo ad approfondire il discorso UML, i class
diagrams in particolare, ed in effetti qualche aiuto me lo sta dando.
Non pretendo di certo mettermi a creare faldoni di documentazione, ma
solo degli scretch su cui riflettere e ragionare.
Poi, come anticipavi tu, non sarebbe male seguire qualche progetto
interessante esistente... per quello vedremo...
ciao

Mauro Servienti [MVP]

unread,
Mar 8, 2012, 11:59:05 AM3/8/12
to
Ciao Wildcat,

You wrote on 08/03/2012 :
> Grazie dei consigli Giulio, li stampo e me li metto in bella vista.
> In effetti sono da solo a lavorare, ma in concreto probabilmente ho solo

il problema è proprio che sei solo, è molto più complesso perchè non
hai nessuno con cui confrontarti, sfrutta questo NG e tutte le fonti
che trovi e non porti mai la domanda se la domanda che stai per fare è
stupida.

> Questa mattina mi sono messo ad approfondire il discorso UML, i class
> diagrams in particolare, ed in effetti qualche aiuto me lo sta dando. Non
> pretendo di certo mettermi a creare faldoni di documentazione, ma solo degli
> scretch su cui riflettere e ragionare.

io mollerei al volo UML è una cosa più da imparare a gestire.

.m

--
blog @ //milestone.topics.it


Wildcat

unread,
Mar 16, 2012, 6:14:04 PM3/16/12
to
uhm, forse ora sono quasi convinto su uml ma certamente un sistema per
abbozzare la logica dell'applicazione bisogna che lo trovo soprattutto per
il fatto che questo facendolo a tempo perso non riesco ad avere continuità e
le idee che mi vengono poi mi ci vuole tempo per riorganizzarle. I tools UML
usati non da manuale comunque mi potrebbero aiutare.
E' si, sò solo :)) anche se in realtà conosco alcune persone ma a parte il
fatto che non saprei da che parte cominciare poi c'è il fatto che non mi
piace il modo su come svolgono il loro lavoro.

Però una domanda o più, e stupida se permettete la voglio fare comunque,
visto che come avrete capito è il metodo di ben lavorare che voglio capire.
E' bene lavorare su più progetti oppure no?
Vedendo le diverse applicazioni installate su pc presumo che l'eseguibile
contenga il codice letteralmente ridotto all'osso, metodo main o poco di più
ed il resto tutto su progetti differenti. Ho notato che tante applicazioni
"recenti" hanno degli exe da una 70ntina di kb quindi presumo quanto sopra.
Qualche consiglio da darmi su come ben organizzare una Soluzione e PRogetti
in VS.

grazie anticipate


"Mauro Servienti [MVP]" ha scritto nel messaggio
news:mn.44377dc30...@online.nospam...

Mauro Servienti [MVP]

unread,
Mar 17, 2012, 3:17:45 AM3/17/12
to
Ciao Wildcat,

You wrote on 16/03/2012 :
> uhm, forse ora sono quasi convinto su uml ma certamente un sistema per
> abbozzare la logica dell'applicazione bisogna che lo trovo soprattutto per
> il fatto che questo facendolo a tempo perso non riesco ad avere continuitᅵ
> e le idee che mi vengono poi mi ci vuole tempo per riorganizzarle. I tools
> UML usati non da manuale comunque mi potrebbero aiutare.

allora tanto vale powerpoint o carta e penna :-)

> Perᅵ una domanda o piᅵ, e stupida se permettete la voglio fare comunque,
> visto che come avrete capito ᅵ il metodo di ben lavorare che voglio capire.
> E' bene lavorare su piᅵ progetti oppure no?

in teoria no, o meglio dipende :-) il context switch ha un costo e ogni
volta che devi cambiare progetto devi ricordarti dove eri arrivato su
quello prima, se lo fai per vivere ᅵ difficile (possibile ma difficile)
riuscire a lavorare su un solo progetto alla volta, ci sono metodologie
che aiutano molto in questa direzione.

> Vedendo le diverse applicazioni installate su pc presumo che l'eseguibile
> contenga il codice letteralmente ridotto all'osso, metodo main o poco di
> piᅵ ed il resto tutto su progetti differenti. Ho notato che tante
> applicazioni "recenti" hanno degli exe da una 70ntina di kb quindi presumo
> quanto sopra.

considerazione condivisibile.

> Qualche consiglio da darmi su come ben organizzare una Soluzione e PRogetti
> in VS.

cosᅵ su due piedi non saprei probabilmente ci si potrebbe scrivere un
libro :-)

> grazie anticipate

neroMalpelo

unread,
Apr 20, 2012, 5:40:37 AM4/20/12
to
Ciao WildCat

Credo di essere nella tua stessa situazione.
E' un po che leggo e leggo manuali e ora e' giunto il momento di mettere
in pratica quanto studiato.
Sono solo anche io e mi rendo conto che si fa piu' fatica al "decollo"
se si e' soli.

Se ti va, potremmo sentirci e scambiare idee e suggerimenti o sul tuo
progetto e sul piccolo programmillo che vorrei fare.

ciao

0 new messages