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

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

Quindi, se la persona che ha detto che il tuo codice è un disastro non è solo cattiva e non è un altro caso di malattia "lo farei meglio" in comune tra i programmatori dovresti chiedergli cosa c'è di sbagliato nel tuo codice e come puoi migliorarlo.

Non essere orgoglioso di quanto bene codifichi. Sii orgoglioso di quanto bene impari. Quindi imparare che il tuo codice ha bisogno di miglioramenti ti offre l'opportunità di dimostrare quanto sei bravo a imparare, invece di criticare quanto sei cattivo in un programmatore.

Leggi link se non hai idea di cosa sto parlando.

Dopo oltre 20 anni so che parte del mio codice è ancora un casino. Quello che viene in mente è prendere una decisione tra scrivere il miglior codice possibile e scrivere quello che è necessario per fare il lavoro. Ottenere il lavoro entro un lasso di tempo concordato supera ogni volta la continua ricerca della perfezione tecnica.

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

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

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

Ci sono:

• programmatori spediti velocemente,
• programmatori che spediscono sempre codice semanticamente corretto,
• programmatori che trovano sempre la soluzione ottimale e l'algoritmo più veloce
• programmatori il cui codice è facile da guardare.

Difficilmente, se non mai, finiscono per essere la stessa persona.

E ci sono dei maiturici programmatori che devono crescere e

• chiedi cosa c'è che non va,
• non fare commenti personali, come misura del loro valore come essere umano;
• renditi conto che ci sono linee guida sulla sintassi nei team, e devono essere seguiti, e sono arbitrari, quindi non sono pensati per essere discussi ad nauseam , come non è una soluzione ottimale, né una parola finale;
• migliorare nel commentare il loro codice;
• migliorare nel commentare il loro codice; (sic)
• trova più facile eseguire il debug, meno intelligente, soluzioni a compiti semplici, banali;
• prendere una lezione in SQL
  (manderei metà della popolazione di questo mondo a prendere una lezione in SQL, solo per essere al sicuro)

Non è arte, è un mestiere.
Diamo per scontato che tu sia intelligente: stai programmando computer, dannazione.
Ancora AMD64 e x86 non sono forzati dalla potenza della tua prosa. Mantieni le cose semplici.

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

Più pulito è il tuo codice base, meno tempo spendi per combattere il codice base per risolvere un determinato problema. Un anno è un ottimo punto per essere in, perché puoi provare i dolori di qualsiasi decisione di progettazione che hai preso in precedenza nel progetto.

Nel mio attuale progetto, ci siamo rifattorizzati più volte, grazie al nostro stack tecnologico. Questo dovrebbe essere incoraggiato e dovresti prendere nota delle attività che richiedono più tempo di quanto dovrebbero a causa dell'attuale code-base.

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

Anche quando parli di una mancanza di test, questo è sempre qualcosa da guardare. Nel nostro progetto non avevamo test automatici e di conseguenza un codice molto accoppiato. Anche se non scrivi regolarmente unità / integrazione / test, farla per un po 'ti farà prendere l'abitudine di rendere il tuo codice più modulare (e di conseguenza meno pasticcio).

I feel so sad and hurt. I really love programming and making them say something like that really hurts me. I really want to improve myself.

Questo è buono. Questo è un lotto migliore di una reazione del tipo "il mio revisore non ha idea di cosa stia parlando", "il mio revisore è troppo schizzinoso" o semplicemente "il mio revisore non mi piace" e ignora loro. Questo atteggiamento è una buona cosa.

But it seems like I'm not a genius programmer like in the movies.

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

Can you give me advise on how to be better?

Leggi e pratica. Consulta libri come codice completo o Il programmatore pragmatico . Guarda Amazon per libri simili.

Have you ever experience something criticizing your code and you feel really hurt? What do you do on those events..

Perché ti senti ferito? Mi sento deluso da me stesso per essere stato un tale deficiente in primo luogo. Io uso questa motivazione per ripulire il mio codice e per assicurarmi di non ripetere lo stesso errore . L'ultima cosa I voglio farlo non imparare da essa. Sei stato messo giù una volta, non lasciare che accada di nuovo per lo stesso motivo.

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

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 fai, e ci sarà sempre qualcuno che sa qualcosa che tu non conosci. Certamente non mi considererei da nessuna parte se non a livello di entrata / livello, ma apprezzo qualsiasi critica che posso ottenere finché è sia giustificata che data con rispetto.

Un'analogia che potrebbe essere adeguata riguarda un periodo in cui ero un tutor di scrittura in un'università, così come quando prendevo parte a corsi di scrittura creativa. Scrivere un codice, a tutti gli effetti, è molto simile a scrivere un poema, un saggio, un racconto o un romanzo. Ogni individuo ha il proprio 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é siamo così abituati alla nostra stessa voce (o ancora, in questo caso, stile di codice).

Molto simile 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, però, che non è l'unico che può dare la sua assistenza; abbiamo la fortuna che esiste una pletora di risorse come SE / SO.

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

Sono tenuti a rispondervi e sarete in grado di:

• Argomento contrario (se hai una buona ragione per farlo, ovviamente)
• Sentiti molto felice, perché hai appena appreso qualcosa di nuovo e il tuo codice futuro è destinato ad essere più fantastico dato che ora sai come renderlo meno complicato grazie ai loro consigli.

Il fatto che tu sia preoccupato è un buon segno. Iniziamo con quello. Hai detto che ami programmare, ma ti piace essere un programmatore professionista? C'è una grande differenza tra un appassionato e un professionista. Come professionista sarai sotto costante 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 per due anni senza alcun confronto mi dice che stai lavorando in un lavoro molto rilassato che, non è così bello se in realtà vuoi andare avanti come professionista. Intendiamoci, alcuni dei migliori programmatori al mondo lavorano per la fondazione Linux e si assicurano che non vengano trattati in modo gentile quando commettono errori marginali ... tanto meno "codice disordinato".

Per una rapida revisione di alcune linee guida di codifica standard, gli Norme dei contributori della Linux Community dovrebbe darti un'idea del livello di responsabilità verso cui aspirare per il tuo prodotto. Fare riferimento a OTTENERE IL CODICE DESTRA.

Per approfondire questa affermazione, dovresti imparare ad accettare la revisione poiché la maggior parte del buon software è completamente rivista. Questo supporta Legge di Linus che dichiara ...

"If there are enough reviewers, all problems are easy to solve."

Personalmente, ho visto sviluppatori altamente qualificati, responsabili e affidabili ottenere l'ascia per qualcosa di semplice come dimenticare di lasciare commenti ... quindi se qualcuno ti dice i tuoi codici pasticcio allora probabilmente lo è ... Passaci sopra ... Refactoring. Fa parte del concerto.

I feel so sad and hurt. 

Vai a fare un'applicazione di tristezza per valutare quanto sei sconvolto quando non ti applichi.

You answered your problem ... You Don't Test!

Dopo aver visto un commento che hai dichiarato che sei uno sviluppatore Java, mi sono quasi arrabbiato. Quindi, se comprendo correttamente la tua affermazione che tu e il tuo team di sviluppo lavorate in un negozio Java e non disponiate di un framework di test per le vostre applicazioni ...

Therein Lies The Rub

"We deployed our program to the program without thorough testing."

Cribbing UML Creator Grady Booch ...

The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists.

Alistair Cockburn fornisce una grande quantità 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 sui tuoi punti deboli non avrai un set completo di abilità.

Outro ... Stai bene - Solo non lamentarti. Sposta in avanti nello sviluppo del tuo mestiere e lascia che la tua passione per la programmazione continui ad andare avanti. Buona fortuna: -)

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

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

Il tuo codice non sei tu. Ricordatelo.

Sarò il coglione qui e consiglierò sulla base di .. beh, l'ovvio. Ovviamente, il tuo codice è un casino o la domanda che ti starai chiedendo è "PERCHÉ qualcuno sta dicendo che il mio codice è un casino?" Ma non stai sfidando la supposizione. Ti stai solo facendo male e francamente potrebbe esserci un pianto, ma non c'è nessuna sensazione quando si tratta di giustificare la programmazione.

Ma davvero, perché stai chiedendo? Sai che il tuo codice fa schifo o faresti una domanda diversa. Se qualcuno mi avesse detto che il mio codice web di back-end è stato stordito, avrei riso e avrei detto "ok cosa c'è che non va?" Se mi dicessero il mio JavaScript puzza, darei loro il programmatore sociale equivalente a un grasso labbro e non chiederei mai un consiglio su come reagire perché le piccole femmine sono chiaramente! @ # $ Sbagliato.

Possedere ciò in cui sei bravo. E intendo davvero assumermi la responsabilità per questo. perché ci vuole solo un pizzicotto per un po 'di twit per indovinare. Non chiedere il permesso di essere buono. Conosci solo le tue cose. La fine.

Ricorda questo: il peggior codice che tu possa mai vedere è il tuo!

Jeff Atwood di codinghorror.com ha scritto molto sull'argomento, potresti voler iniziare qui: link

Se vuoi migliorare, inizia a leggere cose su stile, schemi, flussi di lavoro di codifica, praticamente tutto ciò che puoi mettere sulle dita. Impara anche altri linguaggi di programmazione, guarda come fanno cose. Se stai facendo OOP, leggi questo: link

Parla anche con altri programmatori e associa la programmazione o guarda il codice degli altri.

Fare errori è inevitabile, ripetendoli è.

La maggior parte delle volte dovresti dire "Grazie" alla persona che ti ha detto questo.

Le probabilità sono che abbiano a cuore la loro professione, che si preoccupino del loro lavoro, che si preoccupano della loro squadra e che si preoccupano per te.

Può essere difficile criticare. Non arrabbiarti per questo. Pensa a quello che stanno cercando di dirti e non lasciare che le tue emozioni abbiano la meglio su di te.

Ho programmato per molto tempo (30 anni) e il mio stile e codice migliorano continuamente (spero). L'unico modo in cui so che il suo miglioramento è quando altre persone mi dicono o se torno indietro e rivedo il mio codice.

Prova a guardare il codice che hai scritto all'inizio della tua carriera. Che aspetto ti sembra ora? Sembra buono come pensavi quando lo hai scritto;)

Prima di tutto, devi capire che la programmazione è un processo iterativo, molto simile alla scrittura di un articolo o di un libro. Per prima cosa scrivi una "bozza preliminare" del tuo programma, solo per farlo funzionare. In questa fase, il tuo codice sarà un disastro. Quindi ti rifatti per rendere il codice pulito. Quindi profili e vedi cosa è necessario ottimizzare per renderlo veloce. Il trucco è quello di refactoring continuamente, altrimenti il pasticcio crescerà. Devi pulire il tuo codice regolarmente, proprio come devi pulire la tua casa.

Le recensioni dei codici sono assolutamente essenziali. Devi avere il tuo codice guardato da almeno un altro paio di occhi. Quando trascorri ore e ore a guardare il tuo codice, ti ci 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 foglio che stai scrivendo ad alta voce. Il tuo cervello elabora le informazioni audio e visive in modi diversi, 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, è una buona indicazione che devi refactoring il tuo codice.

Quando si fa una revisione del codice è molto importante sia per l'autore che per il revisore controllare il proprio ego alla porta. L'obiettivo è rendere il codice migliore. Quindi il revisore deve essere rispettoso e l'autore deve mantenere una mente aperta. Ricorda, i tuoi collaboratori 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 può capire cosa fa un blocco di codice, rifattalo 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.

A proposito di refactoring, devi assolutamente avere un framework di test unitario, perché senza di esso non puoi refactoring.

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

Can you give me advise on how to be better?

La risposta di Jay che consiglia i libri è buona, tuttavia sembra che tu abbia già una svolta al lavoro.

Passato:

Our team is composed of 5 programmers, and 4 of us are new, 1 has more than 3 year experience. We've been working for a program for almost a year now and nobody ever review my code and I was given a page to work with.

presente:

Now it is tight and we need an approval and code review first before we make changes with the code.

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

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

Alla linea di base sarà una rapida recensione con il risultato che "sì sembra ok". Con uno sforzo un po 'più focalizzato puoi far rimbalzare le idee l'una dell'altra ", sì, funziona, ma avresti potuto affrontarlo in questo modo, il che avrebbe reso il tuo obiettivo più chiaro ...". Prendere appunti per il futuro, anche se il codice è ritenuto ok per la distribuzione.

Se ciò avrà successo, è necessario mettere da parte la squadra e il manager, il che significa spesso spiegarne i benefici. Per gli altri sviluppatori questa è un'opportunità per imparare. Per il tuo manager questa è l'opportunità di potenziare il team a costi minimi, quindi creare output a) con più valore o b) più veloce c) con meno costi di manutenzione (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 che questo tipo di cambiamento culturale può essere estremamente utile per le organizzazioni; i buoni manager riconosceranno che stai lavorando per migliorare l'intera squadra, qualcosa che vale la pena ricompensare.

Can you give me advise on how to be better? Have you ever experience something criticizing your code and you feel really hurt? What do you do on those events.

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

How to be better? 

La risposta è un 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, quindi per esempio, hai scritto codice errato nel ciclo sprint 1 e qualcuno ha segnalato che durante la revisione non funziona, quindi nello sprint 2 hai l'opportunità di rifattorizzare il codice.

Questi problemi si verificano in primo luogo a causa della mancanza di un buon processo. Pertanto, la soluzione consiste nel realizzare un buon processo di sviluppo software per il tuo team e praticare il refactoring continuo.

Li ringrazierei per il feedback, quindi chiedo loro di spiegare cosa lo rende cattivo e come dovrebbe essere migliorato.

Se sei d'accordo, la persona che dà il feedback ha un senso, considera di fare cambiamenti in futuro. Ma ricorda, solo perché qualcuno dice che non significa che sia vero.

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

Prima di tutto qualcuno che dice che il tuo codice è un pasticcio è 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 tuo 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 filamenti, strumenti di test e prodotti simili sono progettati per identificare. Sono ben definiti e tu oi tuoi strumenti potete prendere decisioni obiettive sulla loro validità / correttezza.

Stile

Nonostante la struttura e le regole standardizzate per il codice, ogni sviluppatore ha un certo stile nel modo in cui scrive e affronta un problema o un'attività. Esegui la manutenzione del codice in qualsiasi ambiente del team e nel tempo sarai in grado di indovinare chi ha scritto il codice in base allo stile. Svilupperai anche il tuo stile e cambierà man mano che acquisirai esperienza e imparerai la tua abilità.

Quindi ogni volta che qualcuno dice che il tuo codice è un pasticcio devi capire se stanno parlando della struttura o dello stile . Sono due cose molto diverse; structure è obiettivo mentre style è assolutamente soggettivo.

Detto questo, qualsiasi feedback costruttivo da parte di altri programmatori può essere molto prezioso per te. Dipende tutto da te e da come prendi le critiche. Col tempo imparerai chi ha un'opinione da prendere a cuore contro chi lo farà con un pizzico di sale.

Mentre progredisci nella tua carriera, ripercorrerai il 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 smorzi i tuoi spiriti. Prendi quello che puoi da esso e se è significativo e prezioso aggiungilo al tuo negozio di conoscenza.

Mentre è importante riconoscere quando il tuo codice è un casino (sentimento molto tipico tra i programmatori, specialmente quando diventano più esperti e il loro vecchio codice invecchia) è anche più importante da ascoltare quando altre persone te lo dicono così.

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

La revisione del codice è un'opportunità di apprendimento essenziale perché probabilmente ti espone alla nuova conoscenza che non avevi durante il lavoro sul codice (altrimenti la userai e non ci sarebbe alcun disastro).

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

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

Quando rivedo o rileggo il mio codice, ordino informazioni sui problemi relativi al codice in circa questi bucket:

• viola i severi requisiti tecnologici
  • semplicemente sbagliato (non funziona o non soddisfa i requisiti)
  • fallirà in altre circostanze (ambiente / modifica della configurazione)
  • utilizza funzionalità deprecate e si interromperà in un futuro prevedibile
• viola le migliori pratiche del settore, carenti in cose come
  • utilizzando un approccio collaudato a un problema specifico
  • prestazioni
  • compatibilità retroattiva
  • facilità di manutenzione
  • stile di codifica
  • documentazione
• viola le migliori pratiche sul posto di lavoro
  • come il settore, ma più specifico per azienda / colleghi e può differire dal settore in dettaglio
• non in linea con le competenze personali
  • può essere migliorato in qualche modo, secondo l'opinione della persona che esamina

Si noti che questo va da cose molto oggettive ("questo si romperà quando implementato nel nostro server di produzione") a cose molto soggettive ("Non mi piace come hai chiamato le variabili").

2. Determina quali (eventuali) modifiche al codice verranno apportate come risultato della revisione

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

• problema di indirizzo completo
  • correzione non funzionante
  • formatta allo stile di codifica richiesto
  • e così via
• arrivare a un compromesso se il problema debba essere affrontato in tutto o in parte, poiché potrebbe esserci
  • nessuna risorsa (come tempo o budget)
  • non serve (otterrà solo miglioramenti insignificanti, comprometterà la stabilità, ecc.)
• arriva a capire che il problema sollevato non è valido
  Il feedback di
  • (in particolare dalla categoria di opinioni soggettive) può benissimo essere del tutto dannoso e non dovrebbe essere interpretato alla cieca

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

Beh, non sentirti rotto. Alla fine imparerai dagli errori. Una volta che hai finito con il problema, puoi parlare con un ragazzo così da fargli sentire che vuoi migliorare. Cerca di ascoltare di più e discuti di meno.

Ho attraversato questa situazione e posso capire.

TL; DR

How would you react if someone told you your code is a mess?

Il mio semplice, "troppo a lungo non ho letto (tutte le risposte - scuse, spero di trovare il tempo per dopo e modificare / emendare se necessario)" risposta / consiglio:

• Buona vecchia peer review. Chiedi a diversi equipaggi con diverse mentalità collettive, livelli di esperienza e / o livelli di aggressività per rivedere il tuo codice.
• Solo per approfondire ciò che intendo per "diversi" gruppi di pari: la diaspora di StackExchange è probabilmente il gruppo più apprezzato, professionale e stimato a causa della relativa difficoltà nel farne parte rispetto a, diciamo, Reddit. Reddit tende ad essere molto aggressivo nei sub-reddits più popolari - ma stranamente i subreddit di programmazione sono abbastanza amichevoli (da quello che ho vissuto).

Un buon esempio, forse il migliore, di mentalità aggressiva e di tipo gangsta sono la folla dei forum XDK, e il peggiore dei peggiori trofei che offro al CyanogenMod per i forum Android / la popolazione dei canali IRC.

Questo è stato un po 'più lungo di quanto intendessi; il mio punto avrebbe dovuto essere: ricevere recensioni varie, ma concentrarsi su come ottenere critiche oneste da parte delle persone che conoscono il loro mestiere e sapere cosa è la critica costruttiva . Oh, ed essere in grado di prendere qualsiasi forma di critica senza lasciarti abbattere. Regola pratica: se inizi a sentire commenti simili a una cosa che può essere reciproca ai commenti, esegui un'introspezione più approfondita.