Qual è il ruolo di un architetto software nel processo di sviluppo guidato dai test?

A quanto ho capito, Test-Driven Development riguarda la scrittura di test per definire le specifiche del programma (puoi correggermi se sbaglio).

Se esiste qualcuno responsabile della stesura delle specifiche (inclusa un'API pubblica) per il software (chiamiamolo l'architetto del software), significa che l'architetto del software deve scrivere tutti i test?

Oppure l'architetto software scrive le specifiche e le consegna agli sviluppatori per scrivere i test?

O permetti alle specifiche di crescere organicamente permettendo a tutti gli sviluppatori di scrivere i propri test e dimentichi di avere un architetto del software?

architecture tdd

— Robert Harvey
fonte

C'è un dibattito su english.se su cosa intendi per "crescere organicamente" - english.stackexchange.com/questions/17853/… - vuoi confermare :)

— JoseK,

@Jose: L'ultima frase nel mio PO è pensata per essere leggermente ironica, poiché mi sembra ovvio che un programma deve sempre avere specifiche dettagliate da un cliente. Ma i clienti non sanno sempre cosa vogliono esattamente, motivo per cui esistono processi iterativi di sviluppo software . Vedi qui per maggiori informazioni sulla metafora del "software in crescita".

— Robert Harvey,

Risposte:

Lo sviluppo guidato dai test riguarda la scrittura di test per definire le specifiche del programma

Non si scrivono test per definire le specifiche, le descrizioni dei test, le storie degli utenti e le descrizioni delle caratteristiche sono le specifiche, nel senso di "alberi morti".

Per rivedere, il processo TDD in breve è:

definire un progetto in termini di funzionalità
descrivere le parti interessate, il comportamento e l'obiettivo di ogni funzione utilizzando le storie degli utenti
specificare i dati attesi, l'attivazione di eventi / condizioni e comportamenti / risultati associati a una user story utilizzando le descrizioni dei test [e questo completa la "specifica"]
scegli una serie di funzionalità per ogni iterazione; le iterazioni dovrebbero essere brevi [sto omettendo le fasi di pianificazione e stima per brevità]
- codificare un test per una funzione (fallirà, ma è stato necessario prendere decisioni API per codificare il test)
- implementare abbastanza funzionalità in modo che il test passi
- refactoring il codice se necessario
- ripetere con il test successivo fino al completamento della funzione
- ripetere con la funzione successiva fino al completamento dell'iterazione
ripetere con l'iterazione successiva fino al completamento del progetto

quanta progettazione, architettura, documentazione di supporto e così via si sceglie di fare non fa parte di TDD. Ci sono alcune "buone pratiche" pratiche di cui puoi leggere, ma tieni presente che quelle sono le "migliori" pratiche nel laboratorio di qualcun altro , non le tue.

si noti che il punto è che il cliente e lo sviluppatore devono elaborare le funzionalità e scrivere storie e testare le descrizioni insieme , per una comprensione reciproca

quindi, a parte questo, la domanda originale era:

qual è il ruolo di un architetto software in TDD?

E la risposta breve è:

Come sempre, come sempre. - David Byrne

EDIT: La risposta lunga è: l'architetto svolge i consueti ruoli visionario / investigatore / irritante / supporto / backstop durante l'intero processo, se necessario.

EDIT 2: mi dispiace di aver perso il punto delle domande secondarie! Ognuno è responsabile della stesura delle specifiche; tutti gli sviluppatori incluso l'architetto se / quando appropriato più il cliente . Gli sviluppatori codificano anche i test.

— Steven A. Lowe
fonte

Questo ha senso, ma gli unici passi che ho mai sentito parlare di persone nel contesto del TDD sono i cinque passi nei tuoi cinque proiettili interni (che descrivono il processo del refattore rosso-verde). I proiettili rimanenti fanno davvero parte del TDD o fanno parte di una metodologia più ampia che comprende come Agile o DDD?

— Robert Harvey,

@Robert hmmm ... bella domanda! tecnicamente gli altri proiettili sarebbero XP; Ho imparato XP e TDD allo stesso tempo e non ho mai pensato di separarli. Fino ad ora ;-)

— Steven A. Lowe

@Robert ha fatto qualche lettura di aggiornamento; vedere le modifiche (FYI utilizzando XP ref extremeprogramming.org e TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Steven A. Lowe

Hmm, il link che hai fornito per TDD dice che TDD è davvero Test-Driven Design. Ora sono tornato da dove ho iniziato. "Progettate organicamente, con il codice in esecuzione che fornisce feedback tra le decisioni."

— Robert Harvey,

@Robert le modifiche mi hanno sicuramente aiutato a capire meglio la domanda. Prendo la D come sviluppo e la interpreto come l'intero ciclo di vita, non solo la parte di codifica. TDDev è un buon modo per apprendere le capacità architettoniche - il refactoring ha la tendenza a spingerne una in quella direzione

— Steven A. Lowe

Il software Architect non sta scrivendo tutti i test. Ciò metterebbe troppo alla mia mente le spalle.

Il software Architect dovrebbe essere in grado di elaborare un modulo iniziale per l'API in base al quale gli sviluppatori devono scrivere test per questo e quindi creare l'API. Tuttavia, il Software Architect può avere vari standard di codice che non sono necessariamente verificabili, ad esempio documentazione o convenzioni di denominazione. Esiste anche il potenziale per l'API iniziale di perdere alcune chiamate che, man mano che un'implementazione viene eseguita, vengono aggiunte nuove chiamate all'API. Pertanto, l'API avrà una crescita organica man mano che cresce la base di codice, ma il ruolo dell'architetto è nel fornire linee guida di alto livello e nel cercare di assicurarsi che vengano seguite.

Ci possono essere certamente casi in cui un team può decidere di non avere un architetto del software, ma a seconda delle dimensioni dell'API e della società coinvolta, questa può essere o non essere una buona idea.

— JB King
fonte