Ogni tanto capita che, nel team di sviluppo, ci sia un’assenza pesante, e che, per quanto tutto sia ben documentato, occorra fare dei cambiamenti senza che la persona più esperta in quell’area sia presente: è il momento di mostrarsi acrobati del codice e fare i salti mortali.

In questo caso il mio menabò di lavoro è il seguente, composto da pochi piccoli passi:

Leggi la documentazione di tutte le parti del codice coinvolte nella modifica.

La documentazione in questo caso è essenziale: non è codice vostro e probabilmente non siete nemmeno tanto avvezzi all’argomento che tratta. La documentazione in questo caso sarà la vostra guida verso il successo del task che vi accingete a svolgere: non sottovalutatela o ignoratela, prendetela a cuore e leggetela con calma, comprendendo i vari passi dell’architettura e della logica del software che state modificando.

Prevedi ogni possibile fallout.

Fai le modifiche necessarie ed integra i test di sviluppo: probabilmente c’è stata molta urgenza a richiesere il task mentre l’altro developer era assente per qualche motivo, ma la fretta non è tua e non deve essere la tua consigliera. Non si tratta di codice scritto di tuo pugno, occorre che funzioni e che sia testato, sia in TDD che con le opportune prove, prima di qualsiasi rilascio, che altrimenti potrebbe rivelarsi catastrofico.

Se si tratta di un’API, correggi i contratti prima con il desiderata.

Usare un approccio contract first con le api ti chiarirà subito lo scopo della nuova implementazione e ti consentirà di procedere più agevolmente sul codice esistente, integrando tutto più agevolmente. Anche qui non considerare la stesura dei contratti OpenAPI una perdita di tempo: sono un passo fondamentale verso la sicurezza di ciò che scrivi e la sua futura comprensione: non dimentichiamo infatti che chi si occupa di quella sezione del codice tornerà e dovrà misurarsi con quanto scritto da te.

Se non capisci qualche sezione del codice, non aver paura a farci sopra degli esperimenti.

Rivelerai così il profondo funzionamento del codice, imparerai qualcosa di nuovo, comprenderai il pensiero dello sviluppatore originale, e questo ti aiuterà a capire tutto il resto e procedere più spedito nel lavoro successivo.

Non essere l’unico tester.

Questa è una regola sempre valida, ma in questo caso ancora più obbligatoria. Fai testare la modifica ad altre persone: potrebbe essere sfuggito qualcosa a te e ai test automatici. Se si tratta di un microservizio, controlla che non abbia problemi di concorrenza in parallelo e che il suo stato sia coerente: provare in più di una persona contemporaneamente o con uno stress test automatico sarà utile.

Datemi pure altri consigli su come fare gli acrobati nel coding.