Quali passi pratici prendi per assicurarti di essere completo? [duplicare]

Fai 1 cosa alla volta e procedi alla seconda cosa solo dopo aver finito con la prima. Ti sei perso quei bit [httpPost] perché non hai scritto un controller e tutto il suo codice associato, sei andato direttamente al prossimo prima di aver completato il primo.

Lo facciamo tutti in una certa misura, e in genere è causato dalla codifica che ignora ciò che il tuo codice farà in azione.

l'altro aspetto è il test, il tuo metodo di controllo ha funzionato? Se no, perché no! La codifica non riguarda la scrittura del codice. La sua parte di documentazione, analisi, codifica e test. Se ti manca qualcuno di questi passaggi, allora sei solo un dilettante che borbotta la tastiera.

Non devi fare molto per queste cose, ma le devi fare. La documentazione può semplicemente aggiungere i commenti giusti, l'analisi può essere una semplice passeggiata in testa prima di iniziare, il test può essere eseguito semplicemente attraverso il codice finale nel debugger. Puoi fare queste cose più a fondo se vuoi e avere il tempo, ma devi farlo per creare un buon prodotto.

What approach do you take (or what do you incorporate into your approach) to coding tasks that help avoid carelessness and ensure you're doing a thorough job?

Io in generale non lo faccio - è una perdita di tempo.

Gli attributi mancanti sono una correzione di 30 secondi e saranno facilmente catturati dai tester / test di integrazione / UAT / qualunque. Nella mia posizione attuale (e altri che ho tenuto), questo tipo di errore è facilmente correggibile e ha un impatto minimo sul business. Non sto scrivendo il codice per il programma spaziale. Quindi non ho intenzione di implementare dire ... un processo di 30 minuti per prendere una correzione di 30 secondi.

Do you write out what you want to do in plain text or pseudo code first?

Raramente. L'unico motivo per cui lo scrivo è che posso eseguire il piano da altri per assicurarmi che non trascuri le cose grandi .

Do you break your tasks down into much more smaller tasks first with your own set of low-level requirements?

Dipende da cosa intendi. In molti lavori, romperò le storie degli utenti (lavoro di 1-2 settimane) in attività (lavoro di 0-2 giorni). Questo però non mi aiuterà a cogliere gli attributi trascurati.

Do you use unit tests to a level that's granular enough to help defend against silly mistakes?

Assolutamente. Perché i test unitari in genere catturano questo tipo di errori stupidi. Gli strumenti di copertura del codice possono aiutarmi a vedere quali elementi sono (probabilmente) sufficientemente testati e quali parti potrebbero aver bisogno di più occhi. I test unitari dovrebbero essere di circa 5 righe di codice e dovrebbero avere solo una ragione per fallire. Il mondo reale a volte lo impedisce, ma sì, dovrebbero essere così granulari.

Questo non sarebbe d'aiuto per gli attributi sul controller, motivo per cui i test unitari sono solo una parte di un approccio di test a più livelli.

Per lo più, sembra che ti preoccupi delle banalità. Ricorda il vecchio idioma - "Perfetto è il nemico del bene".

Molte buone risposte già, quindi non le duplicherò. Tuttavia, un altro processo che ho trovato utile è eseguire un'autovalutazione del tuo codice prima di inviarlo.

Questa è una cosa molto semplice da fare e ti renderà le vite dei tuoi compagni di squadra rivedere il tuo codice molto più facilmente. Tutto quello che fai è guardare il tuo diff prima di inviarlo e fare una rapida revisione del codice te stesso. Se si inviano note ai colleghi che spiegano il cambiamento, è il momento di scrivere anche quelli. Trovo che passare attraverso la recensione al fine di renderlo accessibile ai miei compagni di squadra mi aiuti a individuare le cose che potrebbero essere più chiare, o passaggi di pulizia che ho perso. Inoltre, durante la revisione, i tuoi compagni di squadra risparmiano tempo perché trovano meno elementi da risolvere.

Un approccio che ho preso è stato molto utile è:

iniziare con il test di accettazione senza implementarlo per fornire il contesto di ciò su cui è necessario lavorare e poi tuffarsi nella costruzione della struttura.

Una volta che c'è una struttura (cioè ho classi, interfacce, alcuni metodi non implementati) vado avanti e inizio a scrivere test unitari per qualsiasi cosa abbia senso. Prova a non forzare il test dell'unità o finirai per testare cose che non ti servono.

Non penso che questo sia puro TDD perché non scrivo prima tutti i miei test. Invece, sto scrivendo uno o due test di alto livello per vedere più chiaramente la struttura nella mia mente e poi vado avanti e la implemento. Ci sono alcuni motivi per cui questo è utile e perché può tenerti lontano dal fare errori stupidi.

1) Per prima cosa vedi l'immagine grande nella tua implementazione. Anche se non hai implementato il test di accettazione, vedi già i tuoi input e le uscite richieste. Questo offre un sacco di contesto e come dovresti andare avanti. Quindi una visione chiara, che ti aiuterà a essere più accurato.

2) Stai seguendo TDD (anche se non completamente) che mantiene il tuo codice testabile in ogni momento e quindi con una maggiore probabilità di essere disaccoppiato. Questo è solo un buon design.

3) Quando comprendi il contesto di ciò che viene lavorato nella tua mente è più comodo pensare ai dettagli di basso livello, permettendoti di ridurre la quantità di errori stupidi che avresti potuto fare diversamente .