it-swarm.it

Quando qualcuno sarebbe considerato un cattivo programmatore?

Come considereresti che un programmatore non è bravo in quello che sta facendo?

Se possibile ... Come dovrebbe migliorare?

57
Tamara Wijsman

Quando non riescono a imparare dai propri errori e dalle revisioni tra pari.

Siamo tutti verdi ad un certo punto; tuttavia, se non stai migliorando o stai cercando di migliorare, allora sei un cattivo programmatore.

134
ist_lion

Un programmatore che non sa cosa non sa e non è interessato a scoprirlo.

125
Graviton

Un grande segnale di avvertimento è se sono programmatori "cargo cult" - nel senso che fanno cose ma non sanno perché fanno quelle cose (è solo "Magia"). Ottimo post di Eric Lippert qui .

Dall'articolo:

programmatori che capiscono cosa fa il codice, ma non come lo fa.
75
Marcel Lamothe

Un grande suggerimento per me è quando pongono a te o agli altri programmatori domande sullo sviluppo che dimostrano chiaramente di aver fatto uno sforzo assolutamente nullo per capirlo da soli.

Un corollario è quando fanno più volte la stessa domanda di programmazione indicando che non stanno interiorizzando le informazioni.

45
JohnFx

Quando impiegano molto tempo per risolvere il problema FizzBuzz.

21
EpsilonVector

I programmatori che si rifiutano di apprendere nuove tecnologie/lingue e insistono per attenersi a ciò che già sanno.


Addendum: (aggiungendo che trattino ha detto sotto nei commenti)

Un'estensione di ciò sono le persone che conoscono un sottoinsieme delle funzionalità di alcune tecnologie ma non mostrano alcun desiderio di saperne di più. Linguaggio di programmazione, editor, altri strumenti ...

21
missingfaktor

Quando un membro del team è sviluppatore con produzione negativa .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Significa che il resto della tua squadra deve fare più lavoro a causa del cattivo sviluppatore. [~ ~ #] nnpp [~ ~ #]

18
danivovich

Quando producono cose che appartengono a The Daily WTF su base regolare.

18
Billy ONeal

Quando sanno che ci sono modi migliori di fare le cose, ma si rifiutano ancora di farle anche quando il tempo lo consente.

15
JeffO

Personalmente penso che qualsiasi programmatore che può guardare il proprio codice che ha scritto qualche tempo fa e non trovare qualcosa di sbagliato in esso non è buono. "Un po '" può scalare con l'esperienza ... direi tra qualche settimana fino a un anno circa.

15
Daenyth

Coloro che ignorano gli avvertimenti sui loro codici e si preoccupano solo di errori.

15
Reigel

Quando ero un caposquadra in un piccolo negozio, c'erano diverse persone che dovevo riassegnare (né io né il mio supervisore diretto avevamo la possibilità di terminare senza una tonnellata di Nastro rosso e una pila di documentazione.) o di non rinnovare il contratto al termine dell'attuale incarico. Alcuni dei tipi elencati hanno funzionato anche per altri team leader e hanno praticamente adottato la stessa opinione. Cose che hanno portato la gente nella categoria "Bad Programmer" nel mio libro:

  1. Non allenabile o ossificato in passato
    Quando il "programmatore" non sembra essere in grado di assorbire il nuovo sistema, il nuovo strumento o qualunque cosa venga distribuita, indipendentemente da come viene svolta la formazione/istruzione. Deve ripetere questo allenamento su base frequente.
    Quando il "programmatore" conosce solo la tecnologia o il paradigma di codifica che hanno usato 10 o 15 anni fa. Allora era abbastanza buono, quindi perché dovrebbero cambiare?
  2. Codificatore da cowboy
    La persona che codifica per prima, senza un piano. Il "programmatore" che apporta modifiche non testate al codice di produzione e/o ai dati "perché ora dobbiamo ripararlo" e quindi è sorpreso quando la "correzione" fallisce.
    Anche il Cowboy non è sicuramente un giocatore di squadra. Non ha bisogno di una squadra puzzolente.
  3. La banderuola
    Questo "programmatore" è innamorato della "tecnologia du jour " e vede ogni nuovo framework, linguaggio, metodologia o qualunque cosa sia nuova e hot come
  4. Il "grande cervello"
    Questo "programmatore" è così sicuro del suo talento e delle sue capacità che vengono fatte cose che non hanno molto senso del progetto. ad es. Riscrivere una libreria standard "perché è inefficiente per il nostro sistema" o introdurre strumenti e tecniche non adatti al problema in questione. ad es. Presentazione di LISP o Forth in un ambiente mainframe.
  5. LOC un. Sandbagger
    Questo "programmatore" usa l'offuscamento e la cattiva direzione per aumentare il un. LOC: Righe di codice che vengono pagate. Ho visto codice in questa situazione che era pagina dopo pagina, schermata dopo schermata con struttura e logica duplicate, con solo i nomi delle variabili di controllo o paragrafo modificati per aumentare il conteggio delle righe.
  6. Esperto indispensabile
    Il 'programmatore' che ha le conoscenze di dominio per risolvere i problemi a portata di mano, ma dal momento che "sanno" tutto al riguardo. In effetti, se fossero stati colpiti da un autobus, l'intera organizzazione sarebbe precipitata. { Osservazione: Di solito sono quelli che pensano di essere indispensabili. (Qualcuno ha la fonte di questo aforisma?)}
  7. Lo chef di pasta
    Questo "programmatore" è specializzato nel codice spaghetti, aromatizzato con identificatori che sono troppo difficili da seguire senza un IDE implementato sintatticamente. ad es. IndexI1O0, Index1I0O, ecc.
  8. Stagista estivo - Sottotipo specifico di Walking Disaster
    Il mio vecchio negozio era solito assumere un certo numero di tirocinanti della scuola superiore o del college. Una volta un dipartimento aveva bisogno di un piccolo database per tenere traccia dell'utilizzo delle apparecchiature (ora questo era indietro e utilizzava dBase III). Il ragazzo ha programmato per tutta l'estate, ma non è stato fatto quando il college è iniziato in autunno. Ha avuto una proroga di una settimana e poi una seconda settimana. Alla fine della seconda settimana, sono stato inviato per riprendere il suo progetto e riportarlo allo sviluppo dei sistemi per essere completato. Mi mostrò le cose che aveva fatto e poi la parte incompiuta. Ciò che ha funzionato ha avuto piacere per gli occhi, ma l'applicazione era incompleto. Quando ho aperto la nuova scatola di floppy formattati per ottenere copie, mi ha detto "solo un secondo, fammi cancellare i miei file di test ..." e prima che potessi dire qualcosa, aveva eliminato un mucchio di file.
    Essendo un tipo sospetto e trovando che la sua applicazione non era altro che un piacere per gli occhi quando sono tornato al mio negozio, sono tornato al dipartimento e ho tirato fuori Norton e cancellato i file che aveva eliminato, cercando di trova qualche logica aggiuntiva, anche se incompleta.
    Ho trovato, non cattiva logica, ma cattivo comportamento. La stampante collegata al PC che stava usando era una stampante a margherita. Il set di caratteri normalmente montato era una variante svizzera. L'output dei programmi eliminati indica un nome, un indirizzo, un DOB, alcuni codici di lettere e un tipo di numero ID. Il formato e il layout mi hanno infastidito. Tutte le date di nascita di più persone erano a mala pena legali per l'età da bere. La maggior parte degli indirizzi non c'erano, quando li ho cercati nella nostra directory incrociata. Quando ho mostrato le stampe al suo supervisore, mi ha guardato e ha detto "Patenti di guida, non credi?" Ho detto di averlo fatto. Disse che era per questo che aveva trovato tutti i pezzi trasparenti tagliati nella spazzatura accanto alla Xerox. Il nostro cattivo ragazzo aveva fatto delle sovrapposizioni per adeguare l'età di lui e dei suoi amici alle patenti di guida. L'abbiamo segnalato alle autorità. Era non pagato per le sue ultime due settimane.

Questi sono solo alcuni dei personaggi cattivi con cui ho dovuto lavorare ...

/ s/BezantSoft

14
BezantSoft

A parte l'ovvia mancanza di conoscenza/abilità, un programmatore è un cattivo, se il loro codice è più difficile da leggere e/o mantenere di quanto dovrebbe essere.

10
Chinmay Kanchi

Incapace di adattarsi alle prossime tecnologie

10
Gopi

Quando nessun altro può leggere il suo codice. Non importa quanto tu sia brillante; nessun programmatore è un'isola.

10
stevenvh

Per me ci sono due categorie di programmatori: solo e team.

I programmatori solisti sono cattivi

  • Coloro che hanno impiegato troppo tempo per svolgere il semplice compito.
  • Coloro che non possono cercare da soli ciò che stanno facendo.
  • Coloro che dimenticheranno ciò che è stato codificato oggi entro pochi giorni e non riescono a mantenere molto bene la propria base di codice.
  • Coloro che non riescono ad adattarsi ai requisiti cambiano.

I programmatori di squadre cattive sono quelli che rientrano nella categoria di programmatori solisti cattivi, tra cui

  • Coloro che non sono in grado di coordinarsi con altri membri del team.
  • Coloro che non accolgono favorevolmente le critiche.
  • Coloro che non sanno come essere utili agli altri e come trarre vantaggio dagli altri membri del team.
  • Coloro che non sono in grado di scrivere codice leggibile.
  • Coloro che non commentano per motivi di leggibilità per gli altri.
7
tia

Qualcuno che non presta attenzione ai dettagli ed è sempre in "funziona, quindi lo lascio da solo. Tutte quelle eccezioni nei registri non contano".

7
talonx

Un grande segnale di avvertimento nella mia esperienza è quando non commentano i loro hack ...

Sai cosa intendo: quando sei costretto a fare qualcosa di molto caotico perché semplicemente non c'è modo migliore per farlo.

I bravi programmatori odieranno doverlo fare e inserire commenti in linea dicendo quanto odiano mettere in quel tipo di hack, ma non c'è scelta. I programmatori sbagliati inseriranno l'hacking e non lo commenteranno.

4
Bobby Tables

Non disposti ad ammettere di non conoscere la risposta e/o non disposti a cercare cose.

Se non lo conosci, non mollare, scoprilo e fallo.

4

Essere ripetutamente mostrato il modo giusto di farlo, e ripetutamente semplicemente farlo nel modo più semplice.

3
DaveDev

Tranquillo ovviamente quando un programmatore scrive MOLTO codice. Funzioni molto grandi, forse copia/incolla di linee o blocchi di codice, usando molto più se necessario, ecc. Ciò potrebbe essere dovuto al fatto che il programmatore non conosce una funzione standard per fare ciò che vuole, ma per la maggior parte del tempo non lo è.

3
user2528

Sto spostando la mia risposta qui da un argomento duplicato chiuso che ha chiesto Riesci a riconoscere se sei un cattivo programmatore? L'altro argomento è stato chiuso mentre stavo componendo la mia risposta. La mia risposta affronta più direttamente la domanda in quanto è stata formulata dall'altro richiedente e leggerà meglio se lo capisci.

Sospiro! Una parte di me non ha voluto aggiungere a questo argomento già occupato, ma l'altra parte di me ha vinto! Perché ha vinto? perché mi preoccupo di aggiungere ancora più parole a questo particolare multilogo? Bene, perché, in una certa misura, potrei avere un approccio leggermente diverso rispetto ai molti commentatori precedenti.

Il binario funziona alla grande nei computer: è "1" o "0", "acceso" o "spento". Possiamo astrarre e codificare molte informazioni usando quei due famosi stati. Ma non tende a funzionare così bene per le questioni umane: "buono" o "cattivo", "sano" o "insano", "buono" o "cattivo", "intelligente" o "stupido", "grasso" o "magro", "vivo" o "morto?" Questo tipo di valutazioni polarizzate ha sempre lasciato l'essere umano premuroso parte di me terribilmente insoddisfatto. Indipendentemente dagli schemi di misurazione che scelgo di applicare, di solito scopro che le risposte a contrasti così netti in realtà si trovano da qualche parte lungo un continuum tra uno di questi poli e l'altro, non alle due estremità.

Ho combattuto con questa tendenza alla polarizzazione per un po 'di tempo, ormai, e la mia soluzione personale è che trovo molto più utile applicare tre parole a una tale valutazione: " in che misura! "

Quindi, la mia risposta alla tua domanda è di suggerirti di riformularla e di chiederti questo: "In che misura sono un cattivo programmatore?" O, ancora meglio, chiederlo nella direzione opposta: "In che misura sono un buon programmatore?" Se persegui la verità, probabilmente ti troverai da qualche parte lungo un continuum tra l'essere un programmatore "cattivo" e un "buono". Quindi, una volta che riesci a localizzare approssimativamente dove ti trovi lungo questo percorso, probabilmente puoi identificare un punto un po 'più vicino alla fine "buona", un punto in cui ti piacerebbe ritrovarti nel prossimo futuro.

Se non imposti quel punto troppo lontano, probabilmente puoi innestare la marcia posteriore e iniziare a spostarlo in quella direzione. Se riesci a ripetere più volte questo algoritmo euristico piuttosto semplice, potresti presto trovarti troppo impegnato a programmare per dover porre di nuovo questa domanda! Oh, e probabilmente farai progressi più rapidi se inizi a battere il codice su una tastiera il più rapidamente e spesso possibile; e, se fai una piccola pausa di tanto in tanto, leggi un codice di alta qualità scritto dai tuoi colleghi! In questi giorni di sviluppo dinamico Open Source, non c'è carenza di codice gratuito e squisito da cui imparare!

Quindi, ti consiglio vivamente di provare le mie tre piccole parole, "fino a che punto" e vedere fino a che punto in una buona direzione possono portarti!

3
John Tobler

Coloro che non conoscono principi come SOLID, DRY, OOP e così via. È importante avere una buona comprensione dei principi di programmazione e delle basi piuttosto che conoscere specifiche tecnologie. Quelli con solide basi saranno in grado di apprendere facilmente nuovi argomenti e produrrà un codice migliore.

2
Giorgi

Una cosa che distingue un programmatore cattivo da un programmatore principiante è l'insistenza ostinata sull'implementazione del proprio sistema preferito in qualsiasi lingua e API in cui stanno lavorando.

Una volta ho ereditato un sistema in cui lo sviluppatore precedente ha reimplementato (in Java) un ampio set di Ashton Tate DBase III + api sovrapposto alla libreria di accesso dbf personalizzata. Nessuno dei Java.

Questo è stato così che poteva scrivere un'app Java/swing che sembrava e si comportava come un'app DBase III + (o forse clipper).

Le App che ha scritto in questo sistema avevano menu a barra lite e apriva una finestra intera con una fila di pulsanti in basso quando si spostava la barra lite all'opzione. Era come una piccola macchina del tempo negli anni '80.

L'uomo era chiaramente un abile sviluppatore. Sapeva abbastanza che era in grado di scrivere da solo l'intero sistema nel periodo di tempo di quel progetto. È stato anche in grado di riutilizzarlo su alcuni altri sistemi interni.

Ma era un programmatore terribile in quanto il suo codice utilizzava in modo improprio le funzionalità dei sistemi su cui lavorava. Era più disposto a trascorrere 3 mesi in una libreria personalizzata di dubbia utilità piuttosto che imparare Java/Swing/SQL.

2
sal

Qualcuno che dice "Non si può fare".

A mio avviso, si tratta di risolvere i problemi, lo strumento dovrebbe essere molto meno pertinente rispetto al lavoro svolto. Se devo risolverlo usando il linguaggio MS-Access o Assembly, è una questione di tempo e denaro, non di "Non si può fare"

Un segnale di avvertimento è troppo focalizzato sul modo accademico e "corretto" di fare le cose, e non abbastanza su come svolgere il lavoro.

2
Dan Williams

Se conosce solo la sintassi di una lingua ma non conosce i concetti di base degli algoritmi.

2
Chankey Pathak

Quando fanno molto pontificando ma producono molto poco.

2
Gratzy

Un programmatore incorporato che non capisce molto bene gli interrupt o il multitasking. Anche i programmatori che hanno bisogno di lavorare con i campi di bit ma non comprendono operazioni logiche su di essi e lo spostamento.

2
tcrosley

Un segnale di riconoscimento immediato è qualcuno che dice: "Non capisco perché non funziona. Ho fatto tutto bene".

2
Robert Rossney

! (intelligente e fa le cose)

2
Nick Pierpoint

Oggi, molti programmatori ritengono che questa complessità sia gestita al meglio utilizzando solo una piccola serie di tecniche ben comprese nei loro programmi. Hanno composto regole rigide sui moduli che i programmi dovrebbero avere, e più zelanti tra loro denunceranno coloro che infrangono queste regole come cattivi programmatori

1
Pir Abdul

Un programmatore che semplicemente copia e incolla il codice da altri luoghi e non capisce come funziona effettivamente il codice, è conosciuto come un programmatore cattivo! In genere lo vedo con JavaScript.

1
Pir Abdul

Penso che l'unico modo in cui un programmatore può essere cattivo nella programmazione è se smette di ascoltare ciò che gli altri hanno da dire.

La programmazione riguarda le informazioni. Bisogna tenere le orecchie e gli occhi ben aperti.

Un programmatore può migliorare solo colpendo i libri e lavorando sodo. Tuttavia, dovresti anche concentrarti sull'apprendimento di cose nuove, non sull'apprendimento continuo (cerca nuove esperienze all'interno del tuo specifico settore/settore).

In bocca al lupo.

0
Pablo