Quando sei sotto pressione, la scadenza si avvicina e un manager ti sta abbassando il collo ti ritrovi a scrivere codice cattivo? Il TDD e le migliori pratiche scivolano sul ciglio della strada per fare le cose? Cosa fai in situazioni del genere? Quali sono state le tue esperienze?
In una parola, sì. Chiunque ti dica altrimenti è probabilmente, nel migliore dei casi, confuso.
Tuttavia, la chiave è costruire sulla tua esperienza per scrivere codice che è meno cattivo. Resisti alla tentazione di inserire qualcosa per farlo funzionare "solo se possibile, perché non lo farà. Hai ancora bisogno di seguire una sorta di processo (sia esso di tua scelta, o della tua azienda, o qualche mix di questi).
L'esperienza mi dice che è molto meglio ( gasp ) far scorrere il programma un paio di giorni per evitare una settimana di correzioni, specialmente quando "sotto pressione" significa una versione rapida della produzione. Se ti stai affrettando a rilasciare il codice, i tester probabilmente avranno anche fretta di rubberstamp.
Le scadenze mancanti sono un segno di scarsa pianificazione e stima. Riconoscere che la scadenza sarà persa e risolvere il problema. A volte non hai il controllo sulla stima o di pianificazione. Identifica chi fa e assicurati che sappia che è stato fatto per errore.
In una situazione in cui la scadenza non può essere spostata, si rompono le bevande altamente contenenti caffeina e ci si mette fretta. Identifica qualsiasi cosa tu possa sacrificare e ritagliare. Prendi ciò che è rimasto e implementalo il più velocemente possibile. Ciò causerà problemi come instabilità, errori dispari, pratiche di codifica inefficienti, correzioni di aiuti per la banda e ogni sorta di altri orrori. Non è necessariamente un codice cattivo , ma è non ideale .
A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature.
Da Joel on Software Il programmatore di nastri Duct .
Non è possibile trattare il codice ideale con se è gestito . Il codice che non è stato trattato si accumulerà e, a sua volta, renderà le modifiche aggiuntive più difficili, se non impossibili. Può arrivare al punto in cui l'applicazione è così interconnessa, che le aggiunte possono essere fatte solo dai programmatori più attenti a un costo esorbitante. Mentre la spedizione è una caratteristica, quindi la manutenibilità.
Sono un grande fan dell'ingegneria del software - scrivere codice pulito nel miglior modo possibile, ecc., ma a volte ho dovuto correre nei momenti in cui il tempo stringe e si avvicina una scadenza. Cerco davvero di non farlo nel miglior modo possibile, ma a volte non riesci a liberartene.
Alcune persone diranno "Beh, questa è la vita, devi spedire" ma non sono d'accordo con questo atteggiamento.
Quando scrivi un codice frettoloso, potresti finire per avere il software fuori dalla porta in tempo, ma cosa succede quando, durante i prossimi giorni, finisci per ricevere chiamate di supporto relative ai bug nel software (questi bug che vivono in lo stesso pezzo di codice che hai corso per finire). Oppure ricevi un cliente arrabbiato che ti chiede perché il loro modulo di segnalazione non funziona più, anche se hai promesso che sarebbe andato bene il giorno della pubblicazione?
È tutto molto bello dire "Devi spedire" , ma c'è una differenza tra l'aspetto efficiente e l'aspetto di un lavoratore sciatto.
Saluti. Giac.
Quando mi trovo in una situazione di stress, il mio codice è pensato per completare il lavoro. Questo è tutto. Non mi concentro sull'efficienza e su altri problemi, il che è negativo, a mio parere.
Ci lavorerò comunque.
Non credo di scrivere personalmente codice significativamente peggiore, ma fornisco un prodotto peggiore.
Di fronte a una scadenza arbitraria e impossibile, ci preoccupiamo del processo di sviluppo. Facciamo più revisioni superficiali del codice (o saltandole del tutto). Testiamo di meno, eludiamo i test unitari dettagliati per i test di integrazione di tipo spot-check, quindi proviamo a contare il test di integrazione come una qualifica formale. Tendiamo a trascurare le anomalie durante i test se non sono direttamente legati ai criteri di pass-fail. Saltiamo gli aggiornamenti della documentazione, non controlliamo le note di rilascio, dimentichiamo di sfogliare l'elenco dei risultati per i file che non sono più necessari.
Il codice sorgente che scrivi durante un crunch può essere di alta qualità, ma verrà quasi certamente spedito come parte di un prodotto scadente.
Dipende.
La pressione è dovuta perché non è possibile fare tutto e perché le nuove funzionalità principali vengono aggiunte ore prima del rilascio?
Codice errato in arrivo!
Ma se è perché il programma è semplicemente molto stretto, ma il piano complessivo è solido e devo solo lavorare molto più del solito e rimanere concentrato continuamente mentre modifico alcune funzioni, ascoltarlo e ... Poi produco molto codice migliore rispetto a se il programma consente un sacco di tempo. Anche se questo significa che non riesco a scrivere tutti i test unitari ma coprire le parti principali del codice.
Conosco qualcuno che non scrive mai codice cattivo sotto pressione. Ha anche dei fagioli magici a cui potresti essere interessato.
A volte tutti scrivono codice errato e le solite scadenze sono la solita ragione, il trucco è evitare di entrare in quella situazione in primo luogo (e anche questo non è facile).
Leggi altre domande sui tag bad-code