Come reagiresti se qualcuno ti dicesse che il tuo codice è un casino?

86

Sono un buon programmatore, o almeno così pensavo. Mi piace sempre programmare. E voglio imparare molte cose sulla programmazione per farmi diventare un programmatore migliore. Ho studiato programmazione per 1 anno e ora lavoro come programmatore per quasi 2 anni. Quindi in breve, ho quasi 3 anni di esperienza di programmazione.

Il nostro team è composto da 5 programmatori e 4 di noi sono nuovi, 1 ha più di 3 anni di esperienza. Lavoriamo per un programma da quasi un anno e nessuno ha mai rivisto il mio codice e mi è stata data una pagina con cui lavorare. Non abbiamo mai avuto una revisione del codice e siamo tutti nuovi quindi non sappiamo come sia un codice pulito. Penso che i programmatori imparino da soli?

Abbiamo distribuito il nostro programma al programma senza test approfonditi. Ora è stretto e abbiamo bisogno di un'approvazione e di una revisione del codice prima di apportare modifiche al codice. Per la prima volta, qualcuno rivede il mio codice e dice che è un casino.

Mi sento così triste e ferito. Amo davvero programmare e far loro dire qualcosa del genere mi fa davvero male. Voglio davvero migliorare me stesso. Ma sembra che non sia un programmatore geniale come nei film. Puoi darmi consigli su come essere migliore? Hai mai provato qualcosa che critica il tuo codice e ti senti davvero ferito? Cosa fai in quegli eventi.

teamwork code-reviews maintenance

— principiante
fonte

51

"Ma sembra che non sia un programmatore geniale come nei film" . Il tuo errore è credere a ciò che vedi nei film su sviluppatori di software, hacker e praticamente tutto ciò che ha a che fare con la tecnologia del mondo reale.

— Stephen C,

160

Congratulazioni! Ad oggi, sei ufficialmente un vero programmatore! Sapere che sei terribile è una delle pietre miliari sempre importanti in questa professione. Non riesco a minimizzare questo: a ogni singolo programmatore professionista è stato detto che qualcosa che hanno scritto è stato terribile in un punto o nell'altro, e che tipo di punture quando sei nuovo, ma è vero e lo sentirai molte altre volte nel corso della tua carriera! Buck up, sei appena entrato nella professione. I bravi programmatori prendono quei jab e imparano a non fare gli stessi errori (invece ne commettono sempre ogni volta!)

— Jimmy Hoffa,

15

@newbie quando sei nuovo e hai costruito un po 'di ego e non hai rovinato abbastanza per rendermi conto che sei cattivo, sono cattivo, siamo tutti cattivi in questo perché è davvero difficile. Se ti rimane dell'ego, dopo che avrai commesso altri errori andrà avanti. Seriamente, alza la mano se sei un ingegnere professionista e hai accidentalmente spazzato via un database prima di alzare la mano

— Jimmy Hoffa,

14

Deluso? Perché diavolo saresti deluso? Il mio ex CTO mi ha chiamato in un articolo che ha scritto (non mi ha dato un nome specifico, ma tutti nel nostro team sapevano di chi stesse parlando), e la prima possibilità che ho avuto ho citato l'articolo in una delle mie risposte qui . Inoltre, sono lo sviluppatore malvagio descritto in questa domanda . Ho incoraggiato l'OP a pubblicare la domanda e ho persino risposto;)

— yannis

19

Ricorda gente, solo perché qualcuno ha detto che il codice era cattivo non lo rende vero. Dopo aver sentito "il tuo codice è un disastro" l'OP merita "ed ecco perché". Quindi, può iniziare l' analisi .

— Tony Ennis,

175

La verità è che probabilmente tra 2 anni quando vedrai il tuo codice attuale sarai d'accordo che era un casino. L'apprendimento della programmazione è un processo senza fine e ci sarà sempre qualcuno più bravo di te.

Quindi se una persona che ha detto che il tuo codice è un disastro non è solo cattiva e non è un altro caso di malattia "lo farei meglio" comune tra i programmatori, dovresti chiedergli che cosa non va esattamente nel tuo codice e come puoi migliorala.

— onlineapplab.com
fonte

27

Hai ragione! Rido del mio codice 2 anni fa. Quindi immagino che riderò anche del mio codice tra due anni. Mi sono solo emozionato. Ad ogni modo, proverò a diventare migliore.

— novizio

5

@newbie: Ecco qua. Questo è quello che devi davvero sapere. Il mio motto è stato "Non sono mai stato bravo come lo sarò tra due anni", da oltre dieci anni. E non ho ancora sbagliato. Non l'ho imparato molto più nella mia carriera di quanto tu abbia fatto. Il tuo collega ti ha fatto un grande favore.

— pdr

27

Penso che sei mesi dovrebbero essere un sacco di tempo per odiare il tuo codice. Sono preoccupato che un giorno potrei trovare il codice che ho scritto sei mesi prima e non trovare qualcosa che odio al riguardo. Sarebbe un segno che non sono cresciuto come programmatore.

— zzzzBov

37

2 anni! Posso ridere nel pomeriggio al codice che ho scritto la mattina.

— dan_waterworth

9

Direi anche che le revisioni del codice sono processi incredibilmente utili. Come afferma questa risposta, se sei un buon programmatore, col tempo anche tu penserai che questo sia un codice terribile - è naturale. Direi anche che il tuo revisore del codice non si sta avvicinando correttamente al processo di revisione. Dovrebbe essere un processo di critica costruttiva in cui viene trasferita la conoscenza, non un processo penale negativo in cui il programmatore in fase di revisione viene ritenuto insignificante. Questo nega molto del bene che può venire da una recensione.

— Mattygabe,

68

Non essere orgoglioso di quanto bene codice. Sii orgoglioso di quanto bene impari. Quindi apprendere che il tuo codice ha bisogno di miglioramenti ti offre l'opportunità di dimostrare quanto sei bravo nell'apprendimento, invece di imbatterti in una critica di quanto sei cattivo programmatore.

Leggi http://www.perlmonks.org/?node_id=270083 se non hai idea di cosa sto parlando.

— btilly
fonte

bell'articolo. :) quindi ho solo a che fare con il mio ego.

— novizio

2

@newbie Exactly. Quando ricevi critiche al tuo codice, può sconvolgerti solo se il tuo ego è legato alla qualità di quel codice. Divorzi il tuo ego dal codice e il problema scompare.

— btilly

5

Sono d'accordo di essere orgoglioso di quanto tu impari, ma dovresti anche essere orgoglioso di come scrivi. Se non sei orgoglioso di come codifichi, non sarai guidato a migliorare.

— Bryan Oakley,

1

E dovresti anche stare attento a essere orgoglioso dell'apprendimento in quanto ciò può portare agli stessi problemi se in realtà non sei così bravo nell'apprendimento.

— Nico Burns,

Pensavo che l'orgoglio fosse uno dei 7 peccati capitali? Che succede con tutti a consigliarlo in questi giorni? Che ne dici di sentirti contento di aver fatto un buon lavoro.

40

Dopo oltre 20 anni so che parte del mio codice è ancora un casino. Ciò che si riduce a prendere una decisione tra la scrittura del miglior codice possibile e la scrittura di ciò che è necessario per ottenere il lavoro svolto. Svolgere il lavoro entro un lasso di tempo concordato supera ogni giorno la ricerca incessante della perfezione tecnica.

Il trucco è imparare ad accettarlo. Impara ad accettare che potresti fare di meglio. Impara a convivere con i difetti. Impara ad accettare che non lo renderai perfetto questa volta, e probabilmente anche la prossima volta, e che è una scelta deliberata perché l'alternativa non sta offrendo. E questo è peggio.

Dichiarazione di non responsabilità: nulla di tutto ciò deve essere letto come "il codice errato è OK".

— Maximus Minimus
fonte

2

Sforzarsi di "ottenere il lavoro svolto" è mirare al mediocre. Hai ragione, funziona e può essere efficace: basta guardare i prodotti cinesi. Ma cercare di rendere grandi le cose è ciò che rende 20 anni di programmazione degno di essere amici. Guardando indietro di 20 anni, cosa rivela: portare a termine il lavoro o farlo con orgoglio?

— Kingdango,

9

Si tratta sempre di "portare a termine il lavoro" a meno che tu non stia scrivendo una sorta di strano progetto artistico basato su codice. Scrivere "buon codice" vs. "codice mediocre" è un compromesso tra il completamento dell'attività immediata e la rendere il codice più gestibile per portare a termine il lavoro in futuro. Ignorare questo porta al perfezionismo, che porta a non fare nulla. Il codice mediocre scritto rapidamente è meglio del buon codice scritto lentamente per uno script unico.

— Gort il robot il

8

Come i debiti monetari, anche il debito tecnico aumenta e apprende come gestire il debito tecnico è una delle abilità primarie di un programmatore nel mondo reale. Chiunque abbia abbastanza tempo per fare un lavoro perfetto ogni volta è incredibilmente bravo, seriamente mal lavorato o illudendosi.

— Mark Booth,

1

Trovare il giusto equilibrio può essere difficile, soprattutto perché gli effetti di andare avanti con un design mediocre sono spesso molto più visibili di quelli di passare troppo tempo a perfezionare un design quando uno mediocre si sarebbe dimostrato perfettamente adeguato per tutta la sua vita utile.

— supercat

1

Questo mi rattrista davvero perché "portare a termine il lavoro" e "la perfezione tecnica" non devono necessariamente essere i mondi a parte che descrivi. Personalmente, non provo molta soddisfazione per un mio codice che è stato rilasciato che è completamente bizzarro ed è in quel modo a causa di vincoli di tempo e, come dici tu, di "portare a termine il lavoro" .

— crmpicco,

39

Il codice di tutti è un casino e non ci sono buoni programmatori.

Ci sono:

programmatori che spediscono velocemente,
programmatori che inviano sempre codice semanticamente corretto,
programmatori che escono sempre con la soluzione ottimale e l'algoritmo più veloce,
programmatori il cui codice è facile da vedere.

Quasi mai finiscono per essere la stessa persona.

E ci sono programmatori butthurt che devono crescere e:

chiedi cosa c'è che non va,
non prendere alcun commento personalmente, come misura del loro valore come essere umano;
rendersi conto che ci sono linee guida per la sintassi nei team, che devono essere seguite e sono arbitrarie, quindi non sono pensate per essere discusse fino alla nausea , poiché non esiste una soluzione ottimale né una parola finale;
migliorare nel commentare il loro codice;
migliorare nel commentare il loro codice; (sic)
trovare soluzioni di debug più facili, meno intelligenti, per compiti semplici, banali;
prendere una classe in SQL
(manderei metà della popolazione di questo mondo a prendere una classe in SQL, solo per essere al sicuro)

Non è arte, è un mestiere.
Diamo per scontato che tu sia intelligente: stai programmando computer, dannazione.
Ancora AMD64e x86non sono costretti dal potere della tua prosa. Mantieni le cose semplici.

— ZJR
fonte

3

Letteralmente a crepapelle. così buono. roflcopters

— kingdango,

1

AMD64 e x86 non sono costretti dal potere della tua prosa. - assolutamente fantastico.

— Sam Brinck,

+1 per prendere una lezione in SQL

— HLGEM

28

Bene, una persona che dice che il tuo codice è un casino non è costruttiva, anche se ha ragione. Ti hanno dato ragioni per cui è un casino? Ad esempio, i metodi sono troppo lunghi, le responsabilità mescolate insieme, troppe ramificazioni, ecc. Onestamente, qualsiasi codice che ho scritto un anno fa direi che è una schifezza completa perché da allora ho imparato molto. Quindi non sentirti male. Sarei più preoccupato se ti piace ancora leggere il codice che hai scritto tanto tempo fa.

Quanto più pulito è il tuo codice, tanto meno tempo dedichi a combattere il codice per risolvere un determinato problema. Un anno è un ottimo punto per essere perché puoi sentire il dolore di qualsiasi decisione di progettazione che hai preso prima nel progetto.

Nel mio progetto attuale, abbiamo eseguito il refactoring più volte man mano che ci sentivamo più a nostro agio con il nostro stack tecnologico. Questo dovrebbe essere incoraggiato e dovresti prendere nota delle attività che richiedono più tempo di quanto dovrebbero a causa dell'attuale base di codice.

Hai esaminato alcune delle parti più vecchie del codice che hai scritto? Probabilmente puoi vedere cose che vorresti fare diversamente ora o refactoring.

Anche quando si menziona la mancanza di test, questo è sempre qualcosa da guardare. Nel nostro progetto non abbiamo avuto test automatizzati e di conseguenza un sacco di codice altamente accoppiato. Anche se non scrivi regolarmente unità / integrazione / qualunque test, farlo per un po 'ti farà prendere l'abitudine di rendere il tuo codice più modulare (e, di conseguenza, meno un casino).

— Kryptic
fonte

26

Mi sento così triste e ferito. Amo davvero programmare e far loro dire qualcosa del genere mi fa davvero male. Voglio davvero migliorare me stesso.

È buono. È molto meglio che avere una reazione come "il mio recensore non ha idea di cosa stia parlando", "il mio recensore è troppo esigente" o semplicemente "il mio revisore non mi piace" e ignorarli. Questo atteggiamento è una buona cosa.

Ma sembra che non sia un programmatore geniale come nei film.

Non sono sicuro del tipo di film che guardi, ma il 90% dei programmatori nei film è così falso che ho lacrime entro la fine della sequenza.

Puoi darmi consigli su come essere migliore?

Leggi ed esercitati. Scopri libri come Code Complete o The Pragmatic Programmer . Cerca su Amazon libri simili.

Hai mai provato qualcosa che critica il tuo codice e ti senti davvero ferito? Cosa fai in quegli eventi ...

Perché ti senti ferito? Mi sento deluso di me stesso per essere stato un tale idiota in primo luogo. Uso questa motivazione per ripulire il mio codice e assicurarmi di non ripetere più lo stesso errore . L'ultima cosa che voglio fare non impara da esso. Sei stato messo giù una volta, non lasciare che accada di nuovo per lo stesso motivo.

Nessun programmatore è nato perfetto, o addirittura vicino. Più codice scrivi, più recensioni ottieni e recensioni fornisci , ti renderà un programmatore a tutto tondo migliore.

— ghiandaia
fonte

2

+1 per metterlo insieme e reviews you provideperché essere critici nei confronti degli altri può essere una pratica importante per migliorare la critica del proprio codice per ottenere una migliore qualità.

— Jimmy Hoffa,

2

"Il 90% dei programmatori nei film è così falso che ho lacrime entro la fine della sequenza." 90%? Che cosa i film che si guarda? : PI non ha visto un film che descriva accuratamente ciò che facciamo. E poi c'erano "Pesce spada" e "Festa dell'indipendenza" ...

— Nik Bougalis,

Ben messo e sinteticamente così!

— Kingdango,

16

Una delle cose migliori per me di essere uno sviluppatore è che ogni giorno è un processo di apprendimento. Ci sarà sempre qualcuno là fuori che non sa qualcosa che tu fai e ci sarà sempre qualcuno che sa qualcosa che tu non sai. Sicuramente non mi considero di essere altrove che a livello di ingresso / junior, ma apprezzo ogni critica che posso ottenere fintanto che sia giustificata e data con rispetto.

Un'analogia che potrebbe essere adatta si riferisce a un periodo in cui ero un tutor di scrittura in un'università, nonché quando ho preso parte a corsi di scrittura creativa. Scrivere codice, a tutti gli effetti, è molto simile a scrivere una poesia, un saggio, un racconto o un romanzo. Ogni individuo ha il suo modo di farlo, ma allo stesso tempo anche i migliori scrittori (o, in questo caso, gli sviluppatori) commettono errori o lasciano che le cose scivolino attraverso le fessure. Spesso non riusciamo a notare queste cose perché ci abituiamo così tanto alla nostra voce (o di nuovo, in questo caso, allo stile di codice).

Proprio come in qualsiasi campo, ci sono quelli che sono considerati esperti. Se quelle persone non esistessero, non avremmo nessuno da cui imparare. Supponendo che questo individuo in questione sia veramente un esperto, ascolterei quello che dice e chiederò cosa ti suggerirebbe di fare per migliorare il tuo codice. Non dimenticare mai, tuttavia, che non è l'unico che può dare la sua assistenza; abbiamo la fortuna che esista una pletora di risorse come SE / SO.

— Paolo
fonte

9

" Ci sarà sempre qualcuno là fuori che non sa qualcosa che tu fai, e ci sarà sempre qualcuno che sa qualcosa che tu non sai " - fantastico; +1.

— Maximus Minimus,

Sì, e voglio imparare tutto ciò che posso

— novizio

@mh: aggiungerei che una persona saggia generalmente imparerà molto di più dall'avere torto che dall'avere ragione. Questo non vuol dire che si dovrebbe cercare di sbagliare sulle cose, ma piuttosto che non si dovrebbe scoraggiarsi al riguardo purché si sfrutti le possibilità di apprendere.

— supercat

10

Il pasticcio è piuttosto soggettivo. La cosa migliore che puoi fare è chiedere effettivamente a quella persona (o al rapporto di revisione): perché è disordinato? (dal loro punto di vista, cioè)

Sono tenuti a risponderti e sarai in grado di:

Discutere contro di esso (se hai una buona ragione per farlo, ovviamente)
Sentiti molto felice, perché hai appena imparato qualcosa di nuovo e il tuo codice futuro sarà sicuramente più fantastico poiché ora sai come renderlo meno disordinato grazie ai loro consigli.

— Omega
fonte

Non ha commentato :( Ma ecco il mio codice -> codereview.stackexchange.com/questions/18719/…

— newbie

perché pensi che sia disordinato?

— Principiante

7

@newbie: Allora quel recensore non è molto bravo. In che modo un programmatore dovrebbe migliorare qualcosa senza sapere qual è il problema (nemmeno un indizio!)?

— Omega,

1

Okay grazie ... Non sono neanche un programmatore jquery. Sono un programmatore Java ...

— Principiante

1

Solo il mio codice è disponibile per lui quella volta. Ad ogni modo, hai ragione, chiederò maggiori dettagli a riguardo. Grazie :)

— novizio

8

Il fatto che tu sia preoccupato è un buon segno. Cominciamo con quello. Dici che ti piace programmare, ma ti piace essere un programmatore professionista? C'è una grande differenza tra un appassionato e un professionista. Come professionista sarai costantemente sotto controllo per il tuo prodotto di lavoro.

Our team is composed of 5 programmers, and 4 of us are new

Il fatto che tu abbia lavorato due anni senza alcun confronto mi dice che stai lavorando in un lavoro molto rilassato che, non è così buono se vuoi davvero andare avanti come professionista. Intendiamoci, alcuni dei migliori programmatori al mondo lavorano per la fondazione Linux e state certi che non vengono trattati gentilmente quando commettono errori marginali ... molto meno "codice disordinato".

Per una rapida revisione di alcune linee guida di codifica abbastanza standard, gli Standard dei contributori della comunità Linux dovrebbero darti un'idea del livello di responsabilità a cui aspirare per il tuo prodotto. Fare riferimento a COME OTTENERE IL CODICE GIUSTO.

Per favorire tale affermazione, dovresti imparare ad accettare la revisione poiché la maggior parte dei buoni software viene esaminata a fondo. Questo supporta la legge di Linus che afferma ...

"Se ci sono abbastanza revisori, tutti i problemi sono facili da risolvere."

Personalmente, ho visto sviluppatori altamente qualificati, responsabili e affidabili prendere l'ascia per qualcosa di semplice come dimenticare di lasciare commenti ... quindi se qualcuno ti dice che i tuoi codici sono un casino, probabilmente è ... Supera ... refactoring. Fa parte del concerto.

I feel so sad and hurt.

Vai a fare una domanda di tristezza per valutare quanto ti arrabbi quando non ti applichi.

Hai risposto al tuo problema ... Non testare!

Dopo aver visto un commento che hai fatto affermando che sei uno sviluppatore Java, mi sono quasi arrabbiato. Quindi, se ho capito bene la tua affermazione che tu e il tuo team di sviluppo state lavorando in un negozio Java e non disponete di un framework di test per le vostre applicazioni ...

Qui sta il rub

"Abbiamo distribuito il nostro programma al programma senza test approfonditi".

Cribbing UML Creator Grady Booch ...

L'ingegnere del software amatoriale è sempre alla ricerca della magia, un metodo o uno strumento sensazionale la cui applicazione promette di rendere banale lo sviluppo del software. È il marchio del software engineer professionista sapere che non esiste tale panacea.

Alistair Cockburn fornisce una vasta gamma di informazioni sul suo sito sull'uso di metodologie agili per aumentare le prestazioni e la qualità per te e il tuo team.

Uno degli aspetti più importanti della programmazione {e della vita} è conoscere i tuoi punti di forza e di debolezza. Se non lavori sulle tue debolezze non avrai un set di abilità a tutto tondo.

Outro ... Stai bene - Solo non lamentarti. Vai avanti nello sviluppo del tuo mestiere e lascia che la tua passione per la programmazione ti faccia andare avanti. In bocca al lupo :-)

— Eddie B
fonte

5

Non lasciare che le tue emozioni ostacolino il miglioramento del tuo codice. L'obiettivo di una revisione del codice è trovare i problemi, quindi non dovresti essere troppo sorpreso se ce ne sono. Detto questo, non dovrebbero neanche essere una sessione di codhing bashing.

Inoltre, non dovrebbero semplicemente dire "Ewwww" e lasciarlo a quello. C'è sempre una ragione per cui qualcosa non va nella programmazione. Ad esempio, è sbagliato lasciare un sacco di codice commentato in tutto il luogo, ma è sbagliato perché ingombra il codice e rende più difficile la lettura, non perché qualcuno lo ha detto in un libro.

Il tuo codice non sei tu. Ricordati che.

— Michael Shaw
fonte

4

Sarò il cazzone qui e consiglierò sulla base di ... beh, l'ovvio. Ovviamente, il tuo codice È un casino o la domanda che faresti è "PERCHE 'qualcuno sta dicendo che il mio codice è un casino?" Ma non stai sfidando la supposizione. Ti stai solo comportando male e francamente potrebbe esserci un pianto, ma non si ha la sensazione di giustificare la programmazione.

Ma davvero, perché me lo chiedi? Sai che il tuo codice fa schifo o faresti una domanda diversa. Se qualcuno mi dicesse che il mio codice web back-end puzza, riderei e direi "okay cosa c'è che non va?" Se mi dicessero che il mio JavaScript puzzava, darei loro l'equivalente programmatore sociale di un labbro grasso e non chiederei mai consigli su come reagire perché le piccole puttane sono chiaramente sbagliate!

Possiedi ciò in cui sei bravo. E intendo davvero assumermi la responsabilità. perché ci vuole solo uno sciocco per alcuni stupidi per indovinarti di nuovo. Non chiedere il permesso di essere buono. Conosci solo le tue cose. La fine.

— Erik Reppen
fonte

Amen. E conoscere le tue cose richiede ... beh ... uno sforzo per assicurarti di conoscere le tue cose. Ma assicurati anche di farti scoppiare il colletto, ecco cosa fanno tutti i bambini d'élite in questi giorni. : /

— kingdango,

Sì, penso di aver appena dato consigli altrove sugli sviluppatori più esperti, essendo i primi ad ammettere che hanno torto. Posso evitare molte personalità.

— Erik Reppen,

4

Ricorda questo: il peggior codice che tu abbia mai visto è il tuo!

Jeff Atwood di codinghorror.com ha scritto molto sull'argomento, potresti iniziare qui: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Se vuoi migliorare, inizia a leggere cose su stile di codifica, modelli, flussi di lavoro, praticamente tutto ciò su cui puoi mettere le dita. Impara anche più linguaggi di programmazione, guarda come fanno le cose. Se stai eseguendo OOP, leggi questo: http://en.wikipedia.org/wiki/Design_Patterns

Parla anche con altri programmatori e abbina la programmazione o guarda altri codici.

Fare errori è inevitabile, ripeterli è.

— Lucas Hoepner
fonte

È un buon sentimento (il mio preferito è legato al fatto che inizio sempre assumendo che il problema con un'applicazione sia colpa mia) ma purtroppo si scopre che no, il peggior codice che tu abbia mai visto potrebbe non essere il tuo .. non se sei abbastanza intelligente da essere qui e per chiedertelo in primo luogo ...

— Murph

4

Il più delle volte dovresti dire "Grazie" alla persona che ti ha detto questo.

È probabile che si preoccupino della loro professione, si preoccupino del loro lavoro, si preoccupano della loro squadra e si preoccupano per te.

Può essere difficile prendere le critiche. Non ti arrabbiare. Pensa a cosa stanno cercando di dirti e non lasciare che le tue emozioni abbiano la meglio su di te.

Sto programmando da molto tempo (30 anni) e il mio stile e il mio codice migliorano continuamente (spero). L'unico modo in cui so che sta migliorando è quando gli altri me lo dicono o se torno indietro e rivedo il mio codice.

Prova a guardare il codice che hai scritto all'inizio della tua carriera. Come ti sembra adesso? Ha un bell'aspetto come credevi quando l'hai scritto;)

— Fortyrunner
fonte

3

Prima di tutto, devi capire che la programmazione è un processo iterativo, proprio come scrivere un articolo o un libro. Per prima cosa scrivi una "bozza" del tuo programma, solo per farlo funzionare. A questo punto, il tuo codice sarà un disastro. Quindi ti rifatti per rendere pulito il codice. Quindi fai il profilo e vedi cosa devi ottimizzare per renderlo veloce. Il trucco è di refactoring continuamente, altrimenti il disordine crescerà. Devi pulire il tuo codice regolarmente, proprio come devi pulire la tua casa.

Le revisioni del codice sono assolutamente essenziali. Devi avere il tuo codice controllato da almeno un altro paio di occhi. Quando passi innumerevoli ore a guardare il tuo codice, ti abitui e puoi facilmente perdere un bug o un odore di codice che il tuo collega potrebbe notare all'istante.

Inoltre, l'atto di spiegare il tuo codice a qualcun altro è un ottimo modo per vedere se hai perso qualcosa. È come leggere un articolo che stai scrivendo ad alta voce. Il tuo cervello elabora le informazioni audio e visive in diversi modi e puoi trovare difetti nel tuo ragionamento cambiando modalità. Inoltre, se spieghi il tuo codice a un collega e qualcosa non ha senso per lei, questa è una buona indicazione che dovresti riformattare il tuo codice.

Quando si esegue una revisione del codice, è molto importante che sia l'autore sia il revisore controllino il proprio ego alla porta. L'obiettivo è migliorare il codice. Quindi il recensore deve essere rispettoso e l'autore deve tenere una mente aperta. Ricorda, i tuoi colleghi sono quelli che dovranno mantenere il tuo codice, quindi deve essere chiaro a loro. Se il revisore non capisce cosa fa una variabile, rinominala. Se il revisore non è in grado di capire cosa fa un blocco di codice, trasformalo in una funzione con un nome descrittivo. Indipendentemente da ciò che potresti pensare, se i tuoi colleghi non riescono a capire il tuo codice, non va bene.

Parlando di refactoring, devi assolutamente avere un framework di unit test, perché senza di esso non puoi refactoring.

Infine, consiglio vivamente di leggere "Clean Code" di Robert C. Martin. Ti dirà perché il tuo codice è un disastro e cosa puoi fare per ripulirlo.

— Dima
fonte

3

Puoi darmi consigli su come essere migliore?

La risposta di Jay che raccomanda i libri è buona, tuttavia sembra che tu sia già a un punto di svolta al lavoro.

Passato:

Il nostro team è composto da 5 programmatori e 4 di noi sono nuovi, 1 ha più di 3 anni di esperienza. Lavoriamo per un programma da quasi un anno e nessuno ha mai rivisto il mio codice e mi è stata data una pagina con cui lavorare.

Presente:

Ora è stretto e abbiamo bisogno di un'approvazione e di una revisione del codice prima di apportare modifiche al codice.

Sembra che la tua azienda / team / dipartimento stia imparando nel suo insieme, in termini di gestione di progetti e team, nonché di programmazione. Iniziare a rivedere il codice è un'ottima opportunità per migliorare praticamente in tutte le aree se viene data la giusta attenzione.

Usalo come un'opportunità; supponendo che tu stia facendo revisioni tra pari (con gli altri sviluppatori del tuo team) suggeriscono loro che questo processo è importante e che tutti possono imparare da esso.

Alla base sarà una rapida rassegna con il risultato che "sì sembra ok". Con uno sforzo un po 'più mirato puoi rimbalzare le idee l'una dall'altra, "sì, funziona, ma avresti potuto affrontarlo in questo modo, il che avrebbe reso il tuo obiettivo più chiaro ...". Prendi appunti per il futuro anche se il codice è ritenuto corretto da distribuire.

Se questo avrà successo, devi mettere in squadra il tuo team e il tuo manager, il che spesso significa spiegare loro i vantaggi. Per gli altri sviluppatori questa è un'opportunità per imparare. Per il tuo manager questa è l'opportunità di migliorare le competenze del team a costi contenuti, creando quindi output a) con più valore o b) più velocemente c) con costi di manutenzione inferiori (di solito un grosso problema!).

Questo è un cambiamento culturale, che non puoi forzare da solo, ma puoi aiutare a spingere le cose nella giusta direzione!

Non dimenticare, questo tipo di cambiamento culturale può essere estremamente vantaggioso per le organizzazioni; i bravi manager riconosceranno che stai lavorando per migliorare l'intera squadra, qualcosa che vale la pena premiare.

— opaco
fonte

3

Puoi darmi consigli su come essere migliore? Hai mai provato qualcosa che critica il tuo codice e ti senti davvero ferito? Cosa fai in quegli eventi.

La risposta a questa può essere trovata nelle società di nuova generazione. Sono stato in aziende come Google e FaceBook e vedo che se segui religiosamente il processo Agile / Scrum, puoi scrivere codice migliore e migliorarlo ogni sprint.

How to be better?

La risposta è il refactoring continuo. I moderni strumenti di sviluppo come Visual Studio hanno molti strumenti che ti aiutano in questo processo. Se segui il processo di sviluppo del software Scrum, ad esempio, hai scritto un codice errato nel ciclo di sprint 1 e qualcuno ha sottolineato durante la revisione che è male, quindi nello sprint 2 hai l'opportunità di refactoring del codice.

Questi problemi si verificano in primo luogo a causa della mancanza di un buon processo. Quindi la soluzione è quella di elaborare un buon processo di sviluppo software per il tuo team e praticare il refactoring continuo.

— Avinash Kumar
fonte

3

Vorrei ringraziarli per il feedback e quindi chiedere loro di spiegare cosa lo rende negativo e come dovrebbe essere migliorato.

Se sei d'accordo che la persona che sta dando il feedback abbia un senso, prendi in considerazione di apportare modifiche in futuro. Ma ricorda, solo perché qualcuno dice che non significa che sia vero.

Puoi fornire esempi specifici di ciò che è stato definito "un casino"?

— Tony Ennis
fonte

I sentimenti a volte possono essere difficili, ma è certamente così che spero di reagire.

— Thomas Padron-McCarthy,

3

Prima di tutto qualcuno che dice che il tuo codice è un casino è molto vago e soggettivo. Può significare cose diverse per persone diverse. Ecco perché; ci sono due cose diverse che devono essere considerate.

Struttura

La struttura del codice è regolata dalla lingua, dagli standard di settore e dagli standard aziendali per citarne alcuni. Ovviamente ci sono anche altri fattori.

Questi sono i tipi di errori che lanugine, strumenti di test e prodotti simili sono progettati per identificare. Sono ben definiti e tu o i tuoi strumenti potete prendere decisioni oggettive sulla loro validità / correttezza.

Stile

Nonostante la struttura / regole standardizzate per il codice, ogni sviluppatore ha un certo stile nel modo in cui scrive e affronta un problema o un'attività. Effettua la manutenzione del codice in qualsiasi ambiente di squadra e nel tempo sarai in grado di indovinare chi ha scritto il codice in base allo stile. Svilupperai anche il tuo stile personale e cambierà man mano che acquisisci esperienza e impari il tuo mestiere.

Quindi ogni volta che qualcuno dice che il tuo codice è un disastro devi capire se stanno parlando della struttura o dello stile . Sono due cose molto diverse; la struttura è oggettiva mentre lo stile è assolutamente soggettivo.

Detto questo, qualsiasi feedback costruttivo da parte di altri programmatori può essere molto prezioso per te. Dipende da te e da come prendi le critiche. Con il passare del tempo imparerai chi è l'opinione da prendere a cuore contro chi deve prendere con un granello di sale.

Man mano che avanzi nella tua carriera, guarderai indietro al tuo codice e vedrai cose che potresti fare in modo diverso, migliore, più pulito e più veloce. Fa tutto parte del processo di apprendimento e vedere i tuoi errori passati è una vera indicazione che stai perfezionando e migliorando il tuo mestiere.

Non lasciare che un po 'di critica inumidisca il tuo umore. Prendi ciò che puoi da esso e se è significativo e prezioso aggiungilo al tuo archivio di conoscenza.

— Stephen
fonte

3

Mentre è importante riconoscere quando il proprio codice è un disastro (sensazione molto tipico tra i programmatori, soprattutto man mano che diventano più esperti e la loro età di codice precedenti) è ancora più importante ascoltare quando gli altri ti dicono così.

Ci sono solo così tanti problemi che puoi riconoscere nel tuo codice, poiché è stato prodotto in vincoli delle tue attuali conoscenze di programmazione.

La revisione del codice è un'opportunità di apprendimento essenziale perché probabilmente ti espone a nuove conoscenze che non avevi durante il lavoro sul codice (altrimenti lo utilizzeresti e non ci sarebbero problemi).

Penso che ci siano due parti per l'elaborazione del feedback negativo.

1. Determina la natura dei problemi sollevati e cosa dovresti imparare da esso

Quando rivedo o faccio rivedere il mio codice, ordino le informazioni sui problemi del codice in circa tali bucket:

viola i severi requisiti tecnologici
- chiaramente sbagliato (non funziona o non soddisfa i requisiti)
- fallirà in altre circostanze (modifica ambiente / configurazione)
- utilizza funzionalità obsolete e si romperà in un futuro prevedibile
viola le migliori pratiche del settore, mancando di cose come
- utilizzando un approccio comprovato a problemi specifici
- prestazione
- compatibilità con le versioni precedenti
- facilità di manutenzione
- stile di codifica
- documentazione
viola le migliori pratiche sul posto di lavoro
- come l'industria, ma più specifica per azienda / colleghi e può differire dall'industria nei dettagli
non in linea con le competenze personali
- può essere migliorato in qualche modo, in vista della revisione della persona

Nota che questo va da cose molto oggettive ("questo si interromperà quando distribuito sul nostro server di produzione") a cose molto soggettive ("Non mi piace come hai chiamato le variabili").

2. Determinare quali (se presenti) modifiche al codice verranno apportate come risultato della revisione

Dopo che le informazioni sono state elaborate, viene presa la decisione se è utilizzabile e se il codice deve essere modificato. Questa non è necessariamente una tua decisione, la tua opinione potrebbe o meno avere importanza a seconda delle parti coinvolte e dei dettagli della tua situazione (anzianità, ecc.). Ma i possibili risultati sono all'incirca:

risolvere il problema per intero
- riparato rotto
- formato secondo lo stile di codifica richiesto
- e così via
scendere a compromessi se il problema dovrebbe essere affrontato in tutto o in parte, dal momento che potrebbe esserci
- nessuna risorsa (come tempo o budget)
- nessuna necessità (otterrà solo miglioramenti insignificanti, stabilità di compromesso, ecc.)
capire che il problema sollevato non è valido
- il feedback (specialmente dalla categoria di opinione soggettiva) può benissimo essere dannoso e non dovrebbe essere seguito alla cieca

Hai imparato che è doloroso ricevere feedback negativi e potrebbe benissimo essere doloroso ogni volta in futuro. Tuttavia, hai lasciato imparare come è importante opportunità di apprendimento e come il processo ti aiuta a migliorare professionalmente e il tuo posto di lavoro per ottenere una migliore base di codice.

— Rarst
fonte

1

Beh, non sentirti rotto. Alla fine imparerai dagli errori. Una volta che hai finito con il problema, puoi parlare con un ragazzo in modo che gli senta che vuoi migliorare. Prova ad ascoltare di più e a discutere di meno.

Ho attraversato questa situazione e posso capire.

— Hisham
fonte

0

TL; DR

Come reagiresti se qualcuno ti dicesse che il tuo codice è un casino?

Il mio semplice "troppo tempo non ha letto (tutte le risposte - mi scuso, spero di trovare il tempo per in seguito e modificarlo / modificarlo se necessario)" risposta / suggerimento:

Buona vecchia recensione tra pari. Chiedi a diversi equipaggi con mentalità collettive, livelli di competenza e / o livelli di aggressività diversi per rivedere il tuo codice.
Giusto per elaborare un po 'ciò che intendo per "diversi" gruppi di pari: la diaspora StackExchange è probabilmente il gruppo più ricercato, professionale e stimato a causa della relativa difficoltà a farne parte rispetto, per esempio, a Reddit. Reddit tende ad essere molto aggressivo nei sub-rossetti più popolari - ma stranamente i subreddit di programmazione sono abbastanza amichevoli (da quello che ho sperimentato).

Un buon, forse il migliore, esempio dell'aggressivo, gangsta tipo di mentalità cricca è la folla dei forum XDK, e il peggio del peggior trofeo che consegno al popolamento di forum / canale IRC di CyanogenMod per Android.

È stato un po 'più lungo di quanto pensassi; il mio punto doveva essere: ottenere recensioni varie, ma concentrarsi sull'ottenere una critica onesta da parte delle persone che conoscono il loro mestiere e sapere quali sono le critiche costruttive . Oh, ed essere in grado di prendere qualsiasi forma di critica senza lasciarti abbattere. Regola empirica: se inizi a sentire commenti simili relativi a una cosa che può essere reciproca con i commenti, fai qualche introspezione più approfondita.

— skopp
fonte