C'è una ragione per cui "Test Driven Development" è diventato estremamente popolare oggi - permette agli sviluppatori di scrivere un po 'di test, un po' di codice, compilarlo, testare un po '(magari eseguirne il debug, se necessario) e refactoring - in cicli misurati in minuti , non in giorni o ore. Quindi c'è un ampio consenso sul fatto che non è sicuramente una buona idea scrivere un blocco di 500 righe di codice e quindi lasciare che il codice funzioni la prima volta, vedere se si blocca (cosa che molto probabilmente lo farà), e quindi iniziare a guardare per tutte le possibili cause di root (che sono molte in un blocco di codice di quelle dimensioni).
C'è solo una situazione in cui posso pensare di codificare a grandi passi e "debugare più tardi" potrebbe far risparmiare tempo - quando si hanno tempi di turn-around molto grandi. Quando ogni ciclo di build richiede 30 minuti o più, non si desidera compilare, compilare e eseguire il debug dopo ogni 10 nuove righe di codice.
Fortunatamente, la maggior parte degli ambienti di sviluppo oggi non impone tempi di compilazione simili agli sviluppatori, e persino nei progetti C ++ su larga scala, ci sono mezzi disponibili per mitigare tali problemi.
Tuttavia, non è solo una questione di ambiente, ma è anche una questione di strutturare il tuo progetto in componenti . Se è possibile implementare, ad esempio, 450 linee delle 500 linee totali del codice in un componente separato, che può essere compilato e testato separatamente dal resto del sistema (magari utilizzando TDD, o almeno utilizzando i test di unità), allora può (e dovrebbe) sviluppare il componente nel minor numero possibile di cicli di codice / compilazione / test / debug, anche se una compilazione completa del sistema impiegherebbe più di un'ora. Successivamente, è possibile completare la fase di integrazione separata con le ultime 50 righe di codice "en block".