The Dark Side of Hardware Upgrade Forum

Come tutti saprete seguo una specialistica di quasi informatica. (Non lo sapete ? Sapevatelo)

In tutta la triennale ci hanno insegnato a fare tonnellate di documentazione prima di programmare, poi usare il RUP. Insomma la Documentazione era DIO.

Poi alla Specia in Architetture Software ci dicono che ora va di moda l'extreme programming, programmazione agile, insomma roba che la documentazione se la infilano su per il c--o.

Contemporaneamente a Project Management ci spiegano che sta moda è passata e si è tornati al vecchio modello consolidato di documentazione. (tutto questo ovviamente non in italia, che si fa spaghetti code, ma in realtà estere).

Io non ci sto capendo piu un cazzo.

Come funziona quindi?

tl;dr Come programmate? documentazione?

Documenta nel codice, va, che è già tanto.... si trova certa monnezza in giro....

Maledetto mambo, adesso questo 3d ha visibilità zero.

E' che io non capisco che cazzo di campana seguire.
Sono ben conscio che in italia è una merda la programmazione... Per questo chiedevo agli esterofag, che è il luogo in cui vorrei andare a parare.


Poi tecnicamente il mio ruolo (quello per il quale esco dalla specia) non è programmatore puro, ma Project Manager di sistemi informativi.

mi hai fatto veramente lollare

"quasi informatica"?

Una merda ma non per colpa dei programmatori. Un paese di avvocati, commercialisti, segretarie ed operai, che se ne fa della programmazione ? di teste, come al solito, ne abbiamo e sono buone (noi per il nostro text-to-speech usiamo http://www.loquendo.com, italiana da quel che m'han detto).

Pensa che nella prima soc. qui in Germania ho trovato del codice allucinante! un ottimo basso livello (progetto wi-fi tutto in C ) ma nessun alto livello, no API... tutto un copia e incolla delle state machines arrivando a switch di 500-1000 righe
Una sera tornato in Italia per vendere casa, senza luce e in taverna per il caldo, al lume di candela e birra fresca ho scritto un sistema state machine basato su una matrice di puntatori a funzioni di libreria. A seconda del ritorno di valore di ogni funzione, un descrittore xml faceva muovere il programma chiamando la successiva casella ovvero puntatore[y][x]... quando son tornato e gli ho fatto vedere il design son rimasti così

e poi m'han licenziato

Per il discorso documentazione, noi usiamo doxygen, documentiamo prevalentemente negli header files ma anche nei cpp in caso di cose complesse. Nei momenti di tranquillità, come adesso, documentiamo usando wiki che è una figata.

documentazione

che intendete di preciso?

Descrivere, in inglese possibilmente, cosa fa un progetto, programma, classe, funzione, variabile.

Ringraziami per aver dato visibilità al 3d.

Già, mi ricordo, tu sei il "responsabile collegamenti tra 3ds"... non te ne sfugge uno

A qualcosa servi anche tu

Grazie per la visibilità.
Sono strafottuto con l'uni che non ho avuto modo di seguire il 3d

Quindi un po di documentazione c'è anche da voi, ma vedo che non mi parli di doc pre-programmazione. (scelte architetturali, pacchi di UML, ecc. ecc.)

Questo è a causa di gente che non ha studiato all'università informatica e pretende di fare il programmatore


















Problem trallalero?



Grazie per la risposta.

Non c'è un metodo giusto per lavorare ma bisogna sapersi adattare alle circostanze/esigenze.

Quando ho risolto il problema "no api" della prima società, l'ho fatto prima con carta e penna (idee, flowchart, etc), trascritto su doc al pc, scritto il codice, testato e poi presentato alla soc... come da manuale. Ma perché ho usato strumenti che conoscevo benissimo (in pratica solo il linguaggio C).

Ovvio che l'ideale sarebbe usare sempre questo metodo ma non sempre è possibile.

Infatti appena assunto da questa soc., ho lavorato per un progetto enorme ed io ero quello responsabile della logica/comunicazione della simulazione militare. Abbiamo lavorato con strumenti ed hardware di cui non conoscevamo le specifiche quindi non potevamo fare tutto il design prima di scrivere il codice. Suona male, ma siamo andati un po' a tentoni aggiustando design/codice strada facendo.

Poi son diventato responsabile delle gui della soc... adesso tutte le gui della soc sono create con un programma a pluguins di mia invenzione, ma per farlo ho avuto bisogno di sperimentare, studiare, in pratica tentare.
Il design l'ho scritto dopo su wiki perché prima, non conoscendo l'argomento plugins, non sarebbe stato possibile.

Comunque documentazione pre-programmazione c'è e ce n'è tanta (scelte architetturali, ect) ma non sono io a scriverla. Per quello c'è il team leader, mister no-life

La documentazione non esiste.
Il codice e' il documento che dobbiamo produrre, come gli ingegneri civili producono i progetti di un ponte il nostro progetto e' il codice.
Poi sta al compilatore trasformarlo in un eseguibile, come sta ai manovali trasformare il progetto dell'ingegnere in un ponte.
Inutile dire che per questo motivo il codice DEVE essere ben scritto e comprensibilissimo da chiunque, altrimenti e' SHIT.

My ambition

ah allora da noi non si usa (ne scrivere in inglese ne documentare )

Ok da parte tua c'è un Agile Fan. Che il mio prof di Project Management dice essere "una moda passata che non troverete mai in ambito aziendale"

Ci capisco piu un cazzo

Diventare mister no-life è la tua ambition ?

No women, no beers, no hobbies... no life



Maccheccazzo dici ?

Vedo che non sono il solo ad avere una leggera confusione in ambito development

*
Come dire progetto una casa, ma non lascio uno straccio di foglio per dire dove passano le condutture e come è fatto l'impianto...

Meglio buttarla giù in caso di riparazioni che cercare dove mettere le mani.

Discorso applicabile per qualunque cosa, ancora più valido se il lavoro finale è qualcosa fatto in gruppo.

2-1 per la documentazione.

palla al centro

Neppure io son un fan della documentazione, ma se fai qualcosa che poi qualcuno deve riprendere (o anche solqmente potrebbe riprendere) è d'obbligo lasciare qualcosa di comprensibile e qualche riga di commento.

Oggi ho passato il pomeriggio a scrivere la doc per un test chip. Già solo lasciare un foglio che dice con quali versioni di software l'ho disegnato è un grande aiuto se fra 2 mesi ci devo rimettere mano.

Appunto, a nessuno piace molto documentare ma se fai un server che è un client per un altro processo in un progetto costituito da una catena client-server su un sistema linux-windows, vorrai lasciare 2 righe che spiegano almeno come viene configurato e fatto partire il tutto ?

Proprio ieri, visto che stiamo creando un nuovo build system, ho dovuto rimettere mani sul mio primo progetto fatto qui. Ho dovuto leggere il README perché non ricordavo niente. Che poi il progetto dipende da altri progetti infatti ho dovuto rileggere anche le varie dipendenze e versioni VCS (bazaar) che per fortuna avevo lasciato scritto, altrimenti sarei stato fottuto.



Probabilmente Tigershark è un muratore