• Als Spam markieren
• Beitrag melden

• 
  Diese Gruppe Alles

• Archiv
• RSS-Feeds

• Kontakt
• Hilfe
• Impressum
• Datenschutz

Re: Trovare bravi analisti e sviluppatori ICT

=> ispas [060107 16:17]:

> Gabriele Lana ha scritto:
>
>> La creazione del software con le aziende manifatturiere o con la produzione
>> industriale non ha niente a che fare, e' un'attivita' creativa per definizione
>
> Non sono d'accordo. Progettare bene un oggetto meccanico, oppure un palazzo,
è
> un'attività creativa tanto quanto scrivere l'ennesimo programma di
> lettura/aggiornamento db.

Scusa, effettivamente la frase e' approssimata (come tutto il resto), intendevo
dire che a differenza del manifaturiero/industriale dove c'e' una parte di
progetto (attivita' creativa) ed una di processo (attivita' meccanica), nel
mondo del software esiste solo la parte progettuale, finche' non si ha una
specifica formale (codice sorgente o equivalente) si e' sempre nella fase di
progettazione

> La creatività vuol dire far cose nuove, non replicare cose già fatte.
> E nel software si replica tanto quanto in altri settori.

Non ho capito bene il tuo punto, il mio punto e' che se nel software si ha
necessita' di replicare qualcosa, questa attivita' *deve* essere svolta dai
computer, e quindi la necessita' di attivita' di basso profilo sono indice di
incompetenza in quanto automatizzabili con un'attivita' di profilo superiore

>> L'unica vera specifica del software e' il suo *codice sorgente*,
>
> Sono abbastanza d'accordo per il software esistente e da modificare, non per
> quello da progettare e realizzare (o rifare) da zero. Il quale non esistendo
> non documenta un bel niente.

Quindi il codice sorgente e' la specifica, ma solo se esiste, altrimenti no?

Io non sono per il "Cowboy Coding"[*], penso che non sia efficace/efficiente
separare l'attivita' di analisi/progettazione dall'attivita' di sviluppo

Quando fare analisi? Sempre! Feedback immediato dal cliente, prova diretta sul
campo o simulata, implementazione verticale del prodotto (massimo entro le prime
due settimane si deve avere qualcosa di funzionante da provare), misurazione
continua del raggiungimento degli obiettivi del cliente, ecc...

Quando fare progettazione? Sempre! Il codice per sua stessa natura e
intrinsecamente malleabile, sono le metodologie ingegneristiche/predittive che
ci hanno portato al codice "Write Only", ovvero a codice con costi altissimi di
manutenzione modifica, questo non significa che deve essere cosi'.

E' possibile definire quello che si vuole implementare (obiettivo) attraverso
dei test, scrivere il codice per superare i test, verificare la qualita' del
codice scritto ed eventualmente migliorala, questo continuamente (stiamo
parlando di cicli che durano pochi minuti)

Per non dilungarmi indico due riferimenti
http://c2.com/cgi/wiki?WhatIsRefactoring
http://www.martinfowler.com/articles/newMethodology.html
(sopratutto il paragrafo "Predictive versus Adaptive" se avete poco tempo)


> C'è viceversa una differenza fondamentale: in informatica se sbagli, molto
> spesso, non succede nulla (apparentemente). Ctrl-alt-canc e via.  Se invece
> sbagli a progettare un palazzo, e questo cade.....Non hai il backup di quelli
> che stavano dentro al palazzo :-) In realtà anche in informatica lo sbaglio
> costa, ma in un modo meno evidente, e chi è impreparato alla gestione non se
> ne accorge. Perciò molti pensano proprio così: scrivo subito codice,
tanto se
> non funziona (99,99% dei casi) lo correggo. E lo rifanno 100 volte. E poi i
> progetti costano 100 volte tanto... ah ah!!

E invece cosa ti fa credere di riuscire a progettare qualcosa correttamente al
primo colpo? Chi ti dice che chi implementera' quello che tu hai descritto lo
implementera' come tu lo hai pensato? Chi ti dice che i requisiti del progetto o
gli obiettivi del cliente sui quali hai modellato *oggi* la tua applicazione
non saranno cambiati quando l'applicazione sara' terminata?

>> Quelle che tu chiami specifiche, sono descrizioni non formali, ovvero scritte
in
>> linguaggi semanticamente non ben definiti, possono essere tradotte in
>> specifiche formali (codice sorgente) in infiniti modi e senza la possibilita'
di
>> veficare se la traduzione conserva la semantica, le specifiche iniziali
>> rispetto a quelle finali, valgono *zero*
>
> 1) Gli infiniti modi di traduzione esistono pure negli altri ambiti.  Tutti i
> motori sono uguali? Tutti i palazzi sono uguali? Eppure nessuno si sogna di
> non fare studi di fattibilità e progettazionee

Ripeto quello che ho detto prima, non sto dicendo di non fare progettazione, sto
dicendo di fare progettazione direttamente sul codice, quello che tu chiami
disegnare un pezzo di apparecchio meccanico, io lo chiamo scrivere una classe

Il codice sono le specifiche

> 2) le specifiche di analisi *non* sono progettazione. Quest'ultima segue
> l'analisi, e deve tradurre quelle specifiche in un singolo modo, tra tutti gli
> infiniti possibili

Come fai a sapere se le stai traducendo nel modo corretto? E secondo te in
questo caso cosa significa corretto?

> 3) sono abbastanza d'accordo che in informatica manca a tutt'oggi un insieme
> di strumenti di progettazione validi quanto quelli degli altri. Ma non è un
> buon motivo per non fare neppure 2 fogli di analisi/progettazione.

Se servono a te o al tuo team per scrivere codice migliore, ne puoi fare anche
100 di fogli di analisi/progettazione, la cosa importante e' non scrivere quei
fogli con la pretesa di darli a qualcun'altro affiche' facciano per te il tuo
lavoro

[*] http://en.wikipedia.org/wiki/Cowboy_coding

--
Gabriele Lana
http://milano-xpug.pbwiki.com/

Antworten