Quali sono le peggiori cose a cui gli sviluppatori inesperti dimenticano di pensare? [chiuso]

Trovo che la cosa principale che i nuovi sviluppatori dimenticano è che nel mondo reale spesso lavorano come membri di una squadra. Questo si mostra come ..

• Verifica del codice che interrompe il file build
• Non riutilizzare il codice che è già lì
• Fare le cose a modo loro piuttosto rispetto allo stesso modo di tutti gli altri - che rende costosa la manutenzione

Questo non vuol dire che il loro codice non risulti isolato, ma non funzionano più separatamente.

1. Test.
2. Test.
3. Altri test.
4. Controllo del codice sorgente
5. Tasse appropriate per qualsiasi programma tu abbia scelto come target.

Su Windows, queste imposte sono :

• Gestione degli ambienti con DPI elevato
• Profili utente mobili
• Cambio rapido utente
• Desktop remoto (ad esempio, non si desidera utilizzare il doppio buffering quando RDP è attivo
• Giocare bene con Hierarchical Storage Management
• Monitor multipli
• Windows a 64 bit

Su praticamente tutte le piattaforme, dovrai occuparti di:

• Unicode
• Localizzazione
• Power Managment

Nella mia esperienza, l'unica cosa che quasi tutti gli sviluppatori inesperti non tengono a mente è che tu lavori (quasi sempre) in un ambiente commerciale. Il tuo codice deve essere buono, ma non perfetto. La cosa più importante non è la perfezione, è che il tuo codice viene spedito.

In altre parole, consegnare il codice perfetto tre mesi dopo che la tua azienda è fallita non è una buona cosa per nessuno.

Secondo me, questo è uno dei modi più significativi in cui lo sviluppo nel mondo reale differisce dallo sviluppo come insegnato all'università.

Domanda davvero ampia; per rispondere in dettaglio è ... più libri.

Ecco un elenco di controllo generale per la definizione dei sistemi per iniziare:

• Quali sono le risorse critiche nel sistema e in che modo potrebbero cambiare le loro richieste?
• Quali sono le capacità di prestazione del sistema e in che modo potrebbero aver bisogno di crescere?
• Quali aree di richiesta potrebbero non essere necessarie e rimovibili?
• Esiste la possibilità di avere versioni diverse del sistema con capacità diverse?
• Quali sono le implicazioni sulla manodopera e sulle risorse del computer se i cambiamenti identificati si verificano?
• Che impatto avrà il nuovo sistema sui sistemi operativi esistenti?
• Quali aree di funzione hanno maggiori possibilità di richiedere cambiamenti alla luce dell'esperienza con il sistema?
• Chi sono i futuri utenti del sistema?
• Quali sono i futuri manutentori del sistema?
• Quali sono i miglioramenti futuri che i futuri utenti del sistema possono identificare con tutta probabilità?
• In che modo il sistema si adatta ai piani generali dell'utente e come si prevede che si sviluppino?

Il disaccoppiamento pulito del sistema sulla macchina di sviluppo e sulla macchina target, in modo che non si giunga a situazioni "Bene, funziona sulla mia macchina".

E quanto velocemente puoi ricostruire la tua macchina di sviluppo?

• Sai quali pacchetti ti servono?
• Hai una soluzione a pulsante per ricostruire il tuo database?
• Hai una soluzione a pulsante per testare l'integrità del codice sorgente?

Penso che probabilmente sia il design, ovvero l'approccio di pensare a cosa farai prima di farlo.

Troppi programmatori inesperti (ricorda quando hai iniziato per la prima volta) amano saltare e ottenere qualcosa, quindi aggiungere un po 'di più e aggiungere un po' di più e aggiungere un po 'di più. Questo approccio può funzionare se hai pianificato di farlo in quel modo (ogni bit può essere testato come fai tu dopo tutto), ma molti coder inesperti si concentrano solo sulla parte che stanno scrivendo .. quindi tutte le aggiunte tendono ad essere violate in cima. E abbiamo visto tutti codice che si è evoluto in questo modo!

L'organizzazione è la prossima cosa, spesso sono troppo concentrati sul codice che hanno scritto per ricordare come l'hanno fatto e cosa è stato richiesto. Quindi dimenticano di raggruppare o documentare una dipendenza richiesta. Tendono anche a mettere le cose dove cadono, ho dovuto criticare un giovane la scorsa settimana che ha controllato il suo codice nella directory radice includendo 3 wsdls, 2 dei quali erano lo stesso file, e un set di dll di terze parti che ha commesso in una sottodirectory e la directory root. Il codice non è stato formattato in base a nessuno degli standard che potevi immaginare, e c'erano diverse funzioni presenti ma mai chiamate.

Ovviamente l'ha fatto funzionare ma non era ordinato, e questo significava che l'installazione e la manutenzione sarebbero state problematiche.

Penso che le maggiori differenze siano nella tecnica di codifica. Ognuno ha un approccio leggermente diverso, ma gli sviluppatori inesperti tendono a produrre codice che:

• non gestisce i casi limite
• è molto più lungo del necessario
• ha cattive caratteristiche delle prestazioni in scenari rilevanti
• ha una scarsa separazione di preoccupazioni
• manca di tecniche di auto protezione come l'uso di const, sealed, readonly, ecc.
• modi stravaganti di restituire dati e raccolte di dati
  • questo dimostra ancora l'inesperienza con una piattaforma

Poiché hai chiesto le cose peggiori, la mia risposta è la seguente:

1. Hai dimenticato di pensare di disinfettare la macchina di sviluppo da spyware, malware e virus trojan.
2. Hai dimenticato di pensare di fare un backup normale salvato in archivi sicuri che si trovano in diverse posizioni geografiche.