Sviluppo software

Ciao a tutti,
ho una domanda o meglio un dibattito da affrontare. Nel mio lavoro affronto sempre metodi di programmazione differenti, io principalmente programmo PLC e nel tempo libero (sempre poco) mi diletto a programmare i microcontrollori.
Comunque, vedendo lavori sviluppati da vari personaggi, mi sono reso conto che nel mondo del lavoro, manca un metodo di affrontare lo sviluppo di un progetto software, perché trovo spesso e volentieri istruzioni buttate là a caso senza una strutturazione, o meglio dei software che sono come castelli di carta. E quando trovo questi software cerco sempre di metterli a posto e se riesco (il che dipende dal tempo a disposizione) di dargli una struttura. Ma qui sorge il dilemma, io cerco sempre di fare delle funzioni, per ogni singola applicazione, ed in quella funzione c'è tutta la gestione di quel pezzo o movimento. Questo mi permette di analizzare meglio i comportamenti della macchina, in quanto ho tutto sott'occhio. Ma c'è un rovescio della medaglia, e cioè che se c'è un grosso impianto queste funzioni si moltiplicano, quindi è necessario avere un hardware che mi supporta la struttura software.
il mio metodo è intuitivo ed è facile da capire (questo perché me l'ha riferito chi a messo mano sui miei lavori) quindi facile da debuggare, ma ha bisogno di una struttura hardware adeguata.
Per cui vi domando esiste una via di mezzo?
tra il mio modo di sviluppare (molto pesante) e quello molto leggero che utilizza una sola funzione nella quale dentro ci sia tutto (messo in modo ordinato e solido), ma contro c'è il discorso che per debaggare una particolare zona è necessario ricercare le righe di codice all'interno delle x migliaia di righe di tutta la struttura.
Un metodo che si possa esportare nelle varie piattaforme, dai microcontrollori ai PLC, ai linguaggi di alto livello.
E' possibile creare uno standard di sviluppo software, in modo da facilitare a tutti il debug?

grazie e ciao

Ciao Luca,

una regola generale c'e', e personalmente ritengo che sia:

Privilegia la chiarezza all'efficienza.

La chiarezza può portare sistemi indeficienti ma se il sistema e sufficientemente veloce non ci sono problemi.
Solo se la chiarezza crea conflitti con le aspettative (specifiche) finali e' bene ottimizzare.

Chiunque rimette le mani in un codice bene scritto, gioverà della chiarezza e non manderà accidenti al programmatore...e lo ringrazierà.

Non ho mai programmato i PLC per cui non so dove siano i limiti, ma la regola sopra credo sia piuttosto universale.

Algoritmi sofisticati e geniali, li capiscono solo i geni...ma il mondo e' prevalentemente fatto di persone normali, per cui e' bene non fare i geni!

Saluti,

Mauro

mah.. secondo me ogni volta che si legge il codice di un altro ci si deve sempre ragionare su sia che sia scritto bene sia che sia scritto male. Questo perchè ognuno ha un modo suo di pensare e di affrontare i problemi e soprattutto perchè ci sono sempre piu modi per giungere alla stessa soluzione.
Quindi un codice che per me potrebbe sembrare banale e scritto nel modo piu semplice possibile per altri potrebbe essere complicato.

Certamente bisognera´ ragionare su ogni soluzione, ma credo che le soluzioni da evitare siano quelle in cui la nostra testa pensa:

• Questa soluzione e´ geniale...
• Questo e´un modo piu´ "ottimizzato"...
• Certo che sono proprio forte...

Saluti,

Mauro

Concordo pienamente con te Mauro, il fatto che il software sia leggibile e capibile da tutti è la cosa migliore.
Il discorso che ho fatto sulla pesantezza è una mia fissa, nel senso che con le potenzialità che ci sono oggigiorno, non ci sono particolari problemi.

Purtroppo, però, quei tre punti che hai inserito sono nella testa di ognuno di noi quando scriviamo, lo dico perché io stesso ho passato quella fase, nel continuare a dirmi sono grande scrivo software benissimo etc etc, complice anche il fatto che chi mette mano sul software da scritto mi fa i complimenti. quindi il tutto ha alimentato il mio ego, fino a quando è successo il patatrac, e lì ho fatto i conti con me stesso e ho dovuto rivalutare il tutto tornado umile quando scrivo software, dato che non si ha mai finito di imparare.
Per questo ho aperto questo topic per vedere se ci sono nuove frontiere nello sviluppo, ma forse il tema è preso alla larga e per poter fare qualche considerazione è necessario prendere caso per caso.

Luca