Scrittura pratica su come il software viene realizzato e mantenuto in salute. Gli argomenti includono il controllo della versione per sviluppatori singoli, test automatizzati, feature flag, blocchi del codice e blocchi delle funzionalità, e come ritirare in sicurezza il codice legacy. Le guide sono scritte per piccoli team e sviluppatori indipendenti che hanno bisogno di abitudini che funzionino, non di teoria.
Il Black Friday è tra cinque settimane e il feature freeze sul tuo calendario non ha ancora una data fissa. Prima che le distribuzioni si fermino, hai bisogno di un piano per ciò che viene rilasciato ora e ciò che aspetta fino a gennaio. Un feature freeze protegge le entrate, ma ferma anche quasi tutto ciò che un team di sviluppo fa normalmente per quattro-dieci settimane. … Leggi tutto
Un rilascio difettoso alle 2 del mattino non dovrebbe richiedere un redeploy di 20 minuti per essere corretto. I feature flag offrono un interruttore per disattivare istantaneamente una funzionalità difettosa, senza toccare la pipeline di distribuzione. La domanda non è se usarne uno, ma quale versione costruire: un flag scritto da te, una piattaforma open-source eseguita sul … Leggi tutto
Arriva ottobre e con esso la domanda annuale: blocchi il codebase prima della corsa alle festività o continui a rilasciare sperando che non si rompa nulla? Ogni anno, i proprietari di siti e i piccoli team affrontano questa stessa decisione senza un piano d'azione chiaro. Un blocco del codice sembra semplice sulla carta. In pratica, può bloccare silenziosamente lo sviluppo per settimane … Leggi di più
Il codice legacy raramente scompare da solo. I team posticipano la rimozione perché temono che una dipendenza nascosta rompa la produzione nel momento in cui qualcuno elimina un file. Questa checklist adotta una visione diversa: il ritiro funziona meglio come una serie di piccoli passaggi reversibili piuttosto che come una drastica eliminazione. Non avete bisogno di una riscrittura completa per … Leggi tutto
Il controllo di versione sembra uno sport di squadra. Non lo è. La maggior parte delle guide parla di pull request, code review e conflitti di merge tra colleghi, quindi i singoli sviluppatori presumono che l'intero sistema non si applichi a loro. Tale presupposto costa alle persone il loro lavoro. Un singolo sviluppatore rompe le cose tanto spesso quanto un team, solo senza nessun altro nei paraggi a notarlo prima di… Leggi di più
I test automatizzati raramente appaiono in una demo di prodotto, e questo è esattamente il problema. Una demo mostra il percorso felice: ogni clic funziona, ogni schermata si carica, ogni pulsante si comporta bene. Quella rifinitura esiste perché qualcuno l'ha provata, non perché il software sia solido sotto. Gli utenti reali cliccano fuori ordine, su connessioni lente, su telefoni che … Leggi tutto
