riflessioni personali: organizzazione e metodi di lavoro

[The3DProgrammer]

Originariamente inviato da fek

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

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

quoto

x curiosità, dove ti sei laureato?

[repne scasb]

Originariamente inviato da fek

e le donne non devono costruire software

Originariamente inviato da jappilas

stessa nozione che mi ha inculcato avere una donna a Fondamenti d' Informatica II

Originariamente inviato da 71104

le donne che programmano fanno ridere

Originariamente inviato da 71104

prova a leggere i sorgenti scritti da una donna, fanno ridere per davvero

Originariamente inviato da 71104

la mia esercitatrice di Algoritmi 1 è una perfetta scema

Originariamente inviato da 71104

si vede benissimo che è na sega

Originariamente inviato da The3DProgrammer

quoto

Tutto molto offensivo.

[fek]

Anche solo molto ironico. Non rovinare questo topic perche' e' interessantissimo.

[cionci]

Io conosco anche donne che porgrammano molto bene... Probabilmente è anche una questione derivante dal fatto che il pensiero femminile è organizzato in maniera diversa da quello maschile...e per questo, secondo uno studio, i maschi sono superiori in certi campi e le donne in altri...

[Elentari]

Originariamente inviato da repne scasb

Tutto molto offensivo.

Non c'è nulla di offensivo invece. Io sono una donna, sono laureata in ingegneria elettronica, ho anche preso 30 in un esame di informatica ma.. non so programmare. Non mi piace. Non ci sono portata.

E secondo me le donne in generale non sono portate a programmare.

[cionci]

Elentari: conosci fek ? Ti ho chiesto questo perchè dalla location sembrate molto vicini

[jappilas]

Originariamente inviato da repne scasb

Tutto molto offensivo.

Ho avuto una docente che effettivamente ignorava quello che pretendeva di insegnare (programmazione C, C++, assembly e Smalltalk applicate con metodologia indistinta), che cercava di imporre agli allievi metodi e costrutti che regolamente si rivelavano errati
Tra tutti quelli che hanno seguito con quella docente, quasi tutti hanno dovuto studiare programmazione per conto proprio, anche reimparando da zero, scrollandosi di dosso i preconcetti inculcati da un corso che apparteneva a quelli di primi anni (e il primo e secondo anno sono quelli che ho avvertito operare maggior imprinting sulla forma mentis dello studente)
All' epoca (6 anni fa) mi convinsi di aver subito un danno (pago per ricevere una formazione e quello che viene fatto passare per dogma di fede si rivela inesatto e inconsistente ) e sperai che quello rimanesse un caso isolato
in un certo senso lo è rimasto (e mi scuso per il post che appare una generalizzazione sarcastica, voleva essere amara ironia)... però tra le persone aventi dimestichezza con la programmazione, che ho incrociato (scope maggiore di "conosciuto"), rientrano poche donne, e quelle poche, quasi tutte studentesse motivate (tra l' altro, quando entrai le ragazze a seguire quei corsi erano mosche bianche), nessuna docente, quindi della mia età o più giovani...
una sola persona di età maggiore della mia, e l' unica con una profonda conoscenza dell' assembly itanium, l' ho incontrata su un forum e ne ho grande ammirazione...

[71104]

Originariamente inviato da repne scasb

Tutto molto offensivo.

tranquilla/o, non era riferito a te, non ti considero una donna un robot più che altro

[71104]

Originariamente inviato da cionci

Io conosco anche donne che porgrammano molto bene... Probabilmente è anche una questione derivante dal fatto che il pensiero femminile è organizzato in maniera diversa da quello maschile...e per questo, secondo uno studio, i maschi sono superiori in certi campi e le donne in altri...

<OT>infatti hai centrato il punto fondamentale, io la penso esattamente così come hai detto tu: il pensiero maschile è diverso da quello femminile, e dipende dagli ormoni (NB: non esistono solo ormoni sessuali: gli ormoni sono sostanze che regolano il funzionamento di tutto il nostro corpo). in generale per esperienza posso dirti che secondo me mentre gli uomini hanno maggiormente sviluppata una intelligenza di tipo razionale, le donne sono più intelligenti dal punto di vista sociale: sono più brave a comunicare; non a caso nelle superiori le insegnanti sono praticamente tutte donne.</OT>

[fek]

Originariamente inviato da cionci

Elentari: conosci fek ? Ti ho chiesto questo perchè dalla location sembrate molto vicini

Abbastanza vicini

Originariamente inviato da 71104

<OT>infatti hai centrato il punto fondamentale, io la penso esattamente così come hai detto tu: il pensiero maschile è diverso da quello femminile, e dipende dagli ormoni (NB: non esistono solo ormoni sessuali: gli ormoni sono sostanze che regolano il funzionamento di tutto il nostro corpo). in generale per esperienza posso dirti che secondo me mentre gli uomini hanno maggiormente sviluppata una intelligenza di tipo razionale, le donne sono più intelligenti dal punto di vista sociale: sono più brave a comunicare; non a caso nelle superiori le insegnanti sono praticamente tutte donne.</OT>

Pienamente d'accordo, uomini e donne sono diversi, hanno attitudini diverse e riescono al meglio in compiti diversi, spesso complementari. E' una cosa perfettamente naturale e non c'e' nulla di negativo. Ovviamente si fanno discorsi di media, c'e' sempre la proverbiale eccezione che conferma la regola.

Eccezione che io pero' in 15 anni non ho mai incontrato: non ho mai visto una donna scrivere buon codice leggibile e ben strutturato.

[PFed]

Originariamente inviato da 71104

la mia esercitatrice di Algoritmi 1 è una perfetta scema che dice che alle sue lezioni lei programma in pseudocodice perché non vuole perdere tempo a ragionare sulla sintassi del C

E a mio parere ha perfettamente ragione.

In un corso di ALGORITMI lo scopo ultimo e far comprendere a fondo il funzionamento degli algoritmi studiati.

Lo studente si deve concentrare su questi, e non sulla sintassi del C.

[PFed]

Io ho avuto un'insegnate alle superiori che ci ha insegnato alla perfezione le basi dell'informatica, la programmazione procedurale (attraverso il Pascal), e gli algoritmi fondamentali.

Dopo anni e anni di esperienza devo dire che spesso e volentieri vado avanti agevolmente grazie alla forma mentis e alla metodologia con cui ci ha forgiato.

E verò però il fatto (anche se non so perchè, probabilmente valida la spiegazione di cionci) che le persone valide, nel mondo della programmazione, siano in maggioranza maschi.

[71104]

Originariamente inviato da PFed

E a mio parere ha perfettamente ragione.

In un corso di ALGORITMI lo scopo ultimo e far comprendere a fondo il funzionamento degli algoritmi studiati.

Lo studente si deve concentrare su questi, e non sulla sintassi del C.

a ogni modo dovrebbe ragionare sulla sintassi del suo pseudolinguaggio, e si vede benissimo che non lo fa la sintassi cambia da una riga all'altra
in questo modo tavolta si creano persino delle ambiguità sul significato del programma
e potrebbe anche avere ragione sull'uso dello pseudolinguaggio (imho no però) ma fermo rimane che è scema
e non dico che tutte le donne lo sono: ci sono le oche bone e sceme e ci sono le ragazze carine e intelligenti (e poi ci sono anche quelle brutte e pure sceme, ma spesso non si considerano nemmeno ragazze ); la mia prof non è intelligente, sorry

[fek]

Puntuale un articolo sull'argomento del topic:

http://msdn.microsoft.com/msdnmag/is...meProgramming/

TDD e Design Evolutivo, da leggere tutto d'un fiato.

[Giakino]

Domanda:
Riguardo a qualcosa con una GUI, prendiamo in esempio una banalissima calcolatrice.
Come partite?
Io ho fatto così, prima di tutto mi sono creato dei pulsanti messi a caso nella form per poter testare la base (addizione tra due numeri, l'evento del pulsante che richiama una classe esterna in cui sono presenti le operazioni e simili), fatto questo e dopo aver visto il corretto funzionamento sono passato al resto (- * / e gli altri numeri) per poi concludere e mettere a posto (graficamente) le cose
Voi come avreste fatto?
Cioè, sareste partiti direttamente a fare tutto da codice (anche il minimo pulsante) oppure avreste utilizzato le cose a disposizione? Prima il funzionamento o prima l'aspetto "esteriore" ?
Sono curioso perchè i tre prof che ho dicono TUTTI di partire a mettere bene a posto graficamente la GUI per poi passare al funzionamento, cosa imho completamente sbagliata Imho meglio far andare e poi mettere a posto, tanto per quello (se si usa quanto a disposizione) per creare dei pulsanti e usare funzioni/classi già create ci vuole poco

[fek]

E' giusto quello che hai fatto tu. Separa la parte di logica che fa le operazioni dalla GUI e testa la logica separatamente. Poi usa un oggetto che "traduce" comandi ed eventi della GUI in comandi ed eventi per la tua logica; poi incanala la GUI in questo oggetto. Cosi' puoi testare la logica anche senza avere una GUI di test.

Infine metti a posto la GUI esteticamente, ma e' solo l'ultimissima cosa. Ma che razza di professori hai?

[71104]

comunque l'esempio che hai fatto tu (quello della calcolatrice) era banale: per sviluppare una calcolatrice non serve certo una metodologia ferrea!

Originariamente inviato da fek

Ma che razza di professori hai?

e perché io allora?

[jappilas]

Originariamente inviato da Giakino

Domanda:
Riguardo a qualcosa con una GUI, prendiamo in esempio una banalissima calcolatrice.
Come partite?
Io ho fatto così, prima di tutto mi sono creato dei pulsanti messi a caso nella form per poter testare la base (addizione tra due numeri, l'evento del pulsante che richiama una classe esterna in cui sono presenti le operazioni e simili), fatto questo e dopo aver visto il corretto funzionamento sono passato al resto (- * / e gli altri numeri) per poi concludere e mettere a posto (graficamente) le cose
Voi come avreste fatto?
Cioè, sareste partiti direttamente a fare tutto da codice (anche il minimo pulsante) oppure avreste utilizzato le cose a disposizione? Prima il funzionamento o prima l'aspetto "esteriore" ?
Sono curioso perchè i tre prof che ho dicono TUTTI di partire a mettere bene a posto graficamente la GUI per poi passare al funzionamento, cosa imho completamente sbagliata Imho meglio far andare e poi mettere a posto, tanto per quello (se si usa quanto a disposizione) per creare dei pulsanti e usare funzioni/classi già create ci vuole poco

presta attenzione perchè è una questione un po' a tranello...
gli sviluppatori a volte ci "cadono", quando pensano che il loro SW sarà usato solo da altri sviluppatori o da... loro stessi, e "l' importante è che funzioni, dell' aspetto esteriore o se la sequenza di azioni e dialog box è poco consistente, chissene"... ricordo ancora che parecchi progetti open source dimostravano di aver seguto un approccio simile, funzionando (più o meno) ma risultando di scarsa usabilità

l' esempio della calcolatrice imho non è atto a esemplificare la differenza in termini di approccio tra "curare l' interfaccia" vs "curare il codice": una calcolatrice con le 4 operazioni associa praticamente una funzione ad ogni pulsante, in una singola finestra contenitore, e c'è praticamente un solo stato (waiting_for_input), quindi l' unico problema è effettivamente l' allineamento dei pulsanti (che si aggiusta in un paio di secondi in un GUI editor):

se avessi dovuto creare ex novo un' applicazione più seria, avresti dovuto cercare di mantenere il più possibile separate logica e interfaccia (lato estetico) del programma, però tenendo conto dei casi in cui magari l' interfaccia stessa o altre parti risentono della modalità operativa, impostata in qualche variabile, o l' utente debba seguire determinati passi per compiere un' azione, in una sequenza di dialog box in cui cliccare, eccetera,
in quel caso mi vedresti preparare un mockup strutturale prima o durante la stesura preliminare del codice
il mockup avrebbe il solo scopo di testare la congruità interna ed esterna del programma e dell' interfaccia (più che da un punto di vista estetico, da quello delle modalità e sequenze operative, la cui definizione inficia il design del codice sconfinando nel suo dominio)

[Ozn ZzZ]

Originariamente inviato da fek

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



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

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



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

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




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



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

Purtroppo per ora posso attaccarmi solo a quanto leggo sui libri e a quello che mi "propinano" i docenti di ingegneria.
Non ti nascondo che a me UML piace moltissimo,ma se mi trovo qui a discutere e' anche per sentire ,chi magari ,ha gia toccato con mano queste problematiche in ambito lavorativo.
Dal punto di vista "accademico" in UML vedo la possibilita' di spaccare il capello in 4 e di non lasciare nulla al caso.
Vi seguiro' con interesse in queste discussioni

[fek]

Originariamente inviato da Ozn ZzZ

Purtroppo per ora posso attaccarmi solo a quanto leggo sui libri e a quello che mi "propinano" i docenti di ingegneria.
Non ti nascondo che a me UML piace moltissimo,ma se mi trovo qui a discutere e' anche per sentire ,chi magari ,ha gia toccato con mano queste problematiche in ambito lavorativo.
Dal punto di vista "accademico" in UML vedo la possibilita' di spaccare il capello in 4 e di non lasciare nulla al caso.
Vi seguiro' con interesse in queste discussioni

Ma nessuno discute UML, anzi. Martin Fowler che e' uno dei piu' importanti propositori di metodologie agili, e' anche uno dei piu' grandi esperti di UML.

Il problema dei professori all'Universita' e' il non aver mai scritto software (a parte pochissime rare eccezioni), quindi non conoscono di fatto le metodologie che in pratica si rivelano piu' o meno efficaci. Scrivere tutta la documentazione in UML in maniera formare per mesi e' perfetto a livello "accademico" e in teoria funziona perfettamente se i requisiti sono perfettamente stabili e chiari. Ma nel mondo reale dello sviluppo i requsiti non sono ne' stabili, cambiano a ritmi vertiginosi, ne' chiari, il cliente neppure spesso sa quello che vuole fino a che non lo vede.

Quindi, in ambienti di sviluppo reali, le metodologie teoriche semplicemente non funzionano e non sono produttive. Lo scoprirai quando entrerai in un ambiente di lavoro reale.

Questo vuol dire che nessuno usa metodologie di sviluppo basate su documentazione formale con successo? No. La NASA usa quasi solo metodologie di questo tipo per sviluppare il software delle sonde, o degli shuttle, ad esempio. Possono perche' loro hanno requisiti stabili e sono il loro cliente. Quindi possono scrivere tutta la documentazione prima, verificarla formalmente e poi passare allo sviluppo. Quello che scrivono deve essere "nearly zero defects". Sviluppare cosi' costa tantissimo, ma la NASA puo' permetterselo.