Scrivi cattivo codice quando sei sotto pressione? [chiuso]

Quando sei sotto pressione, la scadenza si avvicina e un manager ti respira al collo ti ritrovi a iniziare a scrivere un codice errato? TDD e le migliori pratiche scivolano ai margini per portare a termine le cose? Cosa fai in situazioni del genere? Quali sono state le tue esperienze?

In una parola, sì. Chiunque ti dica altrimenti è probabilmente, nella migliore delle ipotesi, sbagliato.

Tuttavia, la chiave è costruire sulla tua esperienza per scrivere codice meno male. Resistete alla tentazione di mettere qualcosa per farlo "funzionare" se possibile, perché non lo farà. Hai ancora bisogno di seguire una sorta di processo (che sia il tuo, o la tua azienda, o una combinazione di questi).

L'esperienza mi dice che è molto meglio ( ansimare ) di scivolare il programma un paio di giorni per evitare correzioni per una settimana, specialmente quando "sotto pressione" significa un rilascio rapido alla produzione. Se stai affrettando a rilasciare il codice, probabilmente i tester avranno fretta di ripubblicarlo.

Se la squadra è in crisi, qualcosa non ha funzionato.

Le scadenze mancanti sono un segno di scarsa pianificazione e stima. Riconosci che la scadenza non verrà rispettata e risolvi il problema. A volte non hai il controllo sulla pianificazione o sulla stima. Identifica chi lo fa e assicurati che sappiano che ciò è stato fatto per errore.

In una situazione in cui la scadenza non può essere spostata, fai scoppiare le bevande altamente contenenti caffeina e ti precipiti. Identifica tutto ciò che puoi sacrificare e ritaglialo. Prendi ciò che resta e implementalo il più velocemente possibile. Ciò causerà problemi come instabilità, errori strani, pratiche di codifica inefficienti, correzioni di aiuti di banda e ogni sorta di altri orrori. Non è necessariamente un codice errato , ma non è l' ideale .

Una buona soluzione del 50% che le persone hanno effettivamente risolve più problemi e sopravvive più a lungo di una soluzione del 99% che nessuno ha perché è nel tuo laboratorio in cui stai lucidando all'infinito quella dannata cosa. La spedizione è una caratteristica .

^{Da Joel on Software The Duct Tape Programmer .}

Il codice non ideale può essere trattato se trattato . Il codice che non è stato trattato si accumulerà e, a sua volta, renderà più difficili ulteriori modifiche, se non impossibili. Può arrivare al punto in cui l'applicazione è così legata tra loro in modo interdipendente che le aggiunte possono essere fatte solo dai programmatori più attenti ad un costo esorbitante. Mentre la spedizione è una caratteristica, quindi è manutenibilità.

Sono un grande fan della maestria del software: scrivere codice pulito nel miglior modo possibile, ecc., Ma a volte ho dovuto correre in momenti in cui il tempo è breve e una scadenza si avvicina. Cerco davvero di non farlo nel miglior modo possibile, ma a volte non puoi evitarlo.

Alcune persone diranno "Beh, questa è la vita, devi spedire" ma non sono davvero d'accordo con questo atteggiamento.

Quando scrivi codice in fretta, potresti finire per ottenere il software fuori dalla porta in tempo, ma cosa succede quando, nei prossimi giorni, finisci per ricevere chiamate di supporto relative a bug nel software (questi bug vivono nello stesso pezzo di codice ti sei precipitato per finire). Oppure hai un cliente arrabbiato che ti chiama chiedendoti perché il loro modulo di segnalazione non funziona più, anche se hai promesso che sarebbe andato bene il giorno del rilascio?

Va benissimo dire "Devi spedire" , ma c'è una differenza tra un aspetto efficiente e un lavoratore sciatto.

Sì. Ma torna sempre a perseguitarmi più tardi.

Quando sono in una situazione di stress, il mio codice è pensato per portare a termine il lavoro. Questo è tutto. Non mi concentro sull'efficienza e su altre questioni, il che è un male, a mio parere.

Ci lavorerò comunque.

Non credo di scrivere personalmente un codice significativamente peggiore, ma consegno un prodotto peggiore.

Di fronte a una scadenza arbitraria e impossibile, risparmiamo sul processo di sviluppo. Facciamo revisioni del codice più superficiali (o le saltiamo del tutto). Testiamo meno, aggiriamo i test dettagliati dell'unità per i test di integrazione del tipo di controllo a campione, quindi proviamo a contare il test di integrazione come una qualifica formale. Tendiamo a trascurare le anomalie durante i test se non sono direttamente legate a criteri di fall-pass. Saltiamo gli aggiornamenti della documentazione, non ricontrolliamo le note di rilascio, dimentichiamo di cancellare l'elenco dei risultati finali per i file che non sono più necessari.

Il codice sorgente che scrivi durante uno scricchiolio può essere di alta qualità, ma quasi sicuramente verrà spedito come parte di un prodotto scadente.

Dipende.

La pressione è dovuta al fatto che non è possibile fare tutto e perché sono state aggiunte nuove importanti funzionalità ore prima del rilascio?

Codice errato in arrivo!

Ma se è perché il programma è semplicemente molto stretto, ma il piano generale è solido e devo solo lavorare molto più duramente del solito e rimanere costantemente concentrato mentre ottimizzo alcune funzionalità ascoltate e lì ... Quindi produco un codice molto migliore di se il programma consente tonnellate di tempo. Anche se ciò significa che non riesco a scrivere tutti i test unitari, ma coprono le parti principali del codice.

Conosco qualcuno che non scrive mai codici errati sotto pressione. Ha anche alcuni fagioli magici che potrebbero interessarti.

Tutti scrivono codice errato a volte e le scadenze incombenti sono la solita ragione, il trucco è quello di evitare di entrare in quella situazione in primo luogo (e neanche questo è facile).