Newsgroup: it.comp.lang.c++
Titolo: lettera aperta...

Sono ormai 3 anni che lavoro su progetti sw industriali in c/c++.
Per interderci si tratta di progetti "su larga scala": decine di
migliaia di
linee di codice, grossi team di programmatori ecc. ecc.
Fino ad ora ho partecipato a 2 di questi progetti ed entrambi, chi piu'
e chi
meno hanno queste caratteristiche:
1) Codice misto c/c++
2) Nelle parti c++ il codice e' un c con classi, quindi: niente c++
standard
   library, niente eccezioni, spesso niente template.
3) Il codice presenta scarsissime potenzialita' di riuso e
estendibilita',
   anche la manutenzione e' molto difficile.
4) Molto spesso piuttosto che riscrivere qualcosa si tenta di adattare
una
   architettura obsoleta ad una nuova situazione con costi (secondo me)
enormi
   in termini di stabilizzazione del codice.
Mi rendo conto che realisticamente non e' possibile che progetti di
questo
tipo possano avere un codice pulito, facilmente manutenibile ecc. ecc.
ma
neanche che siano cosi' tanto lontano dalle promesse del c++ e della
programmazione OO.
Inutile dire che partecipare a questo genere di progetti e' davvero
frustrante, soprattutto a causa dello sforzo per stabilizzare il codice
(risolvere bachi).
La mia domande sono queste: esistono in Italia e nel mondo , o sono
esistite,
delle realta' in cui, almeno in parte, si tende a produrre sw "su larga
scala"
un minimo riusabile estendibile e manutenibile?
Le promesse della programmazione c++ OO sono applicate nel reale o sono
solo
lettera morta?
Saluti a tutto il NG,
Cesare

scala" un minimo riusabile estendibile e manutenibile?
Certo che esistono.  Tieni però presente una cosa: la tua situazione è
molto più comune che non quest'ultima.  I fattori da considerare sono
tanti: l'oggettiva complessità del linguaggio, che tende a far
rannicchiare i programmatori nel loro angolo e ad usare codice che
somiglia più al vecchio C, che non al nuovo C++ (per la serie: "tanto
riesco a fare le stesse cose"), o anche il fatto che non ci sono mai
(o quasi mai) delle figure precise che progettano e delle figure
precise che usano il codice progettato.  Io credo che l'attività dei
programmatori si possa dividere in "programmatori server" e
"programmatori client".  I primi sono quelli che si occupano della
progettazione e manutenzione, ad esempio, di una gerarchia di classi,
i client la usano (e fanno solo quello).  Comunque, c'è da aggiungere
che sviluppare software è oggettivamente molto difficile, specie su
larga scala; se il numero di programmatori in un team è compreso tra 2
e 8 e i progetti sono medio/piccoli, si può pensare di adottare delle
regole di XP (eXtreme Programming).  Queste ultime possono aiutare
molto.  Non so quanto siano applicabili al tuo caso.
-- 
Andrea Laforgia
#exclude <windows.h>

 nel reale o sono solo lettera morta?
L'OO da solo non si adopera molto. Tipicamente, si fa OO mescolato con
programmazione generica e tradizionale.
Claudio Puviani

 sono puliti, manutenibili, estensibili, ecc.
Beato te ! Non dico che il codice che trovo io e' non mantenibile, ma in
quanto
a cose che si possono migliorare c'e' solo l'imbarazzo della scelta.
Il problema e che di solito i tempi sono talmente stretti che tutte le
eventuali
migliorie di contorno (o almeno viste come tali), vengono di solito
rimandate se non addirittura affondate da qualche prj.manager.
IMHO il fattore tempo e umano e' quello piu' critico.
Saluti

 rimandate se non addirittura affondate da qualche prj.manager.
Concordo con te...
Se il project manager vuole un progetto pulito i programmatori lo faranno
pulito. Se il prj.manager non e' interessato a queste cose, fare codice
pulito significa andargli contro. A volte anche quando il prj.manager e'
interessato a fare codice C++ pulito e riutilizzabile, beh, stakeholders
molto importanti come i direttori della compagnia (di solito piu' anziani e
fuori da queste cose) potrebbero fargli cambiare idea....
Tommy

 molto.  Non so quanto siano applicabili al tuo caso.
Hai centrato il problema, mancano le figure di programmatori "server"
e "client" infatti io mi aspetterei che in questi progetti ci fosse
una parte di sw "core" ben pensata a cui i client possano appoggiarsi
per sviluppare delle situazioni "ad hoc".
Ovviamente il core deve avere dei requisiti di qualita' vicini
all'ottimo, gli strati periferici possono essere affidati a
programmatori piu' giovani (i client) con requisiti di qualita'
rilassati. La periferia puo' cambiare spesso ed e' la parte su cui si
lavora di piu', ma il core dovrebbe cambiare poco o almeno i sui
cambiamenti
dovrebbero riflettersi poco sulla periferia.
Invece quello succede e' che ogni volta che bisogna inserire una feature
o risolvere un baco e' un bagno di sangue.
XP? Ho letto tutto il sito d'un fiato per scoprire quanto sono lontano
da lavorare in quel modo.
Comunque grazie per la risposta. Penso di aver capito che la mia
situazione
e' la piu' comune.
Ciao,
Cesare

 Mi sembra che la frustrazione abbia fonte altrove che nel C++...
Il problema e' che il C++ con la programmazione OO, generica e
procedurale promette molto ma mantiene poco.
Non e' un problema del C++ intendiamoci ma di come viene usato.
Solo che siccome il C++ promettette molto, viene usato molto
ma viene (quasi) sempre usato male.
In un progetto a cui ho partecipato si e' partiti da un codice
mal pensato e ci sono stati 7 mesi di sviluppo partendo da quello.
Poi c'e' stato un anno di stabilizzazione a cui i "pensatori
iniziali" hanno partecipato poco: insomma faccio la frittata
e poi se la vedono gli altri, tra cui io.
Tu non saresti frustrato?
Ciao,
Cesare

 a cose che si possono migliorare c'e' solo l'imbarazzo della scelta.
Hai tutta la mia solidarieta'.
Ciao,
Cesare

situazione e' la piu' comune.
Il che, perň, deve spingerti a migliorare, non ad adagiarti.
Le metodologie XP nascono proprio dal fallimento di alcuni progetti
(vedi la creazione del programma di paghe della Chrysler).


 #exclude <windows.h>
complimenti andrea per la preparazione, spesso mi stupisci :)

 un minimo riusabile estendibile e manutenibile?
Sě, esistono.
Una la coordino io. :)
Ciao
Azathot

 e poi se la vedono gli altri, tra cui io.
Concordo.
A ragion del vero devo dire che ho anche visto situazioni in cui le
specifiche
iniziali venivano cambiate a volo quando in sw era gia' quasi gia' fatto a
dispiacere
degli stessi sviluppatori iniziali che si rendevano conto che il loro stesso
codice
a quel punto non corrispondeva.
Che fare ?
Saluti

 wrote in message
news:ICv_9.68291$ZE.18...@twister2.libero.it...

Che fare? Facile.
Randellate, randellate, randellate.
Con un bastone morbido, cosi' prendi chi di dovere e gliene puoi dare di
piu'.
Mi tocca farlo tutti i giorni ;_;


Quando sono andato in Svezia per i miei 15 mesi di esperienza alla Ericsson,
ovviamente le cose erano meglio organizzate e c'era molta piu'
documentazione in fase di progettazione e prima di mettere mano al codice.
Solo che ancora non era stato introdotto l'UML, almeno nel mio dipartimento.
Qua in Francia al contrario, ora il C++ viene visto come strettamente
collegato alla progettazione ed alla concezione del software con l'aiuto
dell'UML, almeno nelle grandi ditte.
E' dato molto piu' valore alla qualita' del software, alla sua concezione,
qua viene molto valorizzato quello che loro chiamano "cycle en V", che in
effetti e' tutto cio' che avevo descritto prima (dall'analisi dei requisiti,
alla descrizione funzionale alla fase di test).
Per cui uno sviluppatore C++ viene sempre visto , in teoria, come
conoscitore dell'UML.
Sara' per questo che dovro' studiarmelo....
Maurus

 (vedi la creazione del programma di paghe della Chrysler).
Io ci provo leggendo articoli, libri, ma e' una cosa abbastanza
sterile secondo me se poi non applico nel lavoro quotidiano quello
che leggo. Non pensi? Hai dei consigli?
grazie,
Cesare

 Sara' per questo che dovro' studiarmelo....
Ok. Come ci si trasferisce in Francia?
Ciao,
Cesare


L'idea sarebbe scrivere un codice in cui cambiare dei dettagli non
comporta
stravolgimenti. Solo che farlo e' difficilissimo, serve tempo e i
manager
non hanno sensibilita' su questi aspetti o, a volte, sono poco
competenti.
Ciao,
Cesare


Vai a farti un giro su it.lavoro.informatica e guarda i post, capirai che
chi adesso ha un lavoro e' meglio che se lo tenga stretto. Europa E Usa
compresi.
Spadroneggiano capolarato di BodyRental (SSII in Francia), Cococo (Italia),
Societa' di consulenza e affini.
La realta' e' un'altra rispetto alla teoria di come dovrebbe essere
sviluppato un progetto.
Adesso vige l'emergenza lavoro.
Maurus

 Mi tocca farlo tutti i giorni ;_;
Mmhh... potrebbe essere un'idea.
Una volta ho sentito che i giapponesi mettevano a disposizione del
dipendente dei manichini-manager su cui sfogarsi.
:)
Ciao,
Cesare