Poi sono invecchiato e ho iniziato ad usare i test per capire se il mio codice andasse bene anche dopo una modifica, ho iniziato a scrivere documentazione per capire perché avevo ragionato in un certo modo e ho iniziato a fare code review per migliorare la comprensione del codice e la sua manutenzione.
Questo nuovo approccio “complicato” il mio lavoro, o per meglio dire: ha allungato i processi che, da una richiesta, portavano alla soluzione finale.
Una modifica che un tempo facevo in 10 minuti, ora occupa una giornata intera, perché devo valutare tutti gli impatti che quella modifica può avere, far girare tutti i test automatizzati, eseguire qualche test manuale dove non sono riuscito ad automatizzare, scrivere la documentazione, effettuare il merge con il codice principale, aspettare il build e i test di integrazione, verificare che tutto funzioni e finalmente dichiarare l’issue risolta, sperando di non aver dimenticato qualcosa.
Gli anni passano ed è inevitabile che ci sia l’evoluzione dal bambino spensierato che effettua una push senza test, alla cariatide che aggiusta anche gli spazi quando deve aggiungere codice al branch main (no, “master” non si utilizza più).
Per chi vuole leggere l'intero articolo può farlo a questo link Puoi cambiare questa condizione nel codice? Cosa ci vuole?
Puoi cambiare questa condizione nel codice? Cosa ci vuole?
Un tempo ero molto più veloce nel cambiare un algoritmo, nella modifica di un parametro di una funzione, nella creazione o distruzione di flussi e così via. L’obiettivo era, prima di tutto, fare quello che chiedeva il cliente e solo in seconda battuta fare in modo che il codice fosse mantenibile o che la scelta presa fosse la migliore all’interno di una serie di scelte più o meno ponderate.
Fonte di questo post