Sviluppa velocemente e con errori, quindi correggi gli errori o sii lento, attento a ogni riga di codice? [duplicare]

Dipende INTERAMENTE dal tipo di lavoro che stai facendo. Per molte situazioni, il Test-Driven-Development, come si sta facendo attualmente, è sicuramente la strada da percorrere. Nel complesso trascorrerai un tempo inferiore nel progetto, poiché non dovrai più tornare indietro e correggere bug e casi limite che non hai tenuto conto per la prima volta. Con la prima opzione, sì, finirai in un tempo record, ma poi passerai una buona parte del tempo a tornare indietro e correggerai tutti gli errori.

Detto questo , se ti trovi in una situazione in cui devi portare un prodotto fuori dalla porta il più velocemente possibile (forse stai cercando di battere la competizione per il vantaggio del "primo al mercato"), getta TDD fuori dalla finestra e ottieni qualcosa lavorando e là fuori. Un lotto di grandi prodotti è successo in questo modo. Il tuo prodotto non ti porterà da nessuna parte se stai lucidando all'infinito e correggendo bug se un concorrente con un prodotto "abbastanza buono" sta mangiando il tuo pranzo.

Considera Facebook. Mark Zuckerberg ha creato Facebook nel suo dormitorio con PHP e MySQL, in un momento in cui probabilmente venti altre persone o organizzazioni stavano pianificando o già pubblicando siti di social networking. Parte del motivo del successo di Facebook è stato che ha fuori dalla porta in fretta e ha battuto buona parte della competizione solo perché era il primo al mercato del college.

Se hai tempo: test dell'unità .

Se sei in una gara: codice e fallo funzionare, preoccupati per gli errori successivi.

EDIT: Ovviamente, non è possibile rilasciare un prodotto che è così buggato inutilizzabile. Quando si utilizza il metodo "fuori dalla porta", è necessario rendersi conto quando la caccia e la correzione di ulteriori bug aggiungerà solo un valore marginale al prodotto rispetto al rilascio immediato.

Il secondo modo è migliore, secondo me. Sembra più lento, ma la quantità di rilavorazioni, riparazioni e ripetizioni sarà molto inferiore e alla fine porterà a un prodotto migliore. Dici che ci vogliono "settimane" per scrivere un programma, ma sai già che se vai con il primo metodo, puoi scrivere il programma in "giorni" e poi passare "settimane" nella fase "correggere tutti gli errori possibili".

L'unico momento in cui difenderei il metodo n. 1 è quando si tratta di codice proof-of-concept che viene utilizzato per dimostrare una singola finestra o una funzione che funzionerà in parametri molto stretti.

L'unico modo per andare veloci è quello di andare bene.

Ho visto "Zio" Bob Martin parlare di questo in una conferenza una volta. Fortunatamente una citazione è on line.

There's no such thing as quick and dirty in software. Dirty means slow. Dirty means death.

Bad code slows everyone down. You've felt it. I've felt it. We've all been slowed down by bad code. We've all been slowed down by the bad code we wrote a month ago, two weeks ago, even yesterday. There is one sure thing in software. If you write bad code, you are going to go slow. If the code is bad enough, you may just grind to a halt.

The only way to go fast is to go well.

Realizzo lo sviluppo guidato, dove definisco tutti i miei casi in anticipo. Questo mi consente di programmare il codice in modo rapido e sciolto, e poi vedere cosa mi è mancato. Poi torno indietro e rifletto su ciò che ho incasinato. La mia opinione è sempre stata, capire cosa dovrebbe fare, "abbozzarlo" sulla carta e capire dove sono sbagliate le mie supposizioni. Ci sono stato troppe volte in cui ho provato a fare qualcosa di perfetto la prima volta, solo per rendermi conto che devo tornare indietro e rifarlo a causa di un'errata assunzione da parte mia.

Penso che la tua domanda crei qualcosa di una falsa dicotomia. In realtà, la decisione non è binaria ("faccio codice lentamente e con attenzione, o in modo rapido e spericolato?"), Ma è piuttosto su uno spettro. Le due opzioni che hai presentato sono all'estremo.

Esattamente dove lo spettro che si desidera dipende molto dal particolare prodotto su cui si sta lavorando e da ciò che i clienti si aspettano da voi. È necessario esaminare i vincoli con i quali si sta lavorando e quindi prendere una decisione intelligente sul tipo di processo che si desidera utilizzare.

Ad esempio, se sei in una posizione in cui è molto costoso correggere gli errori o dove i guasti sono potenzialmente catastrofici, vuoi essere più vicino all'opzione # 2. Software incorporato, guida missilistica codice e strumenti medici sono buoni esempi. Quando correggere un bug significherebbe richiamare milioni di dollari di hardware, o quando il tuo errore potrebbe causare la morte di persone, devi assicurarti di averlo fatto bene la prima volta.

L'altra estremità dello spettro è quando l'ambiente aziendale richiede modifiche rapide del codice, ma è facile correggere gli errori e le sanzioni per il fallimento sono basse. Le applicazioni Web spesso si adattano a questa descrizione. I tuoi utenti chiedono a gran voce nuove funzionalità e modifiche alla logica di business e le vogliono implementate ieri. Se viene commesso un piccolo errore nel codice, occorrono 15 minuti per modificare lo script incriminato, ottenere il codice di modifica rivisto e correggerlo. In questo caso, finché gestisci correttamente le aspettative degli utenti, impareranno a ignorare il bug occasionale a patto che tu risponda alle loro esigenze e mantenga un tempo di risposta rapido. Ovviamente, anche adottando questo approccio, dovresti comunque disporre di protezioni per prevenire i guasti catastrofici: mantieni i backup, esegui revisioni del codice e assicurati di avere un buon hotfix / processo di ripristino.

Penso che la realtà dello sviluppo del software sia che la maggior parte dei progetti giacciono da qualche parte tra questi due estremi. Di solito vuoi essere diligente nel prevenire i bug, ma potresti non volere un ciclo di rilascio di un anno a causa di un pesante processo di controllo della qualità.

A parte i fattori ambientali che ho citato prima, penso che il modo migliore per capire esattamente dove dovresti essere è valutare il feedback degli utenti. Se sono frustrati dai lunghi tempi di attesa per le nuove funzionalità, potresti voler ridurre leggermente il processo di controllo qualità per essere più reattivo. Assicurati di essere extra veloce per correggere eventuali bug che potresti introdurre. D'altro canto, se richiedono un'assoluta affidabilità, assicurati di disporre di sufficienti tutele per soddisfare al meglio quella richiesta.

Vai per 2.

Think -> think further -> do a peer discussion, for complex devs -> code -> test -> eventual fix.

Molto meglio di

Code -> code more -> realize it won't work -> fix -> discover a new bug the first code raised -> go back to scratch

Stai seguendo un approccio Test Driven Development (TDD)? Scoprirai dopo 1-2 mesi di sviluppo con questo approccio che sei veloce come se stessi seguendo 1. e che mantieni la barra di qualità superiore di 2. Potrai anche apportare modifiche -fattore) senza paura, pensala come un risparmio di tempo in futuro!

Aggiungerò anche che puoi optare per l'opzione 1. se sei in una corsa per ottenere qualcosa sul mercato o se stai realizzando prototipi. Ricorda che il risultato finale di quel pezzo di lavoro dovrebbe essere idealmente rm -rf *

Dipende. Su un sacco di cose, ma una cosa che gli altri hanno mancato è che dipende dalle dimensioni del progetto. Per progetti complessi di grandi dimensioni, il debugging può essere mostruoso e avere profonde ramificazioni. Una pianificazione e una struttura adeguate possono far risparmiare una quantità significativa di tempo. Piccoli progetti semplici, d'altra parte, sono più facili da eseguire il debug. C'è solo così tante parti mobili.

Più grande è il progetto, maggiore è l'attenzione che devi fare per non creare un grande mal di testa.

Personalmente, io faccio # 2. Non dico che qualcosa è fatto a meno che non sappia che passerà il test. Sì, mi spinge a prendere più tempo e spesso vado oltre i miei orari assegnati sui biglietti.

Quando chiudo un ticket, è molto raro che il QA me lo rispedisca. Quindi non mi fa risparmiare tempo, ma risparmia tempo alle squadre di QA perché non devono ripetere i test se ci sono dei bug.

Il mio manager ha accettato che per ogni ora vado avanti ora, cioè 2 o più ore che non sprechiamo nei test.

È lento? Ya, a volte. Ma trovo che sia più veloce a lungo termine. Mettere lo sforzo in più ora potrebbe salvarmi dal lavorare un fine settimana o due prima della fine del progetto risolvendo tutti i difetti. Questo per me vale la pena. :)

Se devo scegliere solo tra quelli 2 e poi sicuramente il numero 1. Ma io non scegliere tra i 2. Dalla tua descrizione, sembra che la maggior parte del lavoro che fai sia concettuale, pensando al codice e come dovrebbe funzionare. Per me, una parte importante del processo di sviluppo è vedere cosa fa realmente il codice quando viene compilato. Naturalmente, posso risolverlo nella mia testa, ma questo non significa sempre che il compilatore lo farà nel modo in cui penso che lo farà. Quello che faccio è, in sostanza, un codice, una compilazione e un ciclo di test in cui rilevo gli errori in anticipo senza dover passare un'ora a guardare una riga di codice. In questo modo puoi produrre risultati molto più velocemente e mantenere un'alta qualità. Al momento non sono in un ambiente TDD, ma sto lavorando per implementarne uno.

Fai in modo che sia veloce e sporco per provare il tuo concetto. Assicurati di aver effettivamente dimostrato il concetto che stai cercando di dimostrare, quindi buttalo via (voglio dire, cancellalo).

Ora fallo di nuovo, ma questa volta seguendo il processo corretto e la programmazione difensiva. Ci vorrà molto meno tempo di quanto pensi, perché sai già cosa stai facendo, e il tuo codice sarà molto meglio di qualsiasi cosa tu abbia potuto inventare facendo solo il quick-and-dirty.

Jarrod ha risposto a questo lungo la dimensione della situazione aziendale.

Anche se questo è valido, penso anche che la risposta varia in base al tipo di programma o anche a parti o "livelli" diversi dello stesso programma di grandi dimensioni.

Nel profondo di un "motore" usato ampiamente dal programma, esso pagherà per andare lento, costante, attento. Fare uso di test Fatti un favore e definisci le interfacce in modo abbastanza ristretto da non aver bisogno di un test di bazillion per coprire un eccesso di permutazioni.

Ma più vicino ai "bordi" del programma, come l'interfaccia utente o le interfacce verso le API esterne in evoluzione, è probabilmente più saggio andare più veloce. Dopo tutto, è più probabile che i requisiti cambino. Inoltre, è più probabile che tu trovi problemi tramite l'osservazione diretta da parte tua e dei beta tester, piuttosto che ti stai masturbando scrivendo elaborate suite di test che hanno meno speranza di ottenere una copertura completa.

Fondamentalmente questo è il senso comune, escluso dalla tua valutazione di quanto possa essere stabile o ben definita una data parte del programma.