Come evitare errori e non perdere nulla [duplicato]

I would like to know how I can schedule the job to not forget anything

Non puoi. Che tu sia Robin Seggelmann o Donald Knuth, scrivere un programma per computer di qualsiasi dimensione realistica non è semplicemente un compito che la mente umana può raggiungere interamente senza errori. Questa è una semplice verità, è spesso ignorata perché la mente ha una capacità avanzata fantasticamente di sopravvalutare i propri poteri. Di fatto, di solito assume che sia infallibile, ma in pratica non lo è mai.

or at least soon realize that I have forgotten something or have missed something

Questo è il test. I test non sono una disgrazia, è una parte normale e atteso dello sviluppo. (È debugging che è una vergogna, perché il debug indica che hai scritto codice in cui tu stesso non capisci come funziona.)

Test, test, test. Test automatizzati. TDD. BDD.

Quasi tutte le persone commettono errori (e alcuni costosi ** ahem **). Non aver paura di loro, impara da loro quando commetti degli errori. E prova il tuo codice. Guarda i possibili punti in cui può fallire (ai limiti dei dati, in casi speciali, ...) e creare test appropriati.

Non sono un programmatore esperto, ma direi che dovrai testare il tuo codice per essere sicuro di ciò che hai scritto. Non eviterai mai errori di programmazione (siamo tutti esseri umani), ma puoi provare e testare il tuo codice tutto il tempo.

Come certamente avete capito, il test è la soluzione.

Ci sono molte cose che potrebbero aiutarti.

1. Creazione di test automatici. Esistono strumenti come Junit per Java e Nunit o il test di unità integrato di Visual Studio per .Net. Più il tuo codice è coperto da questi test, meglio sarà. (Ci sono strumenti per questo, per favore Google). Questi test dovrebbero essere eseguiti automaticamente quando costruisci la tua applicazione.
2. Se hai tempo, crea piani di test per i test di integrazione e tutti i test che non puoi eseguire automaticamente.
3. Tieni traccia dei bug (ci sono strumenti per questo, come JIRA, Bugzilla, ecc.) e non dimenticare MAI di aggiornare i tuoi test automatici e i piani di test in modo da poter rilevare eventuali regressioni.
4. Più in generale se il tuo progetto ne consente l'utilizzo Test Driven Development (TDD) che richiede fondamentalmente di scrivere il tuo test prima di implementare la tua funzionalità.

Nota che questi punti dovrebbero essere implementati da tutto il tuo team. Forse c'è qualcosa da suggerire al tuo capo squadra o al tuo project manager.

La programmazione è un'attività bizzarra. Rispetto a qualsiasi altra attività umana, è privo di qualsiasi feedback innato .

Spesso lo illustro confrontando il nostro lavoro con quello di un muratore:

Per diventare un bravo muratore occorre tempo e pratica. È necessario sviluppare una sensazione per i mattoni, la malta e gli strumenti. Una cosa che aiuta nel mondo fisico è che l'attività dei mattoncini è piena di feedback .

You prepare the next layer of bricks by putting up a line (a length of string aligned with the top of the new layer). Then you drop down some mortar, the amount of which you can feel when lifting it out of its bucket. So, you can see where the next line of bricks go, and you can feel the right amount of mortar. When you put it down, you can hear how it drops, which again confirms the amount used, and if it was placed correctly.

Next, you can pick up the next brick, and sensing its weight, you know exactly how to move it and again you use your sight and touch to decide where to drop it. The moment it touches the mortar, you know how it drops in place.

Any deviations from the norm are automatically corrected, as you know immediately that things need to be adjusted. You don't have to think about it, as this becomes second nature.

Quindi, come potremmo sviluppare questo innato feedback nella programmazione, quando quel feedback visibile e tattile non è presente?

Il più vicino che abbiamo ottenuto finora, per quanto posso vedere, è di introdurre questo feedback con Test Driven Development, e la codifica insieme.

Lavorare insieme sullo stesso codice ti costringerà a serializzare i tuoi pensieri in parole, parole. Scrivere per primi i test falliti ti darà la certezza che stai scrivendo test sensati , che ti aiuteranno a orientarti verso una soluzione di lavoro.

Un metodo che funziona per me è tenere nota di tutto ciò che mi viene in mente quando sto codificando. Non permetto che mi distraggano e continuino a scrivere quello che sto codificando e poi li rivedo tutti alla fine.

Ad esempio, riceverò metà del codice di elaborazione dei dati e improvvisamente penserò "Spero di aver corretto il lettore di file". Faccio una breve nota e proseguo con il codice di elaborazione dei dati.

Altrimenti ho scoperto che stava succedendo era pensavo "Spero di aver sistemato quel lettore di file correttamente", andare a quel bit di codice, controllarlo e correggerlo se necessario e poi tornare al codice di elaborazione dei dati. A quel punto avevo perso il filo del pensiero e la parte di elaborazione dei dati sarebbe piena di bug.

Cerca di tenere una nota su tutto ciò che devi pensare, ma non distrarti dalla tua attuale attività di codifica o introduci altri bug.

• Codice per l'attuale serie di requisiti. Non aggiungere alcuna infrastruttura per funzionalità che non esistono: complicheranno il tuo codice senza offrire alcun vantaggio immediato. Se provi ad anticipare le funzionalità future, probabilmente ti sbagli comunque.
• Non ottimizzare nulla finché non hai misurato, confermato di avere un problema, profilato e trovato il collo di bottiglia.
• Evita null come la peste. In effetti, vietalo apertamente. È un difetto linguistico e un buco nel sistema dei tipi. Nulla di buono deriva dall'uso di null .
• Evita lo stato mutabile. Questa sarà una sfida al di fuori dei linguaggi di programmazione funzionale, ma dovresti cercare di farlo nella misura in cui la tua lingua lo renderà pratico. Non schiaffeggia automaticamente i setter sulle tue classi se riesci a costruire banalmente un nuovo oggetto con i giusti valori. Non utilizzare una struttura dati mutevole se è disponibile una versione persistente .
• Assicurati che il comportamento di qualsiasi funzione o classe che scrivi sia completamente e completamente documentato. (Scrivere piccole funzioni e classi che fanno solo una cosa sarà di grande aiuto qui.)
• Scopri come costruisci una prova . Non deve essere estremamente formale.
• Chiedi ad altre persone di rivedere il tuo codice e le prove (se ce ne sono).
• Unit test il tuo codice religiosamente nel caso in cui qualcosa fosse trascurato. Non preoccuparti di testare ogni piccolo scenario qui - non è produttivo. Questo è un controllo di sanità mentale; prova una piccola manciata di casi che potrebbero rompersi o sono particolarmente difficili.

Anche dopo aver fatto tutto questo, non dimenticare le parole di Knuth:

Beware of bugs in the above code; I have only proved it correct, not tried it.