Come fai a dire a qualcuno che stanno scrivendo un codice errato? [chiuso]

Ho lavorato con un piccolo gruppo di persone su un progetto di programmazione per divertimento. È un gruppo organizzato e abbastanza coeso. Le persone con cui lavoro hanno vari set di abilità legate alla programmazione, ma alcuni di loro usano metodi sbagliati o completamente vecchi, come variabili globali eccessive, convenzioni di denominazione scadenti e altre cose. Mentre le cose funzionano, l'implementazione è scarsa. Qual è un buon modo per chiedere educatamente o introdurre loro di usare una metodologia migliore, senza che si verifichino domande o insulti sulla loro esperienza e / o istruzione?

Presentare domande per far loro capire che quello che stanno facendo è sbagliato. Ad esempio, fai questo tipo di domande:

Perché hai deciso di renderla una variabile globale?

Perché gli hai dato quel nome?

Interessante. Di solito faccio il mio in questo modo perché [Inserisci il motivo per cui stai meglio]

Funziona così? Di solito [inserisci come li faresti sembrare sciocchi]

Penso che il modo ideale per farlo sia sottilmente chiedere loro perché codificano in un certo modo. Potresti scoprire che credono che ci siano benefici ad altri metodi. A meno che non sapessi che il motivo del loro stile di programmazione era dovuto alla disinformazione, non avrei mai giudicato la mia strada migliore senza una buona ragione. Il modo migliore per farlo è semplicemente chiedere loro perché hanno scelto quella strada; assicurati di sembrare interessato al loro ragionamento, perché è quello che devi attaccare, non la loro abilità.

Uno standard di codifica sarà sicuramente d'aiuto, ma se fosse la risposta ad ogni progetto software, sorseggeremmo tutti cocktail sulle nostre isole private in paradiso. In realtà, siamo tutti inclini a problemi e i progetti software hanno ancora un basso tasso di successo. Penso che il problema deriverebbe principalmente dall'abilità individuale piuttosto che da un problema con le convenzioni, motivo per cui suggerirei di risolvere i problemi come gruppo quando un problema gli si strappa la testa.

Ancora più importante, NON assumere immediatamente che la tua strada sia migliore . In realtà, probabilmente lo è, ma abbiamo a che fare con l'opinione di un'altra persona e per loro c'è solo una soluzione. Non dire mai che la tua strada è il modo migliore di farlo se non vuoi che ti vedano come un perdente compiaciuto.

Inizia a fare revisioni del codice o accoppia la programmazione.

Se il team non lo farà, prova le revisioni settimanali del design. Ogni settimana, incontrati per un'ora e parla di un pezzetto di codice. Se la gente sembra difensiva, scegli il vecchio codice a cui nessuno è più legato emotivamente, almeno all'inizio.

Come @JesperE: detto, concentrati sul codice, non sul programmatore.

Quando vedi qualcosa che ritieni debba essere diverso, ma altri non la vedono allo stesso modo, allora inizia ponendo domande che portano alle carenze, invece di segnalarle. Per esempio:

Globali : pensi che vorremmo mai avere più di uno di questi? Pensi che vorremmo controllare l'accesso a questo?

Stato mutevole : pensi che vorremmo manipolarlo da un altro thread?

Trovo anche utile concentrarmi sui miei limiti, che possono aiutare le persone a rilassarsi. Per esempio:

funzioni lunghe : il mio cervello non è abbastanza grande da contenere tutto questo in una volta. Come possiamo realizzare pezzi più piccoli che posso gestire?

nomi cattivi : mi confondo abbastanza facilmente quando leggo il codice chiaro; quando i nomi sono fuorvianti, non c'è speranza per me.

In definitiva, l'obiettivo non è insegnare alla tua squadra come programmare meglio. È stabilire una cultura dell'apprendimento nella tua squadra. Dove ogni persona cerca aiuto negli altri per diventare un programmatore migliore.

Introdurre l'idea di uno standard di codice. La cosa più importante di uno standard di codice è che propone l'idea di coerenza nella base di codice ( idealmente , tutto il codice dovrebbe apparire come se fosse stato scritto da una persona in una seduta) che porterà a un codice più comprensibile e gestibile.

Devi spiegare perché la tua strada è migliore .

Spiega perché una funzione è migliore del tagliare e incollare.

Spiega perché un array è migliore di $ foo1, $ foo2, $ foo3.

Spiega perché le variabili globali sono pericolose e che le variabili locali renderanno la vita più semplice.

Semplicemente elaborare uno standard di codifica e dire "fare questo" non ha valore perché non spiega al programmatore perché è una buona cosa.

Innanzitutto, starei attento a non giudicare troppo in fretta. È facile liquidare un po 'di codice come male, quando potrebbero esserci buoni motivi per cui è così (es: lavorare con codice legacy con strane convenzioni). Ma supponiamo per il momento che siano davvero cattivi.

Potresti suggerire di stabilire uno standard di codifica, basato sull'input del team. Ma allora devi davvero tener conto delle loro opinioni, non solo imporre la tua visione di quale buon codice dovrebbe essere.

Un'altra opzione è quella di portare libri tecnici in ufficio (codice completo, C ++ efficace, programmatore pragmatico ...) e offrire di prestarlo ad altri ("Ehi, ho finito con questo, qualcuno vorrebbe prenderlo in prestito?" )

Se possibile, assicurati che capiscano che stai criticando il loro codice , non personalmente.

Suggerisci un'alternativa migliore in modo non conflittuale.

"Ehi, penso che funzionerà anche in questo modo. Cosa ne pensate ragazzi?" [Gesto per ovviamente migliorare il codice sullo schermo]

Avere revisioni del codice e iniziare rivedendo il TUO codice.

Metterà le persone a proprio agio con l'intero processo di revisione del codice perché stai iniziando il processo rivedendo il tuo codice anziché il loro. Iniziare con il codice fornirà anche buoni esempi di come fare le cose.

Potrebbero pensare che anche il tuo stile puzzi. Riunisci il team per discutere un insieme coerente di linee guida sullo stile di codifica. Accetta qualcosa. Che si adatti al tuo stile non è un problema, accontentarsi di qualsiasi stile purché sia ​​coerente è ciò che conta.

Per esempio. Mostra loro nel modo giusto.

Prendila con calma. Non schiacciarli per ogni piccolo errore fin dall'inizio, basta iniziare con le cose che contano davvero.

L'idea standard del codice è buona.

Ma considera di non dire nulla, soprattutto perché è per divertimento, con, presumibilmente, persone con cui sei amico. È solo un codice ...

Nel libro di Gerry Weinberg "The Psychology of Computer Programming" ci sono davvero dei buoni consigli - tutta la sua nozione di "programmazione senza ego" è tutta su come aiutare le persone ad accettare le critiche al loro codice come distinte dalle critiche di se stessi.

Cattive pratiche di denominazione: sempre ingiustificabili.

E sì, non dare sempre per scontato che la tua strada sia migliore ... Può essere difficile, ma l'oggettività deve essere mantenuta.

Ho avuto un'esperienza con un programmatore che aveva un nome così orribile di funzioni, il codice era peggio che illeggibile. Le funzioni mentivano su ciò che facevano, il codice era privo di senso. Ed erano protettivi / resistenti al fatto che qualcun altro modificasse il proprio codice. se confrontati in modo molto educato, hanno ammesso che aveva un nome mediocre, ma volevano mantenere la proprietà del codice e sarebbero tornati a sistemarlo "in un secondo momento". Questo è passato, ma come si fa a gestire una situazione in cui il loro errore è RICONOSCIUTO, ma poi protetto? Questo è andato avanti per molto tempo e non avevo idea di come superare quella barriera.

Variabili globali: io stesso non sono così affezionato alle variabili globali, ma conosco alcuni programmatori altrimenti eccellenti a cui piacciono MOLTO. Tanto che sono arrivato a credere che non siano poi così male in molte situazioni, poiché consentono chiarezza e facilità di debug. (per favore non darmi fuoco / voto negativo :)) Si tratta di, ho visto un sacco di codice molto buono, efficace, privo di bug che utilizzava variabili globali (non inserite da me!) e un sacco di bug, impossibile leggere / mantenere / correggere il codice che utilizzava meticolosamente schemi corretti. Forse c'è È un posto (anche se forse restringimento) per le variabili globali? Sto pensando di ripensare la mia posizione sulla base di prove.

Avvia un wiki sulla tua rete usando alcuni software wiki.

Inizia una categoria sul tuo sito chiamata "best practice" o "standard di codifica" o qualcosa del genere.

Indica tutti ad esso. Consenti feedback.

Quando esegui rilasci del software, chiedi a chi ha il compito di inserire il codice nella build e di rimandare gli sviluppatori, indicandoli alle pagine Wiki su di esso.

L'ho fatto nella mia organizzazione e ci sono voluti diversi mesi perché le persone prendessero davvero il controllo dell'utilizzo del Wiki, ma ora è questa risorsa indispensabile.

Se hai anche uno standard di codifica sciolto, essere in grado di indicarlo o indicare che non puoi seguire il codice perché non è il formato corretto potrebbe essere utile.

Se non hai un formato di codifica, ora sarebbe un buon momento per crearne uno. Qualcosa come le risposte a questa domanda può essere utile: /programming/4121/team-coding-styles

Vado sempre con la frase "Questo è quello che vorrei fare". Non provo a insegnare loro e dire loro che il loro codice è spazzatura, ma solo dare un punto di vista alternativo che si spera possa mostrare loro qualcosa che è ovviamente un po 'più ordinato.

Chiedi alle persone in questione di preparare una presentazione al resto del gruppo sul codice per un modulo rappresentativo che hanno scritto e lascia che le domande e risposte se ne occupino (fidati di me, lo farà, e se è un buon gruppo, non dovrebbe nemmeno diventare brutto).

Adoro il codice e non ho mai avuto alcun corso nella mia vita su qualcosa di legato all'informatica Ho iniziato molto male e ho iniziato a imparare dagli esempi, ma quello che ricordo e ho sempre tenuto presente nella mia mente da quando ho letto il libro "Gang Of Four" è stato :

"Tutti possono scrivere codice compreso da una macchina, ma non tutti possono scrivere codice compreso da un essere umano"

con questo in mente, c'è molto da fare nel codice;)

Non posso sottolineare abbastanza la pazienza. Ho visto questo esatto genere di cose completamente controproducente soprattutto perché qualcuno voleva che le modifiche avvenissero ADESSO. Molti ambienti richiedono i vantaggi dell'evoluzione, non della rivoluzione. E forzando il cambiamento oggi, può creare un ambiente molto infelice per tutti.

Il buy-in è la chiave. E il tuo approccio deve tenere conto dell'ambiente in cui ti trovi.

Sembra che tu sia in un ambiente che ha molta "individualità". Quindi ... non suggerirei un insieme di standard di codifica. Ti verrà in mente che vuoi prendere questo progetto "divertente" e trasformarlo in un progetto di lavoro altamente strutturato (oh fantastico, quali sono i prossimi ... documenti funzionali?). Invece, come ha detto qualcun altro, dovrai affrontarlo in una certa misura.

Resta paziente e lavora per educare gli altri nella tua direzione. Inizia con i bordi (punti in cui il tuo codice interagisce con gli altri) e quando interagisci con il loro codice prova a prenderlo come un'opportunità per discutere l'interfaccia che hanno creato e chiedere loro se andrebbe bene con loro se fosse cambiato (da tu o loro). Spiega completamente perché desideri il cambiamento ("aiuterà a gestire meglio il cambiamento degli attributi del sottosistema" o qualsiasi altra cosa). Non scegliere e prova a cambiare tutto ciò che vedi come sbagliato. Una volta che interagisci con gli altri al limite, dovrebbero iniziare a vedere come ne trarrebbero beneficio alla base del loro codice (e se ottieni abbastanza slancio, vai più in profondità e inizia davvero a discutere delle tecniche moderne e dei vantaggi degli standard di codifica). Se ancora non lo vedono ... forse tu '

Pazienza. Evoluzione, non rivoluzione.

In bocca al lupo.

Indosso una toga e apro una lattina di metodo socratico.

Il metodo socratico che prende il nome dal filosofo greco classico Socrate, è una forma di indagine filosofica in cui l'interrogante esplora le implicazioni delle posizioni altrui, per stimolare il pensiero razionale e illuminare le idee. Questo metodo dialettico comporta spesso una discussione di opposizione in cui la difesa di un punto di vista è contrapposta a un altro; un partecipante può indurre un altro a contraddirsi in qualche modo, rafforzando il punto stesso dell'investigatore.

Molte delle risposte qui si riferiscono alla formattazione del codice che in questi giorni non è particolarmente rilevante, poiché la maggior parte degli IDE riformatterà il codice nello stile scelto. Ciò che conta davvero è come funziona il codice e il poster ha ragione a guardare le variabili globali, il codice copia e incolla e il mio peeve pet, convenzioni di denominazione. Esiste un codice errato e ha poco a che fare con il formato.

La parte buona è che la maggior parte è cattiva per un'ottima ragione, e queste ragioni sono generalmente quantificabili e spiegabili. Quindi, in modo non conflittuale, spiega le ragioni. In molti casi, puoi anche fornire agli sceneggiatori scenari in cui i problemi diventano evidenti.

Non sono lo sviluppatore principale del mio progetto e quindi non posso imporre standard di codifica, ma ho scoperto che il cattivo codice di solito causa un problema prima piuttosto che dopo, e quando lo fa sono lì con un'idea o una soluzione più pulita.

Non intervenendo in quel momento e adottando un approccio più naturale ho acquisito maggiore fiducia nei confronti del lead e spesso si rivolge a me per idee e mi include sulla progettazione architettonica e sulla strategia di implementazione utilizzate per il progetto.

Le persone che scrivono cattivi codici sono solo un sintomo dell'ignoranza (che è diverso dall'essere stupido). Ecco alcuni suggerimenti per trattare con quelle persone.

• L'esperienza della gente lascia un'impressione più forte di qualcosa che dirai.
• Alcune persone non sono appassionate del codice che producono e non ascolteranno nulla di ciò che dici
• La programmazione accoppiata può aiutare a condividere idee ma a cambiare chi guida o controlleranno semplicemente la posta elettronica sul proprio telefono
• Non affogarli troppo, ho scoperto che anche l'integrazione continua doveva essere spiegata alcune volte ad alcuni sviluppatori più anziani
• Falli eccitare di nuovo e vorranno imparare. Potrebbe essere qualcosa di semplice come i robot di programmazione per un giorno
• FIDATI DEL TUO TEAM, gli standard di codifica e gli strumenti che li controllano in fase di costruzione spesso non sono mai leggibili o fastidiosi.
• Rimuovi proprietà del codice, su alcuni progetti vedrai silos di codici o formiche dove la gente dice che è il mio codice e non puoi cambiarlo, questo è molto male e puoi usare la programmazione accoppiata per rimuoverlo.

Invece di farli scrivere codice, chiedi loro di mantenere il loro codice.

Fino a quando non dovranno mantenere la loro pila fumante di spaghetti, non capiranno mai quanto siano cattivi nella programmazione.

A nessuno piace ascoltare qualcuno che dice che il loro lavoro fa schifo, ma qualsiasi persona sana di mente accetterebbe il tutoraggio e i modi per evitare il lavoro inutile.

Una scuola di insegnamento dice anche che non dovresti segnalare errori, ma focalizzare ciò che è fatto bene. Ad esempio, invece di indicare il codice incomprensibile come male, dovresti sottolineare dove il loro codice è particolarmente facile da leggere. Nel primo caso stai preparando gli altri a pensare e ad agire come programmatori schifosi. Nel secondo caso stai preparando a pensare come un professionista qualificato.

Ho un senario simile con i ragazzi con cui lavoro .. Non hanno l'esposizione alla codifica tanto quanto me, ma sono ancora utili per la codifica.

Piuttosto che lasciarmi fare ciò che vogliono e tornare indietro e modificare il tutto. Di solito li faccio semplicemente sedere e faccio vedere loro due modi di fare le cose. La loro strada e la mia strada, da questo discutiamo i pro e i contro di ogni metodo e quindi giungiamo a una migliore comprensione e una migliore conclusione su come dovremmo andare sulla programmazione.

Ecco la parte davvero sorprendente. A volte verranno fuori domande a cui anche io non ho risposte, e dopo la ricerca otteniamo tutti un migliore concetto di metodologia e struttura.

1. Discutere.
2. Mostra loro perché
3. Non pensare nemmeno di avere sempre ragione. A volte anche loro ti insegneranno qualcosa di nuovo.

Ecco cosa farei se fossi in te: D

Probabilmente un po 'in ritardo dopo l'effetto, ma è qui che uno standard di codifica concordato è una buona cosa.

Francamente credo che il codice di qualcuno sia migliore quando è più facile cambiare, eseguire il debug, navigare, comprendere, configurare, testare e pubblicare (wow).

Detto questo, penso che sia impossibile dire a qualcuno che il suo codice è cattivo senza prima provare a fargli spiegare cosa fa o come qualcuno dovrebbe migliorarlo in seguito (come, creare una nuova funzionalità o eseguirne il debug).

Solo allora la loro mente si spezza e chiunque sarà in grado di vedere che:

• Le variazioni di valore delle variabili globali sono quasi sempre non tracciabili
• Enormi funzioni sono difficili da leggere e comprendere
• I pattern rendono il tuo codice più semplice da migliorare (purché tu rispetti le loro regole)
• ( eccetera...)

Forse una sessione di programmazione in coppia dovrebbe fare il trucco. Per quanto riguarda l'applicazione degli standard di codifica, aiuta ma sono troppo lontani dalla definizione reale di cosa sia un buon codice.

Probabilmente vuoi concentrarti sull'impatto del codice errato, piuttosto che su ciò che potrebbe essere respinto come solo la tua opinione soggettiva sul fatto che sia uno stile buono o cattivo.

Informati privatamente su alcuni dei segmenti di codice "cattivi" con un occhio alla possibilità che sia effettivamente un codice ragionevole , (non importa quanto tu sia predisposto), o che ci siano forse circostanze attenuanti. Se sei ancora convinto che il codice sia semplicemente negativo - e che la fonte sia effettivamente questa persona - vai via. Può succedere una di queste cose: 1) la persona nota e intraprende alcune azioni correttive, 2) la persona non fa nulla (è ignara o non si preoccupa tanto quanto te).

Se succede il n. 2 o il n. 1 non comporta un miglioramento sufficiente dal tuo punto di vista, E sta danneggiando il progetto e / o ti sta influenzando abbastanza, allora potrebbe essere il momento di iniziare una campagna per stabilire / applicare gli standard entro Il gruppo. Ciò richiede un buy-in da parte della direzione, ma è più efficace se istigato dalle origini.

Buona fortuna. Sento il tuo dolore, fratello.