Como você reagiria se alguém lhe dissesse que seu código está uma bagunça?

Sou um bom programador, ou assim pensei antes. Eu sempre gosto de programar. E quero aprender muitas coisas sobre programação para me tornar um programador melhor. Estudei programação por 1 ano e agora estou trabalhando como programador por quase 2 anos. Em resumo, tenho quase 3 anos de experiência em programação.

Nossa equipe é composta por 5 programadores e 4 de nós somos novos, 1 tem mais de 3 anos de experiência. Estamos trabalhando para um programa há quase um ano e ninguém nunca revisou meu código, e recebi uma página para trabalhar. Nunca tivemos uma revisão de código e somos todos novos, portanto não sabemos como é um código limpo. Eu acho que os programadores aprendem sozinhos?

Implementamos nosso programa no programa sem testes completos. Agora está apertado e precisamos de uma aprovação e uma revisão do código antes de fazer alterações no código. Pela primeira vez, alguém analisa meu código e ele diz que é uma bagunça.

Eu me sinto tão triste e magoada. Eu realmente amo programar e fazê-los dizer algo assim realmente me machuca. Eu realmente quero me melhorar. Mas parece que eu não sou um programador genial como nos filmes. Você pode me dar conselhos sobre como melhorar? Você já experimentou algo que critica seu código e se sente realmente magoado? O que você faz nesses eventos?

A verdade é que, provavelmente, em 2 anos, quando você verá seu código atual, concordará que era uma bagunça. Aprender programação é um processo sem fim e sempre haverá alguém que é melhor nisso do que você.

Portanto, se a pessoa que disse que seu código é uma bagunça não é apenas má e não é outro caso de doença "eu faria melhor" comum entre os programadores, pergunte a ele o que exatamente há de errado com seu código e como você pode melhore.

Não se orgulhe de quão bem você codifica. Orgulhe-se de quão bem você aprende. Em seguida, aprender que seu código precisa de aprimoramento oferece a oportunidade de demonstrar o quanto você é bom em aprender, em vez de parecer uma crítica ao quão ruim você é um programador.

Leia http://www.perlmonks.org/?node_id=270083 se você não tem idéia do que estou falando.

Depois de mais de 20 anos, sei que parte do meu próprio código ainda está uma bagunça. O que se resume é tomar uma decisão entre escrever o melhor código possível versus escrever o que é necessário para fazer o trabalho. Concluir o trabalho dentro de um prazo acordado supera a busca interminável por perfeição técnica a qualquer dia.

O truque é aprender a aceitá-lo. Aprenda a aceitar que você poderia fazer melhor. Aprenda a viver com as falhas. Aprenda a aceitar que desta vez não será perfeito, e provavelmente também da próxima vez, e que é uma escolha deliberada, porque a alternativa não está sendo cumprida. E isso é pior.

Isenção de responsabilidade: nada disso deve ser lido como "código inválido".

O código de todo mundo está uma bagunça e não há bons programadores.

Tem:

• programadores que enviam rápido,
• programadores que sempre enviam código semanticamente correto,
• programadores que sempre apresentam a solução ideal e o algoritmo mais rápido,
• programadores cujo código é fácil de ver.

Eles dificilmente, se alguma vez, acabam sendo a mesma pessoa.

E há outros programadores que precisam crescer e:

• pergunte o que há de errado,
• não faça nenhum comentário pessoalmente, como uma medida do seu valor como ser humano;
• perceber que há diretrizes de sintaxe em equipes, e eles tem que ser seguido, e eles são arbitrários, de modo que não está destinado a ser discutido ad nauseam , como não há nenhuma solução óptima, nem palavra final;
• fique melhor em comentar seu código;
• fique melhor em comentar seu código; (sic)
• encontre soluções mais fáceis de depurar, menos inteligentes, para tarefas simples e mundanas;
• faça uma aula de SQL
  (eu enviaria metade da população deste mundo para fazer uma aula de SQL, apenas para estar do lado seguro)

Não é arte, é um ofício.
Damos por certo que você é inteligente: você está programando computadores, maldição.
Ainda assim, AMD64e x86não são compelidos pelo poder da sua prosa. Mantenha as coisas simples.

Bem, uma pessoa que diz que seu código é uma bagunça não é construtiva, mesmo que esteja certa. Eles deram-lhe razões pelas quais está uma bagunça? Por exemplo, os métodos são muito longos, as responsabilidades são misturadas, muitas ramificações etc. Portanto, não se sinta mal por isso. Eu ficaria mais preocupado se você ainda gostasse de ler o código que escreveu há muito tempo.

Quanto mais limpa sua base de códigos, menos tempo você gasta lutando com a base de código para resolver um determinado problema. Um ano é um ótimo ponto para se estar, porque você pode sentir as dores de qualquer decisão de design que você tomou no início do projeto.

No meu projeto atual, refatoramos várias vezes à medida que nos sentimos mais confortáveis ​​com nossa pilha de tecnologias. Isso deve ser incentivado e você deve tomar nota das tarefas que demoram mais do que deveriam devido à atual base de código.

Você examinou algumas das partes mais antigas do código que escreveu? Você provavelmente pode ver as coisas que gostaria de fazer de forma diferente agora ou refatorar.

Além disso, quando você menciona a falta de teste, isso sempre é algo a se observar. Em nosso projeto, não tivemos testes automatizados e, como resultado, muitos códigos altamente acoplados. Mesmo que você não escreva regularmente testes de unidade / integração / o que quer que seja, por um tempo, você terá o hábito de tornar seu código mais modular (e, consequentemente, menos bagunçado).

Eu me sinto tão triste e magoada. Eu realmente amo programar e fazê-los dizer algo assim realmente me machuca. Eu realmente quero me melhorar.

Isso é bom. Isso é muito melhor do que ter uma reação como "meu revisor não tem idéia do que está falando", "meu revisor é muito exigente" ou apenas "meu revisor não gosta de mim" e ignorá-los. Essa atitude é uma coisa boa.

Mas parece que eu não sou um programador genial como nos filmes.

Não tenho certeza de que tipo de filme você assiste, mas 90% dos programadores são tão falsos que tenho lágrimas no final da sequência.

Você pode me dar conselhos sobre como melhorar?

Leia e pratique. Confira livros como Code Complete ou The Pragmatic Programmer . Procure na Amazon por livros semelhantes.

Você já experimentou algo que critica seu código e se sente realmente magoado? O que você faz nesses eventos?

Por que você se sente machucado? Sinto-me decepcionado por ser tão idiota em primeiro lugar. Uso essa motivação para limpar meu código e garantir que não cometa o mesmo erro novamente . A última coisa que quero fazer não é aprender com isso. Você foi humilhado uma vez, não deixe que isso aconteça novamente pelo mesmo motivo.

Nenhum programador nasce perfeito, ou mesmo perto. Quanto mais codificar sua escrita, mais críticas você recebe e fornece , o tornará um programador completo.

Uma das melhores coisas para mim em ser desenvolvedor é que todos os dias são um processo de aprendizado. Sempre haverá alguém que não sabe algo que você faz, e sempre haverá alguém que sabe algo que você não sabe. Eu certamente não me consideraria estar em qualquer lugar, exceto no nível básico, mas aprecio qualquer crítica que possa receber desde que seja justificada e dada com respeito.

Uma analogia que pode ser adequada refere-se a um período em que eu era tutor de redação em uma universidade, bem como quando participei de cursos de redação criativa. Escrever código, para todos os efeitos, é como escrever um poema, ensaio, história curta ou romance. Cada indivíduo tem sua própria maneira de fazê-lo, mas, ao mesmo tempo, até os melhores escritores (ou, neste caso, desenvolvedores) cometem erros ou deixam as coisas escaparem das fendas. Muitas vezes, podemos deixar de notar essas coisas porque nos acostumamos à nossa própria voz (ou, nesse caso, ao estilo de código).

Assim como em qualquer campo, existem aqueles que são considerados especialistas. Se essas pessoas não existissem, não teríamos ninguém com quem aprender. Supondo que esse indivíduo em questão seja realmente um especialista, eu ouviria o que ele disse e perguntaria o que ele sugeriria que você fizesse para melhorar seu código. Nunca esqueça, porém, que ele não é o único que pode ajudá-lo; temos a sorte de existir uma infinidade de recursos como SE / SO.

A bagunça é bastante subjetiva. A melhor coisa que você pode fazer é realmente perguntar a essa pessoa (ou ao relatório de revisão): por que está bagunçado? (do ponto de vista deles)

Eles provavelmente responderão e você poderá:

• Argumento contra isso (se você tiver um bom motivo para fazê-lo, é claro)
• Sinta-se muito feliz, porque você acabou de aprender algo novo e seu código futuro será mais impressionante, pois agora você sabe como torná-lo menos confuso, graças aos conselhos deles.

O fato de você estar preocupado é um bom sinal. Vamos começar com isso. Você mencionou que gosta de programar, mas você gosta de ser um programador profissional? Há uma grande diferença entre um entusiasta e um profissional. Como profissional, você estará sob constante escrutínio do seu produto de trabalho.

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

O fato de você ter trabalhado dois anos sem nenhum confronto me diz que você está trabalhando em um emprego muito descontraído, o que não é tão bom se você está realmente querendo avançar como profissional. Lembre-se, alguns dos melhores programadores do mundo trabalham para a fundação Linux e tenham certeza de que eles não são tratados com gentileza quando cometem erros marginais ... muito menos 'código confuso'.

Para uma rápida revisão de algumas diretrizes de codificação bastante padrão, os Padrões de Contribuidores da Comunidade Linux devem fornecer uma idéia do nível de responsabilidade a ser aspirado pelo seu produto. Consulte OBTER O CÓDIGO CERTO.

Para aprofundar essa afirmação, você deve aprender a adotar a revisão, pois a maioria dos bons softwares é completamente revisada. Isso apoia a Lei de Linus, que declara ...

"Se houver revisores suficientes, todos os problemas são fáceis de resolver."

Pessoalmente, eu vi desenvolvedores altamente qualificados, responsáveis ​​e confiáveis ​​pegarem o machado por algo tão simples como esquecer de deixar comentários ... por isso, se alguém lhe disser uma bagunça nos seus códigos, provavelmente será ... Supere isso ... Refatoração. Faz parte do show.

I feel so sad and hurt. 

Vá fazer uma aplicação de tristeza para avaliar como você fica chateado quando não se aplica.

Você respondeu ao seu problema ... Você não testa!

Depois de ver um comentário que você fez afirmando que você é um desenvolvedor java, eu quase fiquei chateada. Portanto, se eu entendi corretamente, você está dizendo que você e sua equipe de desenvolvimento estão trabalhando em uma loja java e não têm uma estrutura de teste para seus aplicativos ...

Aí reside a fricção

"Implementamos nosso programa no programa sem testes completos".

Criador de UML Criador Grady Booch ...

O engenheiro de software amador está sempre em busca de magia, algum método ou ferramenta sensacional cuja aplicação promete tornar trivial o desenvolvimento de software. É a marca do engenheiro de software profissional saber que não existe essa panacéia.

Alistair Cockburn fornece diversas informações em seu site sobre o uso de metodologias ágeis para aumentar o desempenho e a qualidade para você e sua equipe.

Um dos aspectos mais importantes da programação e da vida é conhecer seus pontos fortes e fracos. Se você não trabalhar em suas fraquezas, não terá um conjunto de habilidades completo.

Outro ... Você está indo bem - apenas não lamente. Avance no desenvolvimento de seu ofício e deixe sua paixão pela programação mantê-lo. Boa sorte :-)

Não deixe que suas emoções atrapalhem a melhoria do seu código. O objetivo de uma revisão de código é encontrar problemas, para que você não fique surpreso se houver algum. Dito isto, eles também não deveriam ser uma sessão de quebra de códigos.

Eles também não deveriam estar apenas dizendo 'Ewwww' e deixando assim. Sempre há uma razão pela qual algo está errado na programação. Por exemplo, é errado deixar muitos códigos comentados por todo o lado, mas é errado porque confunde o código e dificulta a leitura, não porque alguém o tenha dito em um livro.

Seu código não é você. Lembre-se disso.

Eu vou ser o idiota aqui e aconselhar com base em ... bem, o óbvio. Obviamente, seu código é uma bagunça ou a pergunta que você está fazendo é "POR QUE alguém está dizendo que meu código está uma bagunça?" Mas você não está desafiando a suposição. Você está apenas agindo ferido e, francamente, pode haver choro, mas não há nenhum sentimento quando se trata de justificar a programação.

Mas sério, por que você está perguntando? Você sabe que seu código é péssimo ou você faria uma pergunta diferente. Se alguém me dissesse que meu código da web fedia, eu ria e dizia "ok, o que há de errado com isso?" Se eles me dissessem que meu JavaScript fedia, eu daria o programador social equivalente a um lábio gordo e nunca pediria conselhos sobre como reagir, porque as putinhas estão claramente!

Possua o que você é bom. E eu realmente quero dizer assumir a responsabilidade por isso. porque é necessário apenas uma piada para que você pense duas vezes. Não peça permissão para ser bom. Apenas conheça suas coisas. O fim.

Lembre-se disso: o pior código que você verá será o seu!

Jeff Atwood, do codinghorror.com, escreveu muito sobre o tópico, você pode querer começar aqui: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Se você quiser melhorar, comece a ler coisas sobre estilo de codificação, padrões, fluxos de trabalho, basicamente tudo o que você pode entender. Aprenda também mais linguagens de programação, veja como elas fazem coisas. Se você estiver fazendo POO, leia o seguinte: http://en.wikipedia.org/wiki/Design_Patterns

Converse também com outros programadores e emparelhe a programação ou assista ao código de outros.

Cometer erros é inevitável, repeti-los é.

Na maioria das vezes, você deve dizer "obrigado" à pessoa que lhe disse isso.

Provavelmente, eles se preocupam com sua profissão, se preocupam com seu trabalho, se preocupam com sua equipe e se preocupam com você.

Pode ser difícil receber críticas. Não fique bravo com isso. Pense no que eles estão tentando lhe dizer e não deixe que suas emoções o superem.

Estou programando há muito tempo (30 anos) e meu estilo e código estão melhorando o tempo todo (espero). A única maneira de saber que está melhorando é quando outras pessoas me dizem ou se eu voltar e revisar meu código.

Tente analisar o código que você escreveu no início de sua carreira. Como você está agora? Parece tão bom quanto você pensava quando o escreveu;)

Primeiro de tudo, você deve entender que a programação é um processo iterativo, como escrever um artigo ou um livro. Primeiro, você escreve um "rascunho" do seu programa, apenas para fazê-lo funcionar. Nesta fase, seu código estará uma bagunça. Então você refatora para tornar o código limpo. Em seguida, você cria um perfil e vê o que precisa otimizar para torná-lo mais rápido. O truque é refatorar continuamente, caso contrário, a bagunça aumentará. Você precisa limpar seu código regularmente, assim como você precisa limpar sua casa.

Revisões de código são absolutamente essenciais. Você deve ter seu código analisado por pelo menos um outro par de olhos. Quando você gasta inúmeras horas olhando para o seu código, você se acostuma e pode facilmente perder um bug ou um cheiro de código que seu colega de trabalho pode perceber instantaneamente.

Além disso, o ato de explicar seu código para outra pessoa é uma ótima maneira de verificar se você perdeu alguma coisa. É como ler um artigo que você está escrevendo em voz alta. Seu cérebro processa informações de áudio e visuais de diferentes maneiras, e você pode encontrar falhas no seu raciocínio trocando de modalidade. Além disso, se você explicar seu código a uma colega de trabalho e algo não fizer sentido para ela, isso é uma boa indicação de que você deve refatorar seu código.

Ao fazer uma revisão de código, é muito importante que o autor e o revisor verifiquem seus egos na porta. O objetivo é melhorar o código. Portanto, o revisor deve ser respeitoso e o autor deve manter a mente aberta. Lembre-se de que seus colegas de trabalho terão que manter seu código, portanto, deve ficar claro para eles. Se o revisor não entender o que uma variável faz, renomeie-a. Se o revisor não conseguir entender o que um bloco de código faz, refatore-o em uma função com um nome descritivo. Independentemente do que você possa pensar, se seus colegas de trabalho não puderem entender seu código, isso não será bom.

Falando em refatoração, é absolutamente necessário ter uma estrutura de teste de unidade, porque sem ela você não pode refatorar.

Finalmente, recomendo a leitura de "Código Limpo", de Robert C. Martin. Ele mostrará por que seu código está uma bagunça e o que você pode fazer para limpá-lo.

Você pode me dar conselhos sobre como melhorar?

A resposta de Jay, que recomenda livros, é boa, mas parece que você já está em um momento de virada no trabalho.

Passado:

Nossa equipe é composta por 5 programadores e 4 de nós somos novos, 1 tem mais de 3 anos de experiência. Estamos trabalhando para um programa há quase um ano e ninguém nunca revisou meu código, e recebi uma página para trabalhar.

Presente:

Agora está apertado e precisamos de uma aprovação e uma revisão do código antes de fazer alterações no código.

Parece que sua empresa / equipe / departamento está aprendendo como um todo, em termos de gerenciamento de projetos e equipes, além de programação. Começar a revisar o código é uma excelente oportunidade para melhorar em praticamente todas as áreas, se receber a devida atenção.

Use isso como uma oportunidade; supondo que você esteja fazendo análises por pares (com os outros desenvolvedores da sua equipe) sugere a eles que esse processo é importante e que todos podem aprender com ele.

Na linha de base, será uma revisão rápida com o resultado "sim, parece bom". Com um esforço um pouco mais concentrado, você pode trocar idéias umas com as outras, "sim, isso funciona, mas você poderia ter abordado dessa maneira, o que tornaria seu objetivo mais claro ...". Faça anotações para o futuro, mesmo se o código for considerado aprovado para implantação.

Se isso for bem-sucedido, você precisa colocar sua equipe e gerente de lado, o que geralmente significa explicar os benefícios para eles. Para os outros desenvolvedores, esta é uma oportunidade para aprender. Para o seu gerente, esta é a oportunidade de aprimorar a equipe com baixo custo, criando, assim, resultados a) com mais valor ou b) mais rápidos c) com menor custo de manutenção (geralmente um grande problema!).

Esta é uma mudança de cultura, pela qual você não pode forçar sozinho, mas pode ajudar a empurrar as coisas na direção certa!

Não se esqueça, esse é um tipo de mudança de cultura que pode ser extremamente benéfica para as organizações; bons gerentes reconhecerão que você está trabalhando para melhorar toda a equipe, algo que vale a pena recompensar.

Você pode me dar conselhos sobre como melhorar? Você já experimentou algo que critica seu código e se sente realmente magoado? O que você faz nesses eventos?

A resposta para isso pode ser encontrada nas empresas de nova geração. Estive em empresas como Google e FaceBook e vejo que, se você seguir o processo Agile / Scrum religiosamente, poderá escrever um código melhor e melhorá-lo a cada sprint.

How to be better? 

A resposta é refatoração contínua. As modernas ferramentas de desenvolvimento, como o visual studio, têm muitas ferramentas que ajudam você nesse processo. Se você seguir o processo de desenvolvimento de software Scrum, digamos que, por exemplo, você escreveu um código incorreto no ciclo 1 do sprint e alguém apontou que durante a revisão é ruim, no sprint 2, você tem a oportunidade de refatorar o código.

Esses problemas estão ocorrendo em primeiro lugar devido à falta de um bom processo. Portanto, a solução é criar um bom processo de desenvolvimento de software para sua equipe e praticar a refatoração contínua.

Agradeço o feedback e, em seguida, peço que expliquem o que o torna ruim e como deve ser melhorado.

Se você concorda que a pessoa que está dando o feedback está fazendo sentido, considere fazer alterações no futuro. Mas lembre-se, só porque alguém diz que isso não significa que seja verdade.

Você pode dar exemplos específicos do que foi chamado de "uma bagunça"?

Primeiro, alguém dizendo que seu código é uma bagunça é muito vago e subjetivo. Pode significar coisas diferentes para pessoas diferentes. Aqui está o porquê; há duas coisas diferentes que precisam ser consideradas.

Estrutura

A estrutura do seu código é regida pelo idioma, pelos padrões do setor e pelos padrões da empresa, para citar alguns. Obviamente, existem outros fatores também.

Esses são os tipos de erros que o fiapo, as ferramentas de teste e os produtos similares foram projetados para identificar. Eles estão bem definidos e você ou suas ferramentas podem tomar decisões objetivas quanto à validade / correção.

Estilo

Apesar da estrutura / regras padronizadas para código, todo desenvolvedor tem um certo estilo na maneira como escreve e aborda um problema ou tarefa. Faça a manutenção do código em qualquer ambiente de equipe e, com o tempo, você poderá adivinhar quem escreveu o código com base no estilo. Você também desenvolverá seu próprio estilo e isso mudará à medida que você ganha experiência e aprende seu ofício.

Portanto, sempre que alguém disser que seu código é uma bagunça, você precisa entender se está falando sobre a estrutura ou o estilo . São duas coisas muito diferentes; a estrutura é objetiva, enquanto o estilo é absolutamente subjetivo.

Dito isto, qualquer feedback construtivo de outros programadores pode ser muito valioso para você. Tudo depende de você e de como você recebe as críticas. Com o tempo, você aprenderá quem é a opinião a ser levada a sério e quem é a pessoa que leva com um grão de sal.

À medida que você progride em sua carreira, analisa seu próprio código e vê coisas que você poderia fazer de maneira diferente, melhor, mais limpa e mais rápida. Tudo faz parte do processo de aprendizagem e ver seus próprios erros do passado é uma indicação verdadeira de que você está aprimorando e aprimorando seu ofício.

Não deixe que um pouco de crítica amortize seu espírito. Pegue o que puder e, se for significativo e valioso, adicione-o à sua loja de conhecimento.

Embora seja importante reconhecer quando o seu próprio código está uma bagunça (sensação muito comum entre os programadores, especialmente à medida que eles se tornam mais experientes e envelhecem), é ainda mais importante ouvir quando outras pessoas dizem isso.

Existem muitos problemas que você pode reconhecer em seu próprio código, pois ele foi produzido com restrições do seu conhecimento atual em programação.

A revisão de código é uma oportunidade essencial de aprendizado, porque provavelmente o expõe a novos conhecimentos que você não possuía enquanto trabalhava no código (caso contrário, você o usaria e não haveria confusão).

Eu acho que existem duas partes no processamento de feedback negativo.

1. Determine a natureza dos problemas levantados e o que você deve aprender com eles

Ao revisar ou revisar meu código, classifico informações sobre problemas de código em aproximadamente esses intervalos:

• viola rígidos requisitos tecnológicos
  • claramente errado (não funciona nem cumpre os requisitos)
  • falhará em outras circunstâncias (alteração de ambiente / configuração)
  • usa funcionalidade obsoleta e interromperá no futuro previsível
• viola as melhores práticas do setor, faltando coisas como
  • usando abordagem comprovada para problema específico
  • desempenho
  • compatibilidade com versões anteriores
  • facilidade de manutenção
  • estilo de codificação
  • documentação
• viola as melhores práticas no local de trabalho
  • igual ao setor, mas mais específico para a empresa / colegas e pode diferir do setor em detalhes
• não está de acordo com a experiência pessoal
  • pode ser melhorado de alguma forma, na opinião de quem revê

Observe que isso varia de coisas muito objetivas ("isso será interrompido quando implantado em nosso servidor de produção") a coisas muito subjetivas ("não gosto de como você nomeou variáveis").

2. Determine quais (se houver) alterações no código serão feitas como resultado da revisão

Depois que as informações são processadas, chega a decisão se elas podem ser acionadas e se o código deve ser alterado. Esta não é necessariamente uma decisão sua, sua opinião pode ou não ser importante, dependendo das partes envolvidas e das especificidades de sua situação (antiguidade, etc.). Mas os possíveis resultados são aproximadamente:

• resolver o problema na íntegra
  • consertar quebrado
  • formato para o estilo de codificação necessário
  • e assim por diante
• comprometer se o problema deve ser tratado total ou parcialmente, pois pode haver
  • sem recursos (como tempo ou orçamento)
  • não é necessário (somente alcançará melhorias insignificantes, comprometerá a estabilidade etc.)
• entender que o problema levantado é inválido
  • o feedback (especialmente da categoria de opinião subjetiva) pode muito bem ser totalmente prejudicial e não deve ser cegado

Você aprendeu que é doloroso receber feedback negativo e pode muito bem ser doloroso todas as vezes no futuro. No entanto, você deixou de aprender como é importante a oportunidade de aprendizado e como o processo ajuda você a melhorar profissionalmente e seu local de trabalho para obter uma melhor base de código.

Bem, não se sinta quebrado. Eventualmente, você aprenderá com os erros. Quando você terminar o problema, poderá conversar com ele, para que ele sinta que deseja melhorar. Tente ouvir mais e discutir menos.

Eu já passei por essa situação e posso entender.

TL; DR

Como você reagiria se alguém lhe dissesse que seu código está uma bagunça?

Meu direto, "por muito tempo não leu (todas as respostas - desculpas, espero encontrar tempo para mais tarde e editar / alterar isso, se necessário)" resposta / dica:

• Boa e velha revisão por pares. Peça a diferentes equipes com diferentes mentalidades coletivas, níveis de conhecimento e / ou níveis de agressividade para revisar seu código.
• Apenas para elaborar um pouco do que quero dizer com "diferentes" grupos de colegas: a diáspora do StackExchange é provavelmente o grupo mais informado, profissional e estimado por causa da relativa dificuldade em se tornar parte dele em comparação com, por exemplo, o Reddit. O Reddit tende a ser muito agressivo nos sub-reddits mais populares - mas estranhamente os subreddits de programação são bastante amigáveis ​​(pelo que experimentei).

Um bom exemplo, talvez o melhor, do tipo agressivo de gangsta de mentalidade de camarilha é a multidão dos Fóruns do XDK e o pior do pior troféu que entrego à população de canais / IRC do CyanogenMod for Android.

Isso foi um pouco mais longo do que eu pretendia; meu ponto de vista deveria ser: obter críticas variadas, mas focar em obter críticas honestas das pessoas que conhecem seu ofício e saber o que são críticas construtivas . Ah, e seja capaz de fazer qualquer forma de crítica sem deixar isso para baixo. Regra geral: se você começar a ouvir comentários semelhantes sobre algo que pode ser mútuo com os comentários, faça uma introspecção mais completa.