Newsgroup: it.comp.lang.visual-basic
Titolo: [~OT] Pensierino da programmatore della domenica sera

Il pensierino è della domenica sera, non il programmatore :P
Ovvero, prima di tornare al lavoro mi è venuta in mente una cosa...
Voglio fare una considerazione, e avere i pareri di chi legge, sulla
questione della progettazione SW.
La domanda è: ma serve veramente?
In termini economici intendo.
Personalmente mi considero un discreto programmatore, non uno dei migliori,
ma capace di buttar giù 4 righe di codice con una certa logica, e cerco di
fare il mio lavoro nel migliore dei modi.
Quindi, quando mi arriva un lavoro (parlo da dipendente, ma la cosa può
essere vista anche da chi lavora in proprio), anzichè iniziare a buttar giù
codice faccio una piccola analisi su carta (niente di che, un flusso delle
finestre che devono saltar fuori e di cosa deve fare il programma).
Poi inizio a scrivere, cercando di mettere i metodi alle classi o le
funzioni nei moduli in modo non "arrabattone", ma secondo una logica
funzionale e nell'intento di sveltirmi il lavoro la prossima volta che ci
metterò le mani.
Questo "pensare al futuro" però implica tempi superiori di sviluppo rispetto
alla tecnica "arrabattona", magari non di molto, ma superiori.
Il problema è che mi sembra che questo "pensare al futuro" mi si presenti ad
ogni nuovo lavoro, quindi ogni lavoro finisce con un sensibile sforamento
dei tempi.
Il lavoro risulterà tecnicamente buono e magari anche dalla parte
dell'utente si troverà un programma più funzionale, però fatto sta che 'sti
tempi sono sempre fuori.
Quindi il mio dubbio eistenziale è: ma non è che hanno ragione gli
"arrabattoni"?
Voi come mi comportate?
Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti?
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net


DFD ,ER, processi progetti logici ,progetti fisici, mini specifiche ,alberi
decisionali e compagnia bella
e poi ti ritrovi a pensare al futuro.
Io la chiamerei Saggezza ;)
SunRex

 Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti?
Yep. Anzi... prevedi e chiedi tutto il tempo possibile per l'analisi,
tanto lo risparmierai in fase di realizzazione e modifica del prog.
L'unica volta che non l'ho fatto, il prog mi è cresciuto tra le mani
come un cancro, finché non mi è toccato rifarlo da capo.
Lo racconto perché è un esempio tipico... allora, arriva uno dei
boss e dice:
- Mi servirebbe un progettino, hai un pochino di tempo da dedicarmi ?
- Quanto ?
- Boh, una mezza giornata...
- OK. Di che si tratta ?
- Abbiamo un altro prog che crea un file di testo con dei dati,
campi a lunghezza fissa. Dovremmo leggerlo e farne una tabella.
(...mi frego le mani, pensando: "Una Open, Line input, Split e una
griglia, che ci vuole ?)
- Bene, mandatemi un file di prova che vediamo.
Lo faccio in mezza giornata, lo mando e mi dicono
- OK, carino. Ci servirebbe qualche modifica, ne possiamo parlare ?
-Chiamatemi quando volete.
NON L'AVESSI MAI DETTO. :-((((
Tralasciando il fatto che:
- il file campione che mi avevano mandato all'inizio non era ancora
definitivo, quindi cambiavano molte cose
- prima di metà del lavoro i campi e le loro posizioni sono cambiati
più volte.
- non era con campi a lunghezza fissa, ma un CSV, in cui purtroppo
i campi di testo potevano contenere tranquillamente delle virgole :-(
...man mano che ci lavoravo, arrivavano nuove richieste, dalle più
umane alle più assurde. Qualche esempio ?
Prima mi hanno chiesto di evidenziare in colori diversi determinate
cose, poi si devono poter editare le celle, ma non tutte solo quelle
di certe colonne, ma anche altre se ci sono certi problemi, ma volendo
anche tutte, ma non proprio tutte, ma si può sapere _chi_ ha fatto
_quali_ modifiche ? allora ci vuole una gestione degli utenti, però
devono essere anonimi, perché senno' poi se la prendono con me...
poi la possibilità di spostare  le righe della tabella, poi anche le
colonne,
anzi, no, solo parte delle righe, ma rinumerando la prima colonna,
poi il copia e incolla tra due tabelle, poi gestire le righe come gruppi,
poi l'ordinamento automatico, ma secondo parametri variabili, ma
anzi no, va ordinato a mano, ma si potrebbe fare anche che se questo
è diverso da quello allora quell'altro poi dovrebbe... eh, ah, eeee...
senti, ma per stamparlo ? e si può mandare per e-mail ? si può avere
in PDF ? Ma se voglio tornare ad una versione precedente ? ah,
bisognerebbe loggare le modifiche... E senti... non si potrebbe
verificare se la coerenza dei dati... ? poi... ma se ci sono due righe
uguali si può dare un avvertimento ? Ma a me quei colori non mi
piacciono, li posso modificare ?
*AAAAAAAAAAAAAARRRGH !* =8-[
Bye, G.

 Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti?
I miei lavori si basano fortemente sul trattamento di basi dati.
Fatta un'analisi presso il richiedente,
se il lavoro consiste nell'aggiunta di una nuova funzionalità a qualcosa di
già esistente mi metto lì a pensare.
se il lavoro consiste nella creazione di un nuovo progetto ... mi metto lì a
pensare.
Penso a cosa mi serve, cos'ho e cosa devo ottenere. Quindi, principalmente,
alla struttura dei dati.
Poi apro word e scrivo a ruota libera tutto ciò che mi viene in mente, a mo'
di appunti. Questo mi aiuta ad affrontare (apparentemente casualmente) tutte
le problematiche e, quindi, a tutti i pasticci cui andrò incontro. Non li
risolvo, ma me li appunto giusto per ricordarmi che ... dovrò risolverli.
Faccio un preventivo dei tempi di massima e ... moltiplico per 1.5 ;-)
No, coi lavori che mi stanno stretti nei tempi insisto e spiego, cerco di
far capire che non "ci sto facendo la cresta". Se proprio i tempi sono
troppo stretti (e quindi piuttosto imposti), rifiuto.

 Io la chiamerei Saggezza ;)
Sě, ma la saggezza paga?
Mi viene in mente la storiella del viaggiatore che chiede al saggio monaco
la formula per la vita eterna... (cerca in google su questo gruppo)


 tanto lo risparmierai in fase di realizzazione e modifica del prog.
Da noi (e anche in altre ditte in cui sono stato) non si distingue il tempo
di progettazione dal tempo di realizzazione.
Arrivano con il malloppone di richieste e ti dicono "c'è da fare questo...
sarebbe da fare in ... giorni".
Poi hai ragione: molti progetti arrivano così: "Che ci vuole a farlo? Basta
mettere un IF!" poi ti accorgi che se metti l'if metà di quello che ci gira
intorno non funziona più e devi rivederlo, quindi la tua ora di modifiche
diventa una giornata di ristrutturazione e vagli a spiegare che per stampare
"A" invece di "B" ti ci è voluta una giornata. :(
Ma questa è un'altra problematica di cui non ci occupiamo nel presente
articolo :)


 wrote
SunRex


 In termini economici intendo.
Serve, lo renderei obbligatorio.
Darei il patentino per programmare solo a chi supera l'esame sulla questione
da te posta.
E' un'impostazione mentale che supera l'area lavorativa.
E' un' impostazione mentalmente che educa a ragionare in modo ordinato e
sequenziale, anche nello svolgimento di vita quotidiana.
Esiste un dibbattito aperto:
il riutilizzo del codice.
Solo una metodologia di lavoro permette di far accrescere la libreria, da
utilizzare in proggetti successivi.
Certo lo sfigato che opera in situazioni sempre diversi non mancherà,
ma è quasi prassi che alcune situazioni si ripetono.
Alcuni punti quasi fermi si può tentare di enumerare.
Consideriamo che un programmatore pignolo all'eccesso avrà vita difficile.
Tocchiamo il pratico, la costruzione di una Toolkit.
La splashscreen, può essere standardizzata.
La gestione delle autorizzazioni, User e password, con l'ultima criptata,
(aggiungiamo il ruolo)
si può semistandardizzare.
Il controllo dei dati obbligatori, delle virgole e dei punti,
dell'inserimento di soli numeri, ecc.
Una classe per l'accesso al db con i relativi metodi per l'INSERT, ecc.
Se non imposti logicamente l'analisi dello schedario delle transazioni,
voglio vedere il ripresentarsi dopo mesi quanto tempo impieghi a risolvere.
Un'anilisi a braccio:
1- Splashscreen > ce l'ho
2-Criptare delle stringhe > ce l'ho
3- ecc.
Per non parlare di interventi successivi all'applicativo
Ave
giuseppeD

 Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti?
si ma non e' possibile ! ^_^
Guarda, io oramai abituato dai tempi dela sQuola , seguo il tuo stesso iter,
butti giu' 2 schizzi a mente o su carta e inizi a codare , man mano scrivo
routine comuni da mettere in moduli o dll e continuo a buttar giu' schizzi e
diagrammi su carta cercando, nelle prime ore, di capire cosa e' da
centralizzare e cosa posso arrabbattare, questo mi e' utile perche' mi
capita spesso che a meta' lavoro mi si presenta il pirla che mi chiede "una
modifichina" :-/
se avessi arrabbattato tutto, sarei costretto quasi a cancellare delle form
intere, mentre con codice previdente e ben progettato non faccio altro che
ignorare delle sub che avevo scritto e crearne un altro modificando in poche
ore il progetto, visto che oramai qui in ufficio e' la prassi lo stravolgere
tutto, io mi paro il popo' organizzando la struttura il + flessibile
possibile, oramai utilizzo uno schema tipo :
public.bas
dove ci schiaffo tutto quello che e' pubblico sub var ecc...
poi ho
modulospecifico.bas con delle macro funzioni che di solito riciclo da un
piccolo archivio personale (es: stampe, i/o,formattazioni di oggetti ecc)
frmName.frm dove ci sono solo oggetti e la relative sub private con scope
solo alla form stessa
ora se mi chiedono di stravolgere la form main posso permettermi
tranquillamente di cancellarla e riscriverla da 0 ma sono sicuro che cosi
facendo risparmio i tempi del tipo :
Arrabbattando
stesura 5ore
modifiche e manutenzione 5ore
10Ore
ConUnOcchio al futuro
Stesura 8ore
modifiche e manutenzione 3ore
11Ore
logicamente c'e' quell'oretta in piu' ma che ti permette di lavorare in modo
pulito e sicuro, molto spesso infatti capitera' che per modificare in fretta
una sub (1 ora diciamo) ci si perda almeno il doppio per turare le falle
prodotte da esso (se si e' arrabbattato) , facendo mere figure e
incazzandosi inutilmente, invece meglio spendercene 2 di ore ma con calma,
essendo sempre pienamente padroni del codice e "non trovarci in mano con un
ago immenso di osso a ricucire un foglio di carta velina" ^_^
Bello st'ultimo pensiero, stanotte so poeta ^_______^
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 Sito Comune : 
http://www.it-lang-vb.net
quoto tutto. Mi piace questa domanda, volevo quasi farla io, anche se posta
magari in maniera diversa.
Vi spiego: sto leggendo "Codice ribelle", un libro preso allo Smau che libro
della nascita di Linux, del fenomeno GNU, del software open source, freeware
e molto altro ancora. Non sto qui a dilungarmi sui dettagli, ma ve lo
consiglio perchè è molto interessante. Arrivo al dunque, anche se non sono
molto preciso, perchè non ho il testo sotto mano.
I vari hacker che all'inizio hanno cominciato a sviluppare il kernel di
Linux (i vari Linus, Richard Stallman ed altri ancora che hanno creato TeX,
sendmail e altri "miti" nell'ambiente Linux), sono fondamentalemente
arrabattoni, diciamo così.
Seguono la filosofia: prima fai qualcosa funzionante, anche brutta, poi fai
i miglioramenti dopo.
Nell'ambiente Linux infatti prima si fa uscire qualcosa, qualche patch/prg
di qualche tipo, poi se ce n'è bisogno vengono rilasciati aggiornamenti che
perfezionano e sistemano i bug.
In questi giorni stavo quindi pensando anche io a questa cosa. Sapete che
risposta mi sono dato?
Che si può benissimo essere arrabattoni, solo che bisogno averne le
capacità. Un newbie non dovrebbe mai fare l'arrabattone, rischierebbe solo
di far casino. Io, onestamente, oggi, in certi contesti, scrivo subito
codice.
E sono dell'idea che è ora di sfatare il mito secondo il quale il codice
scritto di getto è brutto e fa schifo.
Tutto dipende dal programmatore.
I migliori software per Linux sono stati scritti partendo da basi semplici,
scrivendo magari per 2 settimane consecutive il codice, senza nessuna
analisi particolare. Ovvio, se si sta parlando di progetti grossi, allora
magari è un altro discorso. Se si sta parlando di progetti che non si sa
dove vanno a finire, allora andrebbe pensato tutto bene subito.
Perchè, molto spesso anche io ho la stessa sensazione di Zanna: il
riutilizzo del codice è quasi una teoria. Tutte le volte che comincio un
progetto, riscrivo quasi sempre da zero, al massimo importo qualche .bas o
.cls, ma nulla di più....
non so, io preferisco scrivere d'impulso......
e non è giusto guardare male gli sviluppatori arrabattoni, ce ne sono molti
al mondo, e fanno ottimi lavori.
Solo, bisogna saperlo veramente fare......
con questo, vi auguro una buonanotte.....ci vediamo domani mattina....
:-)))
good coding!!!
--
Damiani Liborio Igor
http://www.igordamiani.it
Nella finestra Debug di VB:
Nome="igor":? Nome & Chr$(64) & Nome & "damiani" & Chr$(46) & "it"
Che tu sia maledetto, SWEN...

 Bello st'ultimo pensiero, stanotte so poeta ^_______^
bene. se poi rispettassi l'italiano... ^_^
ciao, j.

 aggiornamenti che perfezionano e sistemano i bug.
In Microsoft invece no... i bug sono già perfetti fin dall'inizio :-P
Un Paperino e WindowsUpdate.

 Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti?
Io credo che un cliente soddisfatto č un cliente che riceve un programma
funzionante, anche se un pochino in ritardo, a cui sia possibile apportare
le "classiche" modifiche in corso d'opera o dopo la prima release senza
dover impiegare una vita....
La tentazione dell'arrabattamento č forte, ma penso che se prima hai le idee
chiare su come realizzare il progetto, fai molto in fretta a scrivere il
codice dopo, senza magari riscrivere o ribaltare completamente la logica
dell'applicazione.
"Tradurre" comunque quello che ti chiede il cliente (= tutto l'immaginabile
possibile e il + delle volte impossibile)  in quello che devi fare tu, a mio
parere, non č sempre cosě semplice, ci vuole uno studio accurato.
Dal canto mio, i progetti migliori che abbia mai realizzato li ho pensati
prima a tavolino, con carta e matita, scrivendo appunti o idee su come
strutturare il programma, a volte facendo proprio lo schema della gerarchia
delle mie classi e dei compiti che ciascuna deve svolgere.
Per i tempi.... mmmhhhh... io di solito faccio una stima da ottimista, una
da pessimista e ne propongo la media... ;-)
                        Ciao
                                    Zephiross

.cls, ma nulla di piů....
Su questo no, o almeno lo farei dipendere al 99.9 % dal tipo di
programma.
Io sviluppo principalmente software legato alla gestione dati, con n
form di inserimento dati "di base" (anagrafica clienti, chiodi,
bulloni, pale, attivita', etc.): il primo lavoro che ho fatto (durato
un anno) l'ho sviluppato cercando di standardizzare le funzioni che
doveva avere il form tipo (inserimento, modifica, cancellazione,
visione in griglia, stampa, spostamento nei record, tutto scritto su
carta prima) e di conseguenza ho realizzato il form tipo.
In tutto il resto del programma ho riciclato il form tipo risparmiando
un sacco di tempo.
Il secondo programma (poco meno di un anno di lavoro) era sempre di
gestione dati => form gia' pronti, qualche modifica nell'interfaccia e
*opla* un sacco di tempo risparmiato
Per il terzo programma mi hanno richiesto l'uso di .net
=> mi sono fatto un mazzettino per creare classi che incapsulassero la
complessita' della gestione dati (datatable, datarow, oledbcommand,
etc) in una classe simil rdo, lo stesso per la stampa, la gestione
della griglia (in vb6 uso la FlexGrid) etc.
=> ho perso tempo all'inizio del progetto (a carico mio) ma in seguito
ho potuto riciclare lo stesso codice in vb6 al 90 % e ho gia' la
libreria pronta per i futuri progetti 
vb.net
Commento finale:
Il riciclo del codice gia' testato e funzionante e' alla base per
risparmiare tempo nello sviluppo senza intaccare la qualita' del
proprio lavoro (ovviamente IMHO)
Ciao !
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

 Ciao

 Ciao
Bella domanda Zanna...richiede ponderata e politica risposta....
secondo me e la mia esperienza la risposta più politica è
 BOH! ci si intende poco....
poi la risposta più sincera è
DIPENDE
dipende da tante cose....
ora come ora IMHO.... NO!
Però non è verità di fede ma realtà locale del singolo.....
e allora la verità nuda e cruda è DIPENDE DA CHI SEI non c'è risposta
univoca....
Mi spiego ...probabilmente la qualità paga....ma mica sempre!
SE sei un artigiano...e hai un periodo di economia in espansione...e hai un
segmento di mercato "recettivo"....e riesci ad "indovinare" "progettare"la
qualità paga!
E anche bene...fai pochi prodotti pagati bene e la soddisfazione anche
morale è massima!
Oppure (ma non ho esperienza diretta...solo di amici) lavori per una
struttura (banca , ente, swhouse di una certa dimensione) che ha i suoi
standards ed i suoi livelli di riferimento...la tua qualità allora non sarà
la massima possibile ma quella richiesta dalla struttura...
Poi c' è il "serraglio" dove lavoro e opero io....
ditta propria che deve trovarsi clienti...lavori...commesse...in un mercato
"piccolo" "ignorante" e anche un po "becero" come è la realtà locale.
Ossia la realtà di una città con una crisi economica forte...capitali
bloccati....pochi investimenti...con un infrastruttura di servizi esistente
ma obsoleta.
Dove le "storiche" swhouse locali vendono ancora i rispettabilissimi
gestionali in Cobol....dove la percentuale di alfabetizzazione informatica
cresce fra i dipendenti ma drammaticamente cozza ancora con i manager e gli
imprenditori....
Un mercato quindi che guarda più al "soldo" che alla "resa".... o meglio il
massimo della "resa" con il minimo del "soldo".
(d'altronde se vi vendiamo cappotti fatti con gli stracci.....e son fatti
bene....figurati nel sw che chiedono!)
Qui ti scontri con 2 tipi di concorrenti......anzi 3...l'agente delle grandi
SwHouse locali (ma quando c'è te ne vai perchè con loro competi
male....hanno struttura e prezzi stracciati....ti vendono un gestionale
(tutto uguale che va bene dalla tessitura alla pasticceria) a pochissimo e
poi inculano il cliente con contratti di assistenza carissimi)
dicevo competi (quando non ci son questi)....
1) con il figliolo del lattaio....(lo chiamo così)...programmatori con PIVA
e un Vstudio...che si spacciano per megaprogrammatori che ti realizzeranno
il gestionale dei tuoi sogni. A un prezzo infimo. Poco importa se non
rispetteranno le promesse  o se il gestionale avrà tanti problemi di
configurazione.Come fai a dirlo al tuo potenziale cliente? Se lo fai
presente passi da "Giuda" o peggio da uno che vuol dir male dei colleghi per
fregare il cliente (mi è capitato che mi trattassero anche male
all'inizio...)
2)Con il negozio "Ciro Telefoni & Software"
ossia con il negozio di informatica che ha assoldato 2 o 3 ragazzi per
programmare ....
Li ti ammazza perchè insieme al sw li sparano anche un rinnovamento parco
macchine...o il nuovo fax...o la stampante di rete a cationi di
plutonio...etc etc
e fanno il giochetto o diminuisco l'HW e aumento il sw o viceversa....
Che ti rimane e che concludi.....
beh mi rimane questo......
Arruffone son di natura...ma son anche permaloso....mi scoccia se mi
"beccano" su un mio lavoro che non va!
e allora mi son fatto una "base"....su quella modifico qualcosa.....c'ho il
mio gestionalino finito all'80%...il 20% ce lo aggiungo volta volta.....
non è il migliore possibile.....va bene con forzature un po per tutto...è un
6 e mezzo di voto!
Ma lo posso fare a un prezzo che ogni tanto qualcuno me lo compra...
domada : e allora come campi?
Beh... sto smettendo sempre più di programmare in VB....
o mi capita il prodotto "artigianale"....e ogni tanto capita...altrimenti
non ce la faccio a promettere cose che non mantengo.
Mi son rotto di litigare con i clienti che tanto non capiscono nulla e vanno
dietro più ai colori della finestra che alla facilità d'uso del programma!
... mi son messo a fare siti web e corsi di informatica et similia ...anche
onsite
perchè?
perchè si sopravvive cercando giorni migliori...e a me non va poi tanto
male! C'è di peggio in città!
e intanto si studia...si aumentano le proprie conoscenze...
perchè dopo sta lunga e pallosa risposta la mia "perla" è che:
"
La qualità è cosa buona e giusta....in teoria!
La "qualità paga" è una bufala degli enti di certificazione qualità e dei
politici che non sanno che dire.
In realtà è la quantità che paga.
Si è ribaltato tutto:
è il Volume che fa la massa!!!
"
enjoy yourself
:-)
-- 
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
 Quotefix e altro:
http://www.martek.it/go.asp?portamia=4
Usr: ICLVB Pw: amici


Se parli in termini economici serve tutto o niente.Credo che questa domanda
la dovresti fare al tuo cliente chiedendogli se vuole realmente un software
fatto bene oppure no...
Una buona progettazione è alla base di qualsiasi cosa si intenda realizzare
soprattutto se si parla di software che potresti dover modificare.
ciao
------------------------
http://visualwx.altervista.org/
nuova release 0.77c [freeware]
VisualWx rad per c++,python,perl,lua e wxwindows

 bene. se poi rispettassi l'italiano... ^_^
Arg! Non e' giusto, ti sei impegnato anche a seguire la netiquette cosi da
non aver nessun argomento di attacco... CattiFo hai vinto, mi ritiro dietro
la lavagna !
PS:  :(
-- 
-Gigio@Work(?)-

 Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti?
Io mi comporto cosě.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 così..."?
La questione è semplice: la progettazione non è stata ottimale.
D'altra parte la progettazione (corretta) del sw è qualcosa che richiede
solide basi (non di programmazione, ma proprio di progettazione), e
soprattutto una grande, grande, grande esperienza nel campo. Pertanto è
decisamente difficile che programmatori (e non progettisti) di età
giovane come la nostra possano essere bravi in questa attività.


 arrabattoni, diciamo così.
Ed infatti Sendmail ed anche altri programmi di questo tipo sono
talmente pessimi e talmente pieni di bug che al confronto Windows è IL
codice perfetto.


 progettisti) di età giovane come la nostra possano essere bravi in questa
attività.
Parla per te.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Per l'età, cos'hai capito ? :-P
Un Paperino '61, e che gli mancano proprio le basi per la progettazione. :-(

 Un Paperino '61, e che gli mancano proprio le basi per la progettazione. :-(
Beh, hai 9 anni più di me, sei ancora molto giovane...


 Beh, hai 9 anni più di me, sei ancora molto giovane...
Beh, non è che mi senta "vecchio" :-), a volte un po' stanco,
magari... anche se un figlio di 5 mesi stancherebbe chiunque :-/
Quello che intendo è che non ho fatto studi da programatore,
sono completamente autodidatta, e mi mancano nel senso
letterale le basi, la teoria; quelle cose che magari quando ti
tocca studiarle sono di una noia mortale, solo dopo anni ti
accorgi di quanto ti siano utili... E poi, sai quante volte mi sono
accorto di star reinventando la ruota ? :-(
Oltretutto, da un po' di tempo sto svolgendo sempre meno
lavoro da programmatore e sempre più da sistemista.
E' un momento un po' così, insomma... chi vivrà vedrà.
Bye, G.

 E' un momento un po' così, insomma... chi vivrà vedrà.
Ciao.


 giovane come la nostra possano essere bravi in questa attività.
Il tuo discorso è giusto, ma devi anche tenere in considerazione la diversa
natura dei problemi che, come programmatore, ti si possono presentare.
Un giorno potresti realizzare un programma di contabilità, un altro un
server per una specifica funzione, un altro ancora un protocollo per una
particolare comunicazione, etc.
Insomma, la capacità di progettazione, imho, dev'essere legata anche
all'esperienza che tu hai sull'argomento che stai sviluppando.
-- 
Ciao,
        Fabrizio
<=- 
http://www.negusweb.it
 -=>

 Dovrei semplicemente rifuitarmi di fare i lavori ai tempi proposti
Piu' che altro le situazioni che mi si presentano sono due:
1) Problema conosciuto: allora ho gia' in mente quali possono essere le
parti da "lasciare aperte" e da tenere maggiormente in considerazione; 
in questo caso l'esperienza acquisita mi consente di poter progettare in
modo abbastanza sicuro il software; quindi mi dedico molto a rifinire bene
lo schema del software, impiegando poco tempo a "tradurlo" in Visual Basic.
2) Problema sconosciuto: in questo comincio subito a scrivere del codice per
capire quali possono essere i punti su cui mi devo dedicare maggiormente;
passato un po' di tempo ad analizzare in maniera pratica il problema, posso
finalmente farmi uno schema su come progettare il software.
Tirando le somme la mia idea č che se conosco il problema posso fare una
buona ottimizzazione delle conoscenze per poterle applicare al caso
specifico, ma se non conosco il problema devo prima capire quali sono i
punti deboli su cui devo lavorare maggiormente per poter avere una visione
d'insieme ed avere uno schema completo.


 all'esperienza che tu hai sull'argomento che stai sviluppando.
Sì, ovviamente. Comunque, cosa che non va contro quello che hai appena
detto, io sono convinto che i due ruoli progettatore/programmatore
debbano rimanere generalmente distinti, e che occuparsi di entrambe le
cose sia troppo difficile.
