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

Questa è una domanda su come lavorare in gruppo.

Di recente ho lavorato al mio primo progetto di programmazione più grande (~ 80 classi, Java) con un team di 6 persone, sebbene solo 4 di noi lavorassero continuamente sul codice. Abbiamo distribuito il lavoro da svolgere all'inizio e ad un certo punto avevo bisogno di chiamare un metodo che non era ancora stato implementato da uno dei miei co-programmatori. Come è il modo raccomandato per affrontare questo?

Opzioni che ho visto, anche se non mi piacciono molto:

Scrivere me stesso //TODOe rivisitare questa riga di codice in un secondo momento per verificare se il metodo è stato implementato nel frattempo.
Chiedere al membro del team corrispondente di implementarlo ora .
Lancio di un runtimeException personalizzato con una chiara descrizione di ciò che non è ancora stato implementato. (Almeno non dobbiamo cercare a lungo per scoprire cosa manca)
Aggiungendo il metodo necessario alla loro classe e scrivendoli //TODOnel corpo del messaggio, possibilmente anche inviare loro un rapido messaggio su quella modifica. (Ora non è più un mio problema, ma questo può causare fastidiosi conflitti di unione se nel frattempo stavano lavorando a questo metodo)
Definire classi o interfacce astratte per tutto prima di scrivere effettivamente il codice che fa il lavoro. (Non ha funzionato troppo bene perché queste interfacce erano spesso cambiate)

teamwork

— lucidbrot
fonte

Penso che il flusso di lavoro in cui è necessario un metodo scritto da qualcun altro non sia quello giusto. Stai lavorando a una funzione. Se quella funzione richiede un metodo, LO implementate. Se due persone devono implementare una singola funzione, si accoppiano o si integrano e comunicano così frequentemente che sembra quasi che si accoppino.

— Euforico,

@Euforico Più volte mi sono imbattuto in una situazione in cui una nuova funzionalità piuttosto grande doveva essere sviluppata in un arco di tempo relativamente breve e come tale l'interfaccia utente, la logica aziendale e i livelli API dovevano essere suddivisi in diversi compiti su cui lavorare contemporaneamente, altrimenti la scadenza non potrebbe mai essere rispettata. Questo è esattamente il punto in cui una persona che lavora sull'interfaccia utente deve dichiarare a BL solo metodi e comandi di accesso ai dati come interfacce e consentire alle altre persone di lavorare sull'implementazione, lavorando esclusivamente sull'interfaccia utente.

— Andy,

@DavidPacker Quello che descrivi non è l'unico modo per risolvere quel problema. Le sezioni verticali, l'integrazione frequente, le piccole funzionalità sono tutte soluzioni migliori delle sezioni orizzontali con ogni persona che lavora su una parte separata.

— Euforico,

@Euforico Non posso essere più d'accordo con te. Quando possibile, andiamo con il modo di eliminare la complessa nuova funzionalità di parti non critiche (cioè quelle che migliorerebbero solo la UX ma non sono immediatamente necessarie). Purtroppo, a volte le opzioni che hai citato, né la funzionalità di stripping, non sono possibili. Gli affari dicono, gli sviluppatori lo fanno. Quindi, sebbene i tuoi punti siano solidi, c'è anche la probabilità che qualcuno possa e incontrerà una situazione in cui un tipo di divisione del lavoro deve essere fatta per soddisfare le esigenze del business.

— Andy,

che dire di parlare con lui come vuole gestire la cosa?

— Aganju,

Risposte:

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

In poche parole, scrivi dei test che convalidano i tuoi presupposti. Non importa se esegui l'implementazione o i tuoi colleghi programmatori

La lunga risposta

Una di queste opzioni che si lista sono piuttosto passivo e richiedono che si torni e rivisitare il codice (se ne esistono) prima o poi.

I commenti devono essere letti e gestiti dalla controparte responsabile dell'implementazione. Nel frattempo non è possibile compilare il codice. Se si controlla tale stato in un repository di codice, la pipeline di integrazione continua non funzionerà, ed è comunque una cattiva pratica ... non controllare mai il codice non funzionante
Le eccezioni di runtime sembrano migliori, ma sono ancora tossiche, perché il tuo collega programmatore potrebbe presumere che l'implementazione sia già stata eseguita senza controllo, lasciando anche il sistema in uno stato instabile. Se il metodo viene attivato non molto spesso, potrebbe causare la rottura del codice di produzione ... anche cattive pratiche ... non controllare mai le eccezioni "non implementate"
Anche scoraggiare i tuoi colleghi programmatori per l'implementazione dei metodi o uno stub è scoraggiante. Rompe il flusso di lavoro e il flusso di lavoro dei tuoi colleghi programmatori. Cosa succede se sono malati, durante una riunione, durante una pausa caffè, vuoi passare il tempo ad aspettare? ... non aspettare qualcuno se non è necessario
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 cambiarlo? In che modo tu e loro vi assicurate che sia ancora compatibile con le vostre intenzioni? La risposta è di nuovo facile. Scrivi test che verificano, descrivono e documentano le tue intenzioni. Se i test si interrompono, è facile accorgersene. Se è necessario apportare modifiche a quel metodo che interrompono la tua funzione ... la vedi immediatamente. Entrambi avete un motivo per comunicare e decidere cosa fare. Dividere la funzionalità? Modifica l'implementazione, ecc ... non eseguire mai il check-in del codice non sufficientemente documentato dai test

Per raggiungere un livello sufficiente di prove, suggerirei di dare un'occhiata a due discipline.

TDD - sviluppo guidato dai test - questo ti assicurerà di descrivere il tuo intento e di testarlo sufficientemente. Ti dà anche la possibilità di deridere o falsare metodi e classi (anche usando interfacce) che non sono ancora implementati. Il codice e i test verranno comunque compilati e consentiranno di testare il proprio codice isolando il codice dei colleghi programmatori. (vedi: https://en.wikipedia.org/wiki/Test-driven_development )
ATDD - sviluppo guidato dai test di accettazione - questo creerà un loop esterno (attorno al loop TDD) che consente di testare la funzionalità nel suo insieme. Questi test diventeranno verdi solo quando l'intera funzione sarà implementata, dandoti così un indicatore automatico quando i tuoi compagni completeranno il loro lavoro. Abbastanza pulito se me lo chiedi.

Avvertenza: nel tuo caso, scriverei solo semplici test di accettazione e non proverei a coinvolgere troppo il lato commerciale, dato che sarebbe troppo per cominciare. Scrivi semplici test di integrazione che mettono insieme tutte le parti del sistema richieste dalla funzionalità. Questo è tutto ciò che è richiesto

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

Se vuoi approfondire l'argomento, controlla i seguenti link:

— Jesko R.
fonte

103

Chiedi stub.

Oppure scrivili tu. In entrambi i casi, tu e i tuoi colleghi dovete concordare le interfacce e come devono essere utilizzate. Tale accordo deve essere relativamente solidificato in modo da poter sviluppare contro gli stub - per non parlare, quindi puoi creare le tue beffe per i test delle tue unità ...

— svidgen
fonte

^^ Questo. Se stai usando correttamente le interfacce, non dovresti aver bisogno delle implementazioni fino a quando l'altro non ha finito di scriverle.

— Robert Harvey,

E per un ulteriore commento di Robert, se non stai usando correttamente le interfacce in un progetto specificamente progettato per essere diviso tra più persone, beh, ti

— divertirai

È un peccato che Java non abbia file di intestazione. Nel mondo C / C ++ puoi elaborare le tue API e scrivere prima tutte le intestazioni, una mancanza di implementazione diventa quindi un problema per il linker. (Leggera semplificazione, anche l'ABI deve rimanere costante perché sia solo una questione di linker).

— Wes Toleman,

@WesToleman Divertentemente, una delle mie cose preferite su Java è che non ha file di intestazione. Le "interfacce" citate da Robert e corsiKa riempiono perfettamente quel ruolo. Prima devi elaborare le API, scrivere le interfacce e una mancanza di implementazione concreta non è un problema per il compilatore.

— GrandOpener il

@WesToleman Funziona bene per te? Alle mie orecchie sembra molto simile allo stile delle cascate d'acqua, e la mia ipotesi è che devi aggiornare ulteriormente l'interfaccia quando ti rendi conto che ti sei perso questo "parametro importante"?

— netigger

Nella tua situazione, vorrei parlare con il membro del team con la responsabilità di quella funzione. È possibile che siano in grado di dare priorità allo sviluppo di quella funzione in modo da poter iniziare a usarla prima.

Vorrei evitare la tua quarta opzione. Hai scritto tutto il tuo codice e, come dici, non lo consideri più un tuo problema. Il collega quindi scrive l'implementazione della funzione e non la considera più il loro problema. Chi testerà effettivamente che il codice che hai scritto funzioni correttamente?

— Pete
fonte

È necessario richiedere l' API per quella funzione che dovrebbe risultare in una o più interfacce. Potrebbe essere una buona idea farlo insieme, poiché dovrai utilizzare questa interfaccia in modo da poter progettare i casi di test iniziali in base al tuo input. L'implementazione effettiva può quindi avvenire in seguito (comprese le possibili modifiche all'API)

— Thorbjørn Ravn Andersen,