Com'è difficile essere disciplinati nella scrittura del codice: è da 3 iterazioni che ci ri-cado almeno una volta !!!!
Il punto è questo: fare check-in spesso [1] , più volte al giorno e di una singola cosa alla volta
Oggi è andata cosi, ho cominciato ad aggiungere un tipo per una nuova feature e scrivendo i test mi sono accorto di alcuni namespace di test da rinominare, mi sono fatto prendere la mano e ho spostato anche un namespace del Assembly da testare e poi questo ha richiesto di modificare tutte e 3 le applicazioni che lo usavano. Sono andato avanti fino alle 8 per fare check-in e la feature è ancora da completare.
Quando ho auto la sensazione che i file in check-out stavano diventando troppi ho pensato che ormai mancava poco e facevo prima ad arrivare in fondo: sbagliavo.
Non importa quanto avanti sei andato nella direzione sbagliata, torna indietro. (Proverbio Turco)
→ Tornare indietro significa rolbackkare qualche modifica sul codice... ma c'è sempre lo Shelve di Team System (o i check-in locali di CVS) per salvarsi le modifiche di troppo e ripescarle dopo il check-in
→ Procedere a piccoli passi è più semplice e più veloce
→ Quando la modifica inizia a diventare corposa, procedento a piccoli passi una cosa alla volta è più facile "mettere i buoi in stalla" subito e provare le cose più azzardate alla fine senza rischiare di fallire l'intera iterazione
→ Se l'unico check-in globale va male si rischia di dover gettare tutto il lavoro, con una serie di check-in più piccoli invece in caso di errore si rischia molto meno e quindi si può osare di più e intervallare modifiche a refactoring esplorativi
Tags : Team Work | Agile | Pratiche | Disciplina |
________
[1] di codice testato, funzionante, rilasciabile cioè anche quando la feature non è completa purchè le modifiche non rompano le funzionalità esistenti