Nella mia minuscola esperienza lavorativa, mi sono trovato sempre davanti progetti o applicazioni in cui era più difficile capire come funzionava il tutto piuttosto che studiarsi la trasformata di Laplace! Quello che io mi chiedo sempre più ogni giorno è: ma dove è andata a finire la qualità del software? Possibile che i progetti tenuti bene siano quasi sempre quelli sviluppati da programmatori al di fuori delle aziende? Ma soprattutto quanto costa mettere qualche commento in più? Quanto costa non mettere 400 IF innestati? Quanto costa scrivere un pò di documentazione sana (e soprattutto comprensibile, perchè la documentazione non è un test a chi conosce meglio l'italiano!)
E' vero che comunque in una azienda ci sono progetti da consegnare, quindi le scadenze sono sempre più vicine (e quasi sempre superate...), ma non è meglio perdere 5 minuti per dei commenti, piuttosto che perdere 5 giorni per capire cosa fa un metodo?
Beh questo è il mio pensiero, mi farebbe piacere conoscere anche i vostri pareri a riguardo.
Antonio
Capisc e dotnet tu? No! E allor che parl a fà!
Proprio oggi mi è stato detto "in azienda non ci interessa sperimentare cose nuove, dobbiamo consegnare presto altrimenti il cliente si stanca e ci manda af... "... ti basa come risposta?
Ciao Marco, mi basta per lo meno a convalidare la mia tesi :) !
Non si tratta di sperimentare...si tratta di capire che la documentazione fa parte dello sviluppo del codice. Ma non è solo un problema di documentazione, spesso i commenti interni sono davvero necessari in parti davvero complicate del codice. Si tratta di avere uno standard di programmazione, di usare nomi lunghi ed esplicativi per le variabili, si tratta di dividere il codice in più metodi quando è troppo lungo e fare in modo che il nome del metodo sia autoesplicativo, insomme la lettura del codice dovrebbe essere il più possibile scorrevole, nei limiti del linguaggio di programmazione. Può sembrare stupido ma noi in azienda abbiamo imposto il rispetto di alcune regole di scrittura del codice, quali ad esempio _ per gli attributi privati o protetti, l'utilizzo dei commenti xml che vengono parsati da visual studio in modo da avere il supporto dell'intellisense, ecc...
Per la questione del tempo direri che è vero, come architetto/project manager mi rendo conto delle scadenze e so che il tempo scorre inevitabile, quindi concordo sull'azienda di marco a non sperimentare su progetti con scedenze imminenti, ma sul modo di scrivere il codice basta essere tutti daccordo prima di cominciare!
Mi rendo conto che mi sono espresso male...ho estrapolato una parte di un discorso più ampio che non fa rendere bene l'idea ....in estrema sintesi.....ciò che mi è stato detto è che all'azienda non interessa come è scritto il programma, se bene o male, se risponde ai criteri di ingegneria del software oppure se è stato scritto in unico metodo (passatemi l'assurdotà)...non interessa neanche con quale linguaggio è stato sviluppato....ciò che interessa è che funzioni.....
Io sono il primo che in situazioni critiche non sperimenta tecnolgie nuove ma va sul sicuro....ma sono fermamente convinto che un software "pensato" prima di essere realizzato vive meglio e più a lungo...nell'interesse dell'azienda e del cliente...se si seguono dei criteri il programma funziona...magari come quello prodotto con "spaghetti code"...ma può essere una base solida per sviluppi e nuove implementazioni sullo stesso prodotto...quindi ben vengano convenzioni sui nomi, commenti, una buona architettura...ma il tempo in più che ci vuole a fare questo come si giustifica ? Io ci litigo spesso sul problema...
Non si giustifica, molto semplicemente perchè non si dovrebbe giustificare: è parte del processo di sviluppo.... E' un problema culturale, molto sentito specialmente a Napoli, come in tutto si vive sempre alla giornata. E' pur vero che progettare prima di implementare è un benefit soprattutto per noi che dobbiamo sviluppare e manutenere, il trucco secondo me sta nel cercare di aggirare il problema con un po' di fumo negli occhi, ad esempio cominciando a realizzare prima l'interfaccia...così diamo l'impressione di stare a buon punto quando magari stiamo ancora prototipizzando. L'alternativa vera potrebbero essere le metodologie agili, ma c'è il grosso ostacolo della impossibilità della preventivazione dei costi e del troppo spazio che si da al cliente finale, che potrebbe mettere carne a cuocere continuamente.
Michele Aponte: Non si giustifica, molto semplicemente perchè non si dovrebbe giustificare: è parte del processo di sviluppo.... E' un problema culturale, molto sentito specialmente a Napoli, come in tutto si vive sempre alla giornata. E' pur vero che progettare prima di implementare è un benefit soprattutto per noi che dobbiamo sviluppare e manutenere, il trucco secondo me sta nel cercare di aggirare il problema con un po' di fumo negli occhi, ad esempio cominciando a realizzare prima l'interfaccia...così diamo l'impressione di stare a buon punto quando magari stiamo ancora prototipizzando. L'alternativa vera potrebbero essere le metodologie agili, ma c'è il grosso ostacolo della impossibilità della preventivazione dei costi e del troppo spazio che si da al cliente finale, che potrebbe mettere carne a cuocere continuamente.
Concordo!
Associazione Culturale DotNetCampania - C.F.: 95127870632