Le leggi di Lehman sull'evoluzione del software

[DragoRosso]

Leggete questo articolo e vedete si vi rispecchiate.

https://www.danieleteti.it/post/lehmans-laws-software-evolution-it/

Quoto un tratto che mi ha colpito ... perchè è proprio così che funziona.

Il checkout di una startup nasce come un’unica funzione pulita. Il marketing vuole un percorso per i codici promozionali, e così si aggiunge un if. Poi un percorso per le fatture B2B. Poi uno per le gift card. Poi le eccezioni fiscali regionali. Diciotto mesi dopo, quella funzione è di 600 righe con 40 flag che interagiscono tra loro, e ogni modifica rischia di rompere un percorso che nessuno ricorda più.

[bonmario]

Faccio il programmatore da 30 anni, ho lavorato a 5 o 6 progetti e, ogni volta, è successo esattamente quello 

[DragoRosso]

Io faccio il programmatore da oltre 40 anni, e ho sviluppato personalmente centinaia di progetti e seguito sicuramente altrettanti.

Progetti nati e li rimasti, progetti che hanno continuato ad evolversi, progetti che si sono trasformati (che è diverso da evolversi) ....

Nel tempo di comune è proprio quel fatto, e l'unica cosa che è migliorata è che se all'inzio (40 anni fà) dopo le prime due modifiche il tutto già era in quelle condizioni (n. if con flag senza molte spiegazioni) adesso per sei mesi diciamo che una logica ancora regge, per poi crollare e diventare un guazzabuglio subito dopo.

Tendenzialmente io dopo un pò termino i progetti (e li mantengo aggiornati solo per quello che riguarda la compilazione con le nuove versioni di compilatori) e riparto con dei nuovi riprendendo quelli vecchi con molta ma molta pulizia.

Poi dopo avere testato sul campo la funzionalità aggiorno anche i clienti vecchi con i nuovi progetti, abbandonando definitivamente le "vecchie storie".

Ma tipicamente di questi non ce ne sono più di una decina, è difficle che un "filone" (o mercato che dir si voglia) regga il tempo , per vari motivi.

[Lorenzo]

Io mi preoccupo di commentare bene il codice.

Non so se capita a voi,spesso un progetto lo metto da parte(alcuni li abbandono completamente).
Ma quando riprendo un progetto,è come se il codice che ho scritto io stesso,lo avesse scritto un altro programmatore.
Che abbia scritto io il codice o qualcun altro,per me diventa la stessa cosa.

[DragoRosso]

Io mi preoccupo di commentare bene il codice.

Non so se capita a voi,spesso un progetto lo metto da parte(alcuni li abbandono completamente).
Ma quando riprendo un progetto,è come se il codice che ho scritto io stesso,lo avesse scritto un altro programmatore.
Che abbia scritto io il codice o qualcun altro,per me diventa la stessa cosa.

Si, capita normalmente. E non ho trovato la bacchetta magica per risolvere la situazione.

Il problema è che al momento tutto è chiaro e scrivi i commenti sulla base di questo.
Cioè non è che scrivi perchè l'acqua è diventata calda ... è normale che sia così ad un certo punto. Poi prendi il mano di nuovo il tutto e ti chiedi:

"ma scrivere il perchè l'acuqa è calda sarabbe stato utile ... ora devo spulcaire tra il codice e capire il perchè ...."

ovviamente con una serire di improperi che se non viene giù la Madonna a darti due manate è una fortuna.

Io commento non solo il codice, ma anche ogni singola variabile, proprietà, funzione, record, etc ... eppure non è mai abbastanza.

Questo è un esempio:

Codice: [Seleziona]

    /// <summary> Cancella la ROI (Indice) dall'array interno. Sposta anche tutto l'array se la ROI non e' l'ultima.</summary>
    /// <param name="Indice"> Indice, numero delle ROI. Va' da 0 (prima ROI) a NUMERO_MAX_ROI-1.</param>
    /// <returns> Viene ritornato l'indice cancellato o -1 in caso di errore. </returns>
    function get_Cancella(Indice: cardinal): integer;

[Lorenzo]

Anche io devo commentare quasi ogni riga.
Poi uno non ci capisce niente sennò.
Spesso sono solito scrivere male codice quando sono stanco.
Quando mi accorgo del'orrore mi domando "chi fosse il somaro che ha scritto quella roba"
Poi non mi posso schiodare dall'architettura MVC.
Porca miseria,è diventata un obbligo come se fosse parte della natura del software con GUI.
Se le GUI sono le View, ci sono i Models che sono le classi che gestiscono ogni dispositivo(server,dbms,etc).
Infine la parte controllers riguarda spesso i metodi spesso nella classe di  raccordo (può essere anche un data module talvolta) che istanzia gli oggetti dei Models e permettono di pilotare i vari dispositivi.

Meno male che queste porcherie le riservo solo a me,altri colleghi avrebbero ben più di un movente per farmi fuori.