Eu sou um bom programador, ou assim pensei antes. Eu sempre adoro 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 há quase 2 anos. Então, em suma, tenho quase 3 anos de experiência em programação.
Nossa equipe é composta por 5 programadores e 4 de nós são novos, 1 tem mais de 3 anos de experiência. Estamos trabalhando há quase um ano para um programa e ninguém revisa meu código e eu recebi uma página para trabalhar. Nós nunca tivemos uma revisão de código e somos todos novos, então não sabemos como é um código limpo. Eu acho que os programadores aprendem sozinhos?
Nós implantamos nosso programa no programa sem testes completos. Agora é apertado e precisamos de uma aprovação e revisão de código antes de fazer alterações com o código. Pela primeira vez, alguém revisa 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 que algo assim realmente me magoa. Eu realmente quero me aperfeiçoar. Mas parece que eu não sou um programador genial como nos filmes. Você pode me dar conselhos sobre como ser melhor? Você já experimentou algo que critica seu código e se sente realmente magoado? O que você faz nesses eventos?
A verdade é que, provavelmente, daqui a dois anos, quando você vir seu código atual, você concordará que foi uma bagunça. Aprender programação é um processo sem fim e sempre haverá alguém que é melhor nisso do que você.
Então, se alguém que disse que seu código é uma bagunça não é apenas mesquinho e não é outro caso de doença "Eu faria melhor" comum entre programadores, pergunte a ele o que exatamente está errado com seu código e como você pode melhorar isso?
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 melhorias oferece a você uma oportunidade de demonstrar o quanto você é bom em aprender, em vez de se deparar com críticas sobre o quão ruim é um programador.
Leia o link se você não tem ideia do que estou falando.
Depois de mais de 20 anos, sei que parte do meu próprio código ainda é uma bagunça. O que vem a baixo é tomar uma decisão entre escrever o melhor código possível versus escrever o que é necessário para fazer o trabalho. Realizar o trabalho dentro de um prazo acordado supera a busca incessante pela perfeição técnica em 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 você não vai ficar perfeito desta vez, e provavelmente da próxima vez também, e que é uma escolha deliberada, porque a alternativa não está entregando. E isso é pior.
Aviso: nada disso deve ser lido como "código incorreto é OK".
O código de todo mundo é uma bagunça e não há bons programadores.
Existem:
Eles dificilmente acabam sendo a mesma pessoa.
E existem programadores butthurt que precisam crescer e:
Não é arte, é um ofício.
Nós damos como certo que você é inteligente: você está programando computadores, porra.
Ainda AMD64 e x86 não são compelidos pelo poder de sua prosa. Mantenha as coisas simples.
Bem, uma pessoa dizendo que seu código é uma bagunça não é construtiva, mesmo que esteja certa. Eles te deram razões porque é uma bagunça? Tipo, métodos são muito longos, responsabilidades misturadas, ramificações demais, etc. Honestamente, qualquer código que eu escrevi um ano atrás eu diria que é uma porcaria completa, porque eu aprendi uma tonelada desde então. Então não se sinta mal com 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ódigo, menos tempo você gasta lutando contra o código-base 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ê tenha feito anteriormente no projeto.
No meu projeto atual, refatoramos várias vezes conforme nos sentíamos mais confortáveis com nossa pilha de tecnologia. Isso deve ser incentivado e você deve tomar nota das tarefas que levam mais tempo 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 coisas que você gostaria de fazer de forma diferente agora ou refatorar.
Além disso, quando você menciona a falta de testes, isso é sempre algo para se ver. Em nosso projeto, não tivemos testes automatizados e, como resultado, um código altamente acoplado. Mesmo que você não escreva testes unitários / de integração / quaisquer que sejam os testes regularmente, fazê-lo por algum tempo fará com que você tenha o hábito de tornar seu código mais modular (e, conseqüentemente, menos confuso).
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.
Isso é bom. Isso é um muito melhor do que ter uma reação como "meu revisor não tem idéia do que ele está falando", "meu crítico é muito exigente" ou apenas "meu crítico não gosta de mim" e ignorar eles. Essa atitude é uma coisa boa.
But it seems like I'm not a genius programmer like in the movies.
Não sei em que tipo de filmes você assiste, mas 90% dos programadores nos filmes são tão falsos que eu tenho lágrimas no final da sequência.
Can you give me advise on how to be better?
Leia e pratique. Confira livros como Código Completo ou O Programador Pragmático . Procure na Amazon livros semelhantes.
Have you ever experience something criticizing your code and you feel really hurt? What do you do on those events..
Por que você se sente magoado? Sinto-me desapontado por ser tão idiota em primeiro lugar. Eu uso essa motivação para limpar meu código e certifique-se de não cometer o mesmo erro novamente . A última coisa que eu quero fazer é não aprender com isso. Você foi abatido uma vez, não deixe que isso aconteça novamente pelo mesmo motivo.
Nenhum programador nasce perfeito, ou mesmo perto. Quanto mais código você escreve, mais comentários você recebe e revisa , , fará de você um programador completo.
Uma das melhores coisas para mim em ser um desenvolvedor é que todo dia é um processo de aprendizado. Sempre haverá alguém por aí 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 em qualquer lugar, mas em um nível de entrada / junior, mas eu aprecio qualquer crítica que eu possa obter, contanto que seja justificada e dada com respeito.
Uma analogia que pode ser adequada refere-se a um período de tempo em que eu era um professor 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, conto ou romance. Cada indivíduo tem seu próprio jeito de fazer isso, mas, ao mesmo tempo, até mesmo os melhores escritores (ou, neste caso, os desenvolvedores) cometem erros ou deixam as coisas escaparem. Muitas vezes, podemos deixar de perceber essas coisas porque nos acostumamos tanto a nossa própria voz (ou, novamente, neste caso, 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 diz 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 dar sua ajuda; temos a sorte de existir uma infinidade de recursos, como SE / SO.
Mess é bastante subjetivo. A melhor coisa que você pode fazer é realmente perguntar a essa pessoa (ou o relatório de revisão): por que é confuso? (do ponto de vista deles, isto é)
Eles responderão a você e você poderá:
O fato de você estar preocupado é um bom sinal. Vamos começar com isso. Você menciona que adora programar, mas você ama ser um programador profissional? Há uma grande diferença entre um entusiasta e um profissional. Como profissional, você estará sob constante escrutínio de 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 qualquer confronto me diz que você está trabalhando em um trabalho muito descontraído, o que não é tão bom se você está realmente querendo seguir em frente como profissional. Lembre-se, alguns dos melhores programadores do mundo trabalham para a fundação Linux e têm a certeza de que não são tratados gentilmente quando cometem erros marginais e muito menos código bagunçado.
Para uma revisão rápida de algumas diretrizes de codificação razoavelmente padronizadas, as Normas de Colaboradores da Comunidade Linux deve dar-lhe uma ideia do nível de responsabilidade a aspirar ao seu produto. Consulte COMO COMEÇAR O CÓDIGO DIREITO.
Para promover essa afirmação, você deve aprender a adotar a revisão, pois a maioria dos softwares bons é completamente revisada. Isso é compatível com Lei de Linus informando ...
"If there are enough reviewers, all problems are easy to solve."
Pessoalmente, tenho visto desenvolvedores altamente qualificados, responsáveis e confiáveis obterem o machado por algo tão simples como esquecer de deixar comentários ... então, se alguém lhe disser seus códigos, bagunça, então provavelmente é ... Supere isso ... Refatoração. Faz parte do show.
I feel so sad and hurt.
Faça um aplicativo de tristeza para avaliar o quanto você fica chateado quando não se aplica.
You answered your problem ... You Don't Test!
Depois de ver um comentário que você fez afirmando que é um desenvolvedor java, quase me chateado. Então, se eu entendi corretamente o seu dizer que você e sua equipe de desenvolvimento estão trabalhando em uma loja de java e não tem uma estrutura de teste para seus aplicativos ...
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.
O Alistair Cockburn fornece uma riqueza de 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 strongs e fracos. Se você não trabalhar com seus pontos fracos, não terá um conjunto de habilidades completo.
Outro ... Você está bem - Só não lamente. Avance no desenvolvimento do seu ofício e deixe que sua paixão pela programação o mantenha em movimento. Boa Sorte: -)
Não deixe que suas emoções interfiram no aprimoramento de seu código. O objetivo de uma revisão de código é encontrar problemas, então você não deve se surpreender se houver algum. Dito isto, eles também não devem ser uma sessão de codificadores.
Eles também não deveriam apenas dizer 'Ewwww' e deixar isso assim. Há sempre uma razão pela qual algo está errado na programação. Por exemplo, é errado deixar um monte de código comentado em todo o lugar, mas é errado porque desordena 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ê estaria 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 se machucando e, francamente, pode estar chorando, mas não há nenhum sentimento quando se trata de justificar a programação.
Mas realmente, por que você está perguntando? Você sabe que seu código é uma droga ou você estaria fazendo uma pergunta diferente. Se alguém me dissesse que meu código da web de back-end fedia, eu ria e dizia "ok, o que há de errado com isso?" Se eles me dissessem que meu JavaScript fedia, eu daria a eles o programador social equivalente a um lábio gordo e eu nunca pediria conselhos sobre como reagir, porque as putinhas estão claramente erradas!
Tenha o que você é bom. E eu realmente quero dizer assumir responsabilidade por isso. porque leva apenas uma brincadeira para alguns twit para adivinhar você. Não peça permissão para ser bom. Apenas conheça suas coisas. O fim.
Lembre-se: o pior código que você verá será o seu!
Jeff Atwood do codinghorror.com escreveu muito sobre o assunto, você pode querer começar por aqui: link
Se você quer melhorar, comece a ler coisas sobre estilo de codificação, padrões, fluxos de trabalho, basicamente tudo o que você pode usar. Aprenda também mais linguagens de programação, veja como elas fazem coisas. Se você estiver fazendo OOP, leia isto: link
Converse também com outros programadores e faça programação em pares ou assista a outros códigos.
Cometer erros é inevitável, repetindo-os é.
Na maioria das vezes você deve dizer "obrigado" para a pessoa que lhe disse isso.
As chances são de que eles se preocupam com sua profissão, eles se importam com seu trabalho, eles se preocupam com sua equipe e eles se importam com você.
Pode ser difícil aceitar críticas. Não fique bravo com isso. Pense no que eles estão tentando te dizer e não deixe suas emoções levarem a melhor sobre você.
Eu tenho programado há muito tempo (30 anos) e meu estilo e código estão melhorando o tempo todo (espero). A única maneira que conheço é melhorar quando outras pessoas me dizem ou se eu volto e reviso meu código.
Tente ver o código que você escreveu no início de sua carreira. O que parece para você agora? Parece tão bom quanto você pensou quando você o escreveu;)
As 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ê passa incontáveis 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 possa notar instantaneamente.
Além disso, o ato de explicar seu código para outra pessoa é uma ótima maneira de ver 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 em seu raciocínio ao mudar de modalidade. Além disso, se você explicar seu código a um colega de trabalho e algo não fizer sentido para ele, isso é uma boa indicação de que você deve refatorar seu código.
Ao fazer uma revisão de código, é muito importante que tanto o autor quanto 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 são os que terão que manter seu código, por isso 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, você absolutamente deve ter uma estrutura de teste de unidade, porque sem ela você não pode refatorar.
Por fim, recomendo ler "Clean Code", de Robert C. Martin. Ele dirá por que seu código está uma bagunça e o que você pode fazer para limpá-lo.
Can you give me advise on how to be better?
A resposta de Jay, que recomenda livros, é boa, mas parece que você já está em um ponto de virada no trabalho.
passado:
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.
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 rever o código é uma excelente oportunidade para melhorar em praticamente todas as áreas, se for dada a devida atenção.
Use isso como uma oportunidade; assumindo que você está fazendo revisões de pares (com os outros desenvolvedores de sua equipe), sugira 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 sendo "sim parece ok". 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 isso dessa maneira, o que tornaria sua meta mais clara ...". Tome notas para o futuro, mesmo que o código seja considerado correto para ser implantado.
Se isso for bem-sucedido, você precisa colocar sua equipe e seu 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 melhorar a equipe com pouco custo, criando assim saídas a) com mais valor ou b) mais rápido c) com menos custo de manutenção (geralmente um grande problema!).
Esta é uma mudança de cultura, que você não pode forçar sozinho, mas você pode ajudar a empurrar as coisas na direção certa!
Não se esqueça de que esse tipo de mudança cultural 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 ser recompensado.
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.
A resposta para isso pode ser encontrada nas empresas da nova geração. Eu já estive em empresas como Google e FaceBook e vejo que se você seguir o processo Agile / Scrum religiosamente, então você pode 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, possuem muitas ferramentas que ajudam você nesse processo. Se você seguir o processo de desenvolvimento de software Scrum, então diga por ex, você escreveu um código ruim no ciclo de sprint 1 e alguém apontou durante a revisão que é ruim, então no sprint 2 você tem a oportunidade de refatorar o código.
Esses problemas estão ocorrendo em primeiro lugar devido à falta de bons processos. Portanto, a solução é criar um bom processo de desenvolvimento de software para sua equipe e praticar a refatoração contínua.
Eu gostaria de agradecer pelo feedback e, em seguida, pedir-lhes para explicar o que o torna ruim e como ele deve ser melhorado.
Se você concordar 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 é verdade.
Você pode dar exemplos específicos do que foi chamado de "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 devem ser consideradas.
Estrutura
A estrutura do seu código é governada pela linguagem, pelos padrões do setor e pelos padrões da empresa, para citar alguns. Obviamente, existem outros fatores também.
Estes são os tipos de erros que lint, ferramentas de teste e produtos similares são projetados para identificar. Eles são bem definidos e você ou suas ferramentas podem tomar decisões objetivas quanto à sua validade / correção.
Estilo
Apesar da estrutura / regras padronizadas para o código, todo desenvolvedor tem um certo estilo na maneira de escrever e abordar um problema ou tarefa. Faça manutenção de 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á conforme você ganha experiência e aprende seu ofício.
Assim, sempre que alguém disser que seu código é uma confusão , você precisa entender se eles estão falando sobre a estrutura ou o estilo . São duas coisas muito diferentes; estrutura é objetiva, enquanto estilo é absolutamente subjetiva.
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 levar para o coração do que quem vai levar com um pouco de sal.
À medida que avança na sua carreira, você olha para o 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 abale seus espíritos. 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 é uma bagunça (sentimento muito comum entre os programadores, especialmente à medida que eles se tornam mais experientes e anteriores), é ainda mais importante ouvir quando outras pessoas te avisam.
Existem apenas tantos problemas que você pode reconhecer em seu próprio código, pois foram produzidos com restrições de seu conhecimento atual de programação.
A revisão de código é uma oportunidade de aprendizado essencial, pois provavelmente expõe a novo conhecimento que você não tinha enquanto trabalhava no código (caso contrário, você o usaria e não haveria confusão)
Acho que há duas partes no processamento do feedback negativo.
1. Determine a natureza do problema levantado e o que você deve aprender com ele
Quando reviso ou reviso meu código, classifico informações sobre problemas de código em aproximadamente esses blocos:
Note que isso varia de coisas muito objetivas ("isso vai quebrar quando implantado em nosso servidor de produção") para coisas muito subjetivas ("Eu 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 a informação é processada, chega a decisão se é acionável e se o código deve ser alterado. Esta não é necessariamente a sua decisão, a sua opinião pode ou não ser relevante, dependendo das partes envolvidas e das especificidades da sua situação (antiguidade, etc). Mas os resultados possíveis são aproximadamente:
Você aprendeu que é doloroso receber um feedback negativo e isso pode ser muito doloroso no futuro. No entanto, você deixou de aprender como é importante oportunidade de aprendizagem 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 mal. Eventualmente você aprenderá com os erros. Uma vez que você tenha terminado o problema, você pode falar com o cara para que ele sinta que você quer melhorar. Tente ouvir mais e argumente menos.
Já passei por essa situação e consigo entender.
TL; DR
How would you react if someone told you your code is a mess?
Meu simples ", muito tempo não leu (todas as respostas - desculpas, espero encontrar tempo para mais tarde e editar / corrigir isso, se necessário)" resposta / dica:
Um exemplo bom, talvez o melhor, da mentalidade agressiva de gangsta é a multidão de fóruns do XDK, e o pior do pior troféu que eu entrego ao CyanogenMod para fóruns de Android / população do canal de IRC.
Isso foi um pouco mais longo do que eu pretendia; meu ponto deveria ser - ter opiniões variadas, mas focar em obter críticas honestas das pessoas que conhecem seu ofício, e saber qual é a crítica construtiva . Ah, e seja capaz de aceitar qualquer tipo de crítica sem deixar que você a derrube. Regra de ouro: se você começar a ouvir comentários semelhantes referentes a algo que possa ser mútuo com os comentários, faça uma introspecção mais completa.