Quando qualcuno sarebbe considerato un cattivo programmatore? [chiuso]

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

Se possibile ... Come dovrebbe migliorare?

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.

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

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

Dall'articolo:

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

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.

Quando impiegano molto tempo per risolvere il problema FizzBuzz.

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

Addendum: (aggiungendo ciò 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 ...

Quando un membro del team è lo sviluppatore produttore negativo .

|# 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

Quando producono cose che fanno parte del Daily WTF su base regolare.

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

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ò ridursi con l'esperienza ... direi tra alcune settimane fino a un anno circa.

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

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 burocrazia e una pila di documentazione.) O di non rinnovare il contratto alla fine 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 addestrabile 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 svolto l'addestramento / 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 del giorno " e vede ogni nuovo quadro, linguaggio, metodologia o qualunque cosa sia nuova e accattivante come il
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 ^a. Sandbagger
   Questo "programmatore" usa l'offuscamento e la cattiva direzione per aumentare la ^a. LOC: righe di codice che vengono pagate. Ho visto codice in questa situazione che era pagina dopo pagina, schermata dopo schermata di 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: quelli che pensano di essere indispensabili lo sono di solito. (Qualcuno ha la fonte di questo aforisma?)}
7. The Pasta Chef
   Questo "programmatore" è specializzato nel codice spaghetti, speziato con identificatori che sono troppo difficili da seguire senza un IDE implementato sintatticamente. ad es. IndexI1O0, Index1I0O, ecc.
8. Stagista estivo - Sottotipo specifico 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 un piacere per gli occhi, ma l'applicazione lo eraincompleto. 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 trovare qualche logica aggiuntiva, anche se incompleto.
   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 emette 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à.non pagato per le sue ultime due settimane.

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

/ s / BezantSoft

Incapace di adattarsi alle prossime tecnologie

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.

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

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

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.

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

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

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.

Silenzioso 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 la maggior parte delle volte non lo è.

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

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 veniva chiuso mentre componevo 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 voleva 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 questo 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 martellare 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!

Qualcuno che dice "Non si può fare".

A mio avviso, si tratta di risolvere i problemi, lo strumento dovrebbe essere molto meno pertinente rispetto a svolgere effettivamente il lavoro. Se devo risolverlo usando MS-Access o il linguaggio 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.

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

Quando fanno molto pontificando ma producono molto poco.

! (intelligente e fa le cose)

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

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

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

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 api Ashton Tate DBase III + api sovrapposto alla libreria di accesso dbf personalizzata. Nessuno del framework delle raccolte Java è stato utilizzato.

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 della barra lite e aprivano una finestra intera con una fila di pulsanti in basso quando si spostava la barra lite sull'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 spendere 3 mesi in una libreria personalizzata di dubbia utilità rispetto all'apprendimento di Java / Swing / SQL.