Qual è il contrario di TDD? [chiuso]

Question

Test Driven Development (TDD) e le sue prestazioni sono ben definiti. Lo stesso si può dire per le pratiche come Behavior Driven Development (BDD). Ognuno rappresenta una tecnica di sviluppo software che sostiene una maggiore disciplina prima di iniziare a scrivere codice.

Qual è, allora, è l'acronimo conveniente per l'approccio "non strutturato" per lo sviluppo?

ho visto "TAD" (Test Dopo lo sviluppo) utilizzato in alcune occasioni, ma che implica comunque il test è stato fatto. Qualcuno ha visto (o qualcuno vuole inventare) un acronimo per il "codice di come si va" approccio allo sviluppo? Sto cercando il TDD / BDD / xDD equivalente per il tipo di sviluppo che tutti abbiamo fatto dove il codice semplicemente di scrittura e di rilascio.

(Chiaramente, v'è abbondanza di spazio per la "commedia" qui, quindi cerchiamo di astenersi da "n00b Driven Development" e l'ilk.)

[UPDATE]

Un sacco di ottime risposte. In definitiva, credo che le idee di "Driven Development Sviluppo" o "Idea Driven Development" migliore risposta alla domanda. Dove in TDD si sta cercando di superare le prove e in BDD si sta cercando di soddisfare il comportamento, in fase di sviluppo "non strutturato", stai davvero guidato solo provando convertito un'idea per il codice.

Chiaramente, nessuna risposta giusta o sbagliata, ma una buona collezione di opinioni qui. Speriamo che questa risorsa possa essere utile per gli altri cercando di catturare in modo chiaro la "definizione" di sviluppo in assenza di processo.

Answer 1

mi piacerebbe tendono a concordare con Pavel, ma sarebbe andare oltre e chiamare:

Driven Development Sviluppo

Sviluppo guidato senza alcuna motivazione evidente è lo sviluppo per il bene dello sviluppo. In TDD, si sviluppa per soddisfare i test. In BDD, si sviluppano per stabilire alcuni comportamenti. Nello sviluppo Sviluppo-driven, si sviluppa perché sei uno sviluppatore e questo è ciò che sei pagato per fare.

Answer 2

Non so su un acronimo, ma cosa ti riferisci è tipicamente chiamato Cowboy Coding .

  

Cowboy codificatori sono programmatori che scrivere il codice secondo le proprie regole.

     

La Via Cowboy:

     

  
• La velocità con cui posso incidere qualcosa insieme determina il mio valore
  
• Le persone che hanno bisogno di commenti al fine di comprendere il mio codice sono troppo stupido per essere   lavorare con me
  
• Le persone che mi chiedono domande sul mio codice sono troppo stupido per capirlo,   e (quindi) sono troppo stupido per essere   lavorare con me
  
• il codice di altre persone è solo scadente, ma la mia è auto-descrittivo e   bella
  
• Sfruttando una caratteristica del linguaggio del compilatore-dipendente per salvare una linea di   codice è "elegante"
  
• Altre persone del mio team causa tutti i bug; Sono io quello che li correzioni
  
• Il mio codice non è mai in colpa, perfezionare sempre, e non faccio errori
  
• Dal momento che il mio codice non è mai in colpa, non ho bisogno di testare a fondo, se   a tutti
  
• Dal momento che il mio codice è sempre perfetto, non ha mai bisogno di essere riscritta, non importa   quanto tempo è stato nel codebase o   quante cose sono cambiate intorno ad esso
  
• Dal momento che non ho mai sbagliare, posso urlare a chiunque altro che fa
  
• Dal momento che il mio codice è perfetto, se il programma va in crash a causa di imprevisti   i dati, è colpa dell'utente per   inserimento dati non validi.
  
• Dal momento che il mio codice è perfetto, se il programma non riesce dopo una macchina minore   modifica della configurazione, è il   gli amministratori di sistema per colpa cambiarlo.
  
• Dal momento che il mio codice è perfetto, se il programma viene eseguito troppo lentamente, è il   guasto gestioni per non fornire un   macchina più veloce.
  

Answer 3

FDD

La fede Driven Development.

Perché è necessario pregare tue opere di progetto su ogni rilascio.

Answer 4

AD (D) D - deficit di attenzione (Driven) per lo sviluppo

In che:

• lavorare in modo casuale su qualunque parte dell'applicazione attira la vostra attenzione al momento
• lavorare su caratteristiche per qualsiasi utente squawks i più forti (fino squawks qualcun altro più forte)
• correre giù per sentieri di coniglio nel codice, dimenticare il percorso che hai preso per arrivarci, e uscire in qualche luogo completamente diverso e risolvere qualche problema completamente diverso
• "refactoring" Codice cambiando il suo comportamento senza una solida comprensione di ciò che è in realtà dovrebbe fare o se funziona ancora quando si è finito - ma se così non fosse, si potrebbe andare in giro a fissare, se qualcuno squawks abbastanza forte

Answer 5

Madd - Driven Manager per lo sviluppo.

  

Si impiegano già più a lungo di quanto si   stimata solo al codice reale   prodotto - ora si vuole spendere più   test di scrittura di tempo che non get   liberato?!?!