Sette scuse usate dai DevOps per giustificare brutto codice, secondo Dave Farley, autore di Continuous Delivery
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 David 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:
- “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. - “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. - “Writing tests is a waste of time“
Scrivere test è una perdita di tempo - “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. - “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. - “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. - “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.
Raoul Scarazzini
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.
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
