Quali processi / attività miglioreranno l'interazione con gli sviluppatori e interromperanno le interruzioni?

Innanzitutto hai bisogno di buoni test unitari.

Dico prima perché se ti concentri sulle 'interazioni con lo sviluppatore' prima di fare questo, introduci un sacco di processi e overhead che supportano facendo la cosa sbagliata o almeno non saranno necessari quando allora hai test automatici. Anche le risorse e l'entusiasmo per il cambiamento sono limitati. Inizia a cambiare la cosa peggiore prima. Le interazioni con lo sviluppatore sono fondamentali ma i test unitari sono anche più critici.

Quindi usa il tuo tempo per prendere il primo passo dei test delle unità di scrittura. Domani. Se la gente non sa come o la struttura da utilizzare, ecc., Prepara la formazione e l'istruzione per l'attività di domani e inizia a scrivere i test la prossima settimana. Assicurati che la gente sappia che questo sarà difficile, avrà una curva di apprendimento ripida e anche quando sarà in grado di accelerare significherà prendere più del doppio del tempo necessario per scrivere i test. Questo è un investimento. È possibile costruire una casa senza una fondazione più rapidamente, ma avrà problemi durante l'uso (in base al periodo di tempo previsto di 100 anni che dovrebbe durare). Se un framework o iniziare sembra intimidatorio, scrivi un pezzo di codice che chiama una delle tue funzioni (metodi, ecc.) Che passa i parametri appropriati e controlla il valore restituito per vedere se è quello che è previsto. boom. hai un test unitario. ripetere.

Inizia richiedendo test unitari per nuove funzionalità. Nel tempo la copertura aumenterà. Utilizza uno strumento per misurare la copertura del codice nel tempo in modo che tu possa vederlo.

Sostieni l'idea che i test unitari sono l'unico modo pratico per garantire che le nuove modifiche non interrompano le funzionalità in uscita per il mondo di sviluppo di oggi. Affidarsi al test manuale cambia il ciclo di modifica del codice da minuti a giorni.

Se stai facendo uno sviluppo Agile, parla dei test di Unità, Funzionali, Stress ed Esplorativi che dovresti prendere in considerazione. Il test unitario è solo uno di questi quadranti. È l'unica area che considero non facoltativa e i test unitari dovrebbero essere scritti insieme al codice. Idealmente avanti, passo dopo passo, ma in pratica si può in alcuni casi scrivere il codice quindi il test e in altri il test quindi il codice. Su piccola scala, i dettagli dei quali fai per primi non hanno importanza (ci sono comunque delle differenze), così come assicurarti di finire con il codice e i test che lo supportano. Se fai scrivi prima i test, anche se generalmente troverai che il codice è migliore e più testabile!

In che modo questi nuovi processi / attività miglioreranno l'interazione con gli sviluppatori?

Avere un solido insieme affidabile di test unitari aiuterà le persone a sentirsi bene a cambiare codice, ok su soluzioni rapide o correzioni di bug. So che Joe non infrangerà il codice di Mary perché i buoni test unitari sono lì per dirmi se lo faccio. Altrimenti i giorni sono pieni di vari sviluppatori che rompono il codice di altri sviluppatori, non rendendoli conto e introducendo continuamente bug. Ci sono stato, fatto questo, non è divertente. È difficile avere un ambiente divertente e rilassato quando tutto questo sta succedendo. D'altra parte un ambiente in cui siamo tutti protetti da questo test può essere più rilassato e meno stressante nella mia esperienza.

Ho lavorato in diverse aziende in diversi punti sullo spettro di avere delle buone suite di test e ho visto il gioco sopra descritto. Non fare affidamento su un secondo set di occhi per rompere le funzionalità esistenti quando i test automatici possono farlo per te. Conserva il secondo set di occhi per attività di livello superiore che circondano un codice ben fatto che i computer non possono fare bene.
ancora.

Un altro punto - usa anche i linters per il tuo codice per controllare il formato per html, css, ruby, javascript, python, ecc. Questo è un altro modo per impedire che le recensioni del codice diventino personali e riscaldate (degradando così le interazioni degli sviluppatori che sei chiedere di). Prendi decisioni sugli standard di codice e acquisiscili nei tuoi file di configurazione di linter. Questo ti consente anche di parlare di cose di livello superiore e non di discutere sugli spazi del rientro, ecc.

P.S. questo è tutto nuovo per me. Quando ho scritto il codice 20 anni fa, il test manuale era l'unica opzione.

La cosa da senior junior è così anni '90. Va bene se gli ingegneri più esperti hanno un peso maggiore nei problemi se possono eseguire il backup e convincere l'intera squadra a concordare una soluzione. Tuttavia, cambiare le cose senza il buy-in della squadra non è ok. Sentirsi come se fossero in qualche modo più superiori agli altri sviluppatori non è ok.

È positivo che tu stia facendo delle revisioni tra pari, ma di nuovo assicurati che tu sia veramente "pari" e che non sia inclinato verso gli anziani che dettano ciò che sta accadendo. Se hai la sensazione che potrebbe influire negativamente sulla discussione dei problemi in modo aperto, probabilmente non è una recensione tra pari.

Una delle cose che mi piace in situazioni come questa è l'implementazione di retrospettive. È solo un incontro in cui i singoli membri del team possono sollevare questioni di fronte all'intero gruppo e discuterne apertamente. Accetto o in disaccordo apertamente se qualcosa è veramente un problema e trovare una soluzione per risolvere i problemi. Alcuni team sono in grado di discutere apertamente i problemi su base continuativa, altri team hanno bisogno di un incontro più formale come un "retro" per cambiare lentamente la cultura dello sviluppo da un tipo di comando / controllo a un ambiente più aperto e paritario dove la creatività può davvero dare il calcio in.

Ci sono stati alcuni punti positivi su come migliorare la comunicazione e includere i test unitari, quello che mi sembra che manchi della discussione è come si va a implementare tali cambiamenti dopo che la vostra squadra è d'accordo / ha consapevolezza. Sembra che tu non abbia un processo di flusso di lavoro stabilito o che quello attuale non sia più adatto.

Dici di avere una peer review, tuttavia questi cambiamenti hanno infranto i processi esistenti che sembrano indicare anche una mancanza di test di regressione / o carenti di quelli adatti (nonostante anche la mancanza di test unitari).

Alcuni suggerimenti:

1. Prendi in considerazione la possibilità di creare un piano di test end-to-end che può essere eseguito da un peer / QA per testare la tua funzionalità ogni volta che questi cambiamenti sono introdotto. Questo aiuterà almeno a coprire la mancanza di test unitari (ovviamente, non può sostituirli del tutto).

2. Considera la possibilità di rivedere / aggiornare il tuo flusso di lavoro esistente a un altro uno appropriato, qualcosa come la ramificazione di funzionalità Git potrebbe adattarsi I tuoi bisogni ( link ). Usando questo in un ambiente come GitLab, il tuo team avrà piena visibilità dei cambiamenti, essere in grado di contribuire alle discussioni, e verifica le modifiche in un ambiente di test separato, ecc.

Credo che questa sia una classica domanda XY. Stai chiedendo come ottenere qualcosa ("interazione con lo sviluppatore"), ma il problema in realtà sembra richiedere una soluzione diversa.

Hai uno sviluppatore che apporta un cambiamento che consideri un miglioramento, ma attira una regressione inaspettata che non viene catturata da unittests.

Le recensioni sono sempre una buona idea, ma dichiari di avere già delle revisioni paritarie e con diversi sviluppatori senior che discutono di cambiamenti. Quindi sembra che il problema sia successo nonostante l'interazione con lo sviluppatore piuttosto che a causa della mancanza di esso.

Ci sono alcune possibili spiegazioni:

• lo sviluppatore era avventato e avrebbe dovuto immediatamente rendersi conto dell'errore. E la revisione tra pari è stata eseguita in modo approssimativo.

• il tuo codice è fragile o difficile da ragionare, il che significa che anche le modifiche esaminate con attenzione potrebbero portare a errori imprevisti.

Inoltre il problema non è stato colto da un unittest. Ci sono alcune possibili spiegazioni:

• Non scrivi regolarmente l'unittest per verificare le modifiche e prevenire le regressioni.
• Si scrivono le unittests, ma sono scritte male e in realtà non testano nulla.
• È davvero difficile testare il tuo codice, oppure il codice è davvero complesso e difficile da ragionare, quindi i bug spesso non vengono catturati nonostante il test dell'unità.

Anche tu dai un'occhiata a quale è la causa del problema prima di provare a implementare una soluzione.