Come gestire un metodo non ancora implementato che verrà svolto da un co-programmatore?

È una domanda interessante e la risposta potrebbe essere più facile di quanto pensi.

In poche parole, scrivi test che convalidano le tue ipotesi. Non importa se fai l'implemenation oi tuoi colleghi programmatori

La lunga risposta.

Qualsiasi opzione elencata è in qualche modo passiva e richiede tu di tornare indietro e rivisitare il codice (se esiste) prima o poi.

• Commenti devono essere letti e gestiti dalla controparte responsabile dell'implementazione. Il tuo codice non può essere compilato nel frattempo. Se controlli questo stato in un repository di codice, la tua pipeline di integrazione continua non funzionerà, ed è comunque una cattiva pratica ... mai controllare codice non funzionante
• Le eccezioni di runtime sembrano migliori, ma sono comunque tossiche, perché il tuo programmatore potrebbe presumere che l'implementazione fosse già stata eseguita senza controllo, lasciando anche il sistema in uno stato instabile. Se il metodo viene attivato non così spesso, potrebbe portare a un codice di produzione interrotto ... anche le cattive pratiche ... non controllare mai le eccezioni "non implementate"
• Aspettare i tuoi colleghi programmatori per l'implementazione dei metodi o di uno stub è anche scoraggiante. Rompe il tuo flusso di lavoro e il flusso di lavoro dei tuoi colleghi programmatori. Cosa succede se sono malati, in un meeting a g, in pausa caffè, vuoi passare il tempo ad aspettare? ... non aspettare qualcuno se non devi
• implementare i metodi mancanti sicuramente il modo migliore per andare avanti. Ma cosa succede se la tua implementazione non soddisfa l'intero caso d'uso e i tuoi colleghi programmatori devono modificarlo o modificarlo? Come fai e loro si assicurano che sia ancora compatibile con il tuo intento? La risposta è di nuovo facile. Scrivi test che verificano, descrivono e documentano le tue intenzioni. Se i test si interrompono, è facile notare. Se è necessario apportare modifiche a tale metodo che interrompono la funzione ... la vedi immediatamente. Entrambi avete un motivo per comunicare e decidere cosa fare. Dividere la funzionalità? Cambia la tua implementazione, ecc ... mai verificare il codice che non è sufficientemente documentato dai test

Per raggiungere un livello sufficiente di test ti suggerirei di dare un'occhiata a due discipline.

1. TDD - sviluppo basato sui test - questo assicurerà di descrivere il tuo intento e testarlo a sufficienza. Ti dà anche la possibilità di simulare o falsificare metodi e classi (anche utilizzando interfacce) che non sono ancora stati implementati. Il codice e i test continueranno a essere compilati e ti permetteranno di testare il tuo codice a prescindere dal codice dei tuoi colleghi programmatori. (vedi: link )

2. ATDD - sviluppo basato su test di accettazione - questo creerà un loop esterno (attorno al loop TDD) che ti aiuta a testare la funzionalità nel suo complesso. Questi test diventeranno verdi solo quando verrà implementata l'intera funzionalità, dandoti quindi un indicatore automatico quando i tuoi compagni completeranno il loro lavoro. Abbastanza pulito se me lo chiedi.

Avvertenza: nel tuo caso, scriverò solo semplici test di accettazione e non cercherò di coinvolgere troppo il lato business, perché sarebbe troppo per cominciare. Scrivi semplici test di integrazione che riuniscano tutte le parti del sistema richieste dalla funzione. Questo è tutto ciò che è richiesto

Ciò consentirà di inserire il codice in una pipeline di Integrazione continua e di produrre un'implementazione altamente affidabile.

Se vuoi approfondire questo argomento controlla i seguenti link:

• link
• link
• link

Richiedi stub.

O scrivili tu stesso. In entrambi i casi, tu ei tuoi colleghi dovete essere d'accordo sulle interfacce e su come devono essere utilizzate. Tale accordo deve essere relativamente solidificato in modo che possa svilupparsi contro gli stub - per non parlare, in modo da poter creare i propri mock per il test dell'unità ...

Nella tua situazione, parlerei con il membro del team che ha la responsabilità di quella funzione. Può darsi che siano nella posizione di dare la priorità allo sviluppo di quella funzione in modo da poter iniziare a usarlo prima.

Vorrei evitare la quarta opzione. Hai scritto tutto il tuo codice e, come dici tu, non consideri più il tuo problema. Il tuo collega scrive quindi l'implementazione della funzione e non considera più il problema. Chi sta per verificare che il codice che hai scritto funzioni correttamente?