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

Come giovane sviluppatore, troverei utile avere qualche consiglio su cose a cui pensare per sviluppare un'applicazione di alta qualità. Nei miei corsi universitari, la maggior parte degli insegnanti ha sottolineato la convalida dell'input e alcuni hanno parlato di problemi di sicurezza, ma nessuno ha coperto l'importanza di alcune altre cose, come ad esempio la registrazione.

Quali sono alcuni errori che gli sviluppatori inesperti tendono a fare e che potrebbero portare alla frustrazione per gli sviluppatori più esperti?

Trovo che la cosa principale che i nuovi sviluppatori dimenticano è che nel mondo reale spesso lavorano come parte di un team. Questo si mostra come ..

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

Questo non vuol dire che il loro codice non sia all'altezza da zero, ma non funzionano più da soli.

1. Test.
2. Test.
3. Più test.
4. Controllo della fonte
5. Tasse adeguate a qualunque programma tu stia prendendo di mira.

Su Windows, queste tasse sono :

• Trattare con ambienti ad alto DPI
• Profili utente mobili
• Cambio rapido utente
• Desktop remoto (ad es. Non si desidera utilizzare il doppio buffering quando RDP è attivo
• Giocare bene con Hierarchical Storage Management
• Monitor multipli
• 64 bit di Windows

Praticamente su ogni piattaforma, dovrai occuparti di:

• Unicode
• Localizzazione
• Gestione del potere

Nella mia esperienza, l'unica cosa che quasi tutti gli sviluppatori inesperti non riescono a tenere a mente è che stai (quasi sempre) lavorando 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.

Detto in altro modo, fornire il codice perfetto tre mesi dopo che la tua azienda è fallita non fa bene a 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; 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 come potrebbero cambiare le richieste?
• Quali sono le capacità prestazionali del sistema e come potrebbero essere necessarie per crescere?
• Quali aree del requisito potrebbero diventare inutili 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 in caso di cambiamenti identificati?
• Quale impatto avrà il nuovo sistema sui sistemi operativi esistenti?
• Quali aree funzionali 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 potranno identificare come probabili?
• Come si adatta il sistema ai piani generali dell'utente e come dovrebbero svilupparsi?

Il disaccoppiamento pulito del sistema sulla propria macchina di sviluppo e della macchina target, in modo che non si finisca con situazioni "Bene, funziona sulla mia macchina".

E quanto velocemente puoi ricostruire la tua macchina di sviluppo?

• Sai quali pacchetti sono richiesti?
• Hai una soluzione a pulsante per ricostruire il tuo database?
• Hai una soluzione a pulsante per testare l'integrità sul codice sorgente?

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

Troppi programmatori inesperti (ricorda quando hai iniziato) piace saltare e iniziare 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 questo modo (ogni bit può essere testato come fai dopo tutto), ma la maggior parte dei programmatori inesperti si concentra solo sulla parte che stanno scrivendo .. quindi tutte le aggiunte tendono ad essere hackerate in cima. E abbiamo visto tutti codice evoluto in questo modo!

L'organizzazione è la prossima cosa, spesso sono troppo concentrati sul codice che hanno scritto per ricordare come lo 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 junior la scorsa settimana che ha controllato il suo codice nella directory principale tra cui 3 wsdls, 2 dei quali erano lo stesso file e un set di dll di terze parti in cui si è impegnato una sottodirectory e la directory principale. Il codice non è stato formattato secondo nessuno standard a cui potresti pensare, e c'erano diverse funzioni che erano presenti ma mai chiamate.

Ovviamente lo ha fatto funzionare ma non era ordinato, e ciò 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
• presenta cattive caratteristiche prestazionali in scenari rilevanti
• ha una scarsa separazione delle preoccupazioni
• manca di tecniche autoprotettive come l'uso di const, sigillato, di sola lettura, ecc.
• modi strani per restituire dati e raccolte di dati
  • questo dimostra di più l'inesperienza con una piattaforma

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

1. Ho dimenticato di pensare a sanificare la macchina di sviluppo da spyware, malware e virus trojan.
2. Hai dimenticato di pensare di fare un backup regolare salvato in archivi sicuri che si trovano in diverse aree geografiche.

Il mio più grande è ricordare di pianificare la flessibilità. Nelle classi, i requisiti sono quasi sempre stabiliti all'inizio e non cambiano mai. Nel software, è spesso il contrario: ottieni una serie di requisiti vaghi e cambiano spesso (anche quotidianamente). La cosa migliore che puoi fare per aiutarti è codificare in modo flessibile: accoppiamento lento, piccole funzioni che possono essere utilizzate in modo affidabile in più situazioni ed evitando quanto più possibile di codificare.

Con il passare del tempo, è probabile che tu impari a) quali sono le cose che hanno maggiori probabilità di cambiare e, al contrario, che cosa probabilmente non succederà eb) come anticipare le richieste di modifica e pianificarle.