Sette scuse usate dai DevOps per giustificare brutto codice, secondo Dave Farley, autore di Continuous Delivery

0

Agli albori dell’introduzione delle pratiche DevOps c’è stato un libro che in molti hanno letto e che ha rappresentato, se non effettivamente definito, le fondamenta del metodo, almeno per quanto riguarda l’ambito di quella che oggi chiamiamo comunemente CI/CD.

Questo libro è Continuous Delivery, scritto da Jez Humble e David Farley:

I suoi autori qualcosa in merito all’argomento ne sapevano, ed è per questo che quanto uno di loro, precisamente Farley, pubblica un video dal titolo “Is This Why You’re Bad At Programming?” beh, forse buttarci un occhio può valerne la pena.

Il video è questo:

Ed al netto del titolo, già interessante di suo, sono le sette scuse degli sviluppatori per lavorare male a rappresentare suggerimenti realmente preziosi.

Eccole riassunte:

  1. “You can’t do serious work without feature branching.”
    Non puoi lavorare seriamente senza usare il feature branching
    Differenti branch portano a divergenze che, più passa il tempo, più sono difficili da unire in un merge. Prevedere merge quotidiani (mediante CI) risolve questo problema.
  2. My manager says I don’t have time for this.
    Il mio manager dice che non ho tempo
    Gli sviluppatori, secondo Farley, sono complici di queste decisioni, perché generalmente design e refactoring sono operazioni… Faticose.
  3. Writing tests is a waste of time
    Scrivere test è una perdita di tempo
  4. My code is good so I don’t need tests
    Il codice che scrivo non ha bisogno di test
    Entrambi questi punti si traducono in un dato di fatto: il codice che si può testare è scritto meglio, è più modulare e più predisposto alle evoluzioni.
  5. You can’t do code review with continuous integration
    Non è possibile fare code review con la CI
    Le pull request e le relative run di CI sono la base della code review, la CI è letteralmente nata per quello.
  6. These ideas may work for simple web apps but not for my system
    Queste idee potranno pure funzionare per semplici web app, ma non per il mio sistema
    Citando Google, viene esposto come è possibile avere il processo di CI e di review in minuti, anche e soprattutto in un posto in cui ci sono miliardi di commit in corso.
  7. We’ve always done it this way and it works for us
    Abbiamo sempre fatto così ed ha funzionato
    Le nuove idee sono la fortuna dell’evoluzione dei progetti, se sono dimostrabili mediante dati oggettivi.

Anche se quanto sopra riassume il contenuto del video, ne stra consiglio la visione a tutti, ma più ancora consiglio a tutti di tenere sott’occhio la lista nel momento in cui si sta scadendo in uno degli errori descritti, il che è molto più facile di quanto si possa credere.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *