Como você sabe que está escrevendo um bom código? [duplicado]

267

Eu amo programar. Eu tenho brincado com código desde que eu era criança. Eu nunca fui a rota profissional, mas eu codifiquei vários aplicativos internos para vários empregadores, incluindo um projeto em que eu construí um sistema interno de gerenciamento de transações / relatórios para um banco. Eu pego as coisas rapidamente, entendo muitos conceitos e me sinto à vontade com todo o processo de codificação.

Tudo dito, sinto que nunca sei se meus programas são bons. Claro, eles funcionam - mas o código é limpo, firme e bem escrito, ou outro programador olharia para ele e me dava um tapa na cabeça? Eu vejo algumas coisas no Stack Overflow que apenas me surpreendem e fazem com que minhas tentativas de codificação pareçam completamente fracas. Meus empregadores ficaram felizes com o que eu fiz, mas sem revisão por pares, eu estou no escuro de outra forma.

Eu analisei a revisão de código, mas muitas coisas não podem ser postadas por causa de NDAs ou questões de confidencialidade. Muitos de vocês, profissionais, podem ter companheiros de equipe para olhar as coisas por cima do seu ombro ou trocar idéias com elas, mas e os caras independentes e solos por aí como eu? Como você aprende as melhores práticas e certifica-se de que seu código está bom?

Ou não importa se é "o melhor", desde que seja executado conforme o esperado e forneça uma boa experiência ao usuário?

    
por 6 revs, 5 users 50%Jim 14.11.2015 / 16:32
fonte

25 respostas

328

A maior pista para mim é:

Quando você precisa voltar e adicionar / modificar um recurso, é difícil? Você constantemente quebra a funcionalidade existente ao fazer alterações?

Se a resposta acima for "sim", provavelmente você tem um design geral ruim.

É (pelo menos para mim) um pouco difícil julgar um design até que seja necessário responder à mudança (dentro da razão, claro; algum código é ruim e você pode dizer imediatamente, mas mesmo isso vem com experiência .)

    
por 25.03.2011 / 02:35
fonte
177

Esta é certamente uma medida bastante normal em que trabalho.

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks...

(Robert C Martin, Código Limpo - livro que abre com a foto acima)

    
por 23.09.2013 / 10:03
fonte
103

Você sabe que está escrevendo um bom código quando:

  • As coisas são inteligentes, mas não muito inteligentes
  • Algoritmos são ótimos, tanto em velocidade quanto em legibilidade
  • Classes, variáveis e funções são bem nomeadas e fazem sentido sem ter que pensar muito
  • Você volta depois de um final de semana de folga e pode pular direto para
  • As coisas que serão reutilizadas são reutilizáveis
  • Testes de unidade são fáceis de escrever
por 24.03.2011 / 22:18
fonte
59

Embora você tenha dito que não tem outros programadores para fazer isso, incluirei isso para o bem dos outros.

O teste de qualidade de código: Ter outro programador que nunca viu o código ler e explicar o que cada módulo faz a você enquanto você olha por cima do ombro. Quanto mais strong for sua vontade de pular e explicar algo, pior é o código. Se você pode sentar calmamente de boca fechada e não precisar fazer muitas perguntas, provavelmente é bom.

Para seu benefício, aqui estão algumas diretrizes gerais para quando você não tem um colega à mão. Eles não são absolutos, apenas "cheiros".

Bons sinais

  • Os métodos tendem a ser muito curtos e idealmente realizam uma única tarefa.
  • Você tem informações suficientes para chamar métodos sem olhar para o corpo deles.
  • Testes de unidade são fáceis de escrever.

Sinais ruins

  • Métodos longos compostos de 2 a sub-tarefas que não são divididos em outros métodos.
  • Métodos compartilham dados por meio de outros meios que não sua interface.
  • Se você alterar a implementação de um método (mas não a interface), precisará alterar a implementação de outros métodos.
  • Muitos comentários, especialmente comentários longos.
  • Você tem um código que nunca é executado em seu aplicativo para fornecer "flexibilidade futura"
  • Grandes blocos try / catch
  • Você está com dificuldades para criar bons nomes de métodos ou eles contêm as palavras "OR" e "AND" (por exemplo, GetInvoiceOrCustomer)
  • Blocos de código idênticos ou quase idênticos.

Esta é uma lista mais longa de cheiros de código que também deve ser útil.

    
por 25.03.2011 / 17:38
fonte
27

Para mim, pessoalmente, acho que é quando esqueço o código. Em outras palavras:

  • Bugs raramente ocorrem
  • Quando ocorrem, outras pessoas resolvem-nas sem me perguntar nada
  • Ainda mais importante, ninguém ever me pergunta nada sobre o meu código
  • As pessoas não têm uma taxa alta de WTF / min ao lê-lo
  • Muitas novas classes no sistema começam a usar minha classe ( alta fan-in , como Steve McConnell chamaria)
  • O código é fácil de modificar e / ou refatorar quando / se necessário, sem me amaldiçoar (mesmo que seja eu - amaldiçoando a mim mesmo!)
  • Eu também adoro quando acho que a quantidade certa de abstração parece se adequar a todos na equipe

É uma sensação boa quando você abre um arquivo que você escreveu há um ano e vê todas as boas adições para uma classe, mas muito poucas modificações , e - fan-in muito alto! :)

Naturalmente, essas são as coisas que fazem mim sentir que estou escrevendo um bom código, mas, na realidade, é realmente difícil de saber. Meu palpite é que, se as pessoas começarem a tirar sarro do seu código mais do que elas estão tirando sarro de você, é hora de se preocupar.

    
por 24.03.2011 / 23:15
fonte
20

Eu tenho três regras de ouro:

  1. Se eu me sentir compelido a copiar / colar blocos de código, estou fazendo algo errado
  2. Se eu não posso pegar todo o código na minha cabeça, estou fazendo algo errado
  3. Se alguém entrar e se perder no meu código, estou fazendo algo errado

Essas regras me guiaram para fazer algumas melhorias reais na arquitetura, acabando com classes / métodos pequenos, limpos e de fácil manutenção.

    
por 03.04.2011 / 18:38
fonte
11

Esta é uma excelente pergunta, e eu aplaudo por até mesmo perguntar.

Primeiro, é bom deixar sua mente explodir de vez em quando. Mantém você humilde, faz com que você perceba que você não sabe tudo, que há pessoas melhores que você em você, e lhe dá algo melhor para se esforçar.

Agora, como você sabe quando está escrevendo um bom código?

  • Quando suas aulas têm um propósito único e muito claramente definido, separadas de outras classes com outros propósitos claramente definidos.
  • Quando seus métodos são curtos - idealmente abaixo de 50 linhas e certamente abaixo de 100 - e seus nomes definem claramente o que eles fazem exatamente . Um método não deve fazer nada além do que o nome implica. Se você está indo mais de 100 linhas, ou tabulado em muito longe, você provavelmente pode puxar algo para fora em sua própria função.
  • Quando seu código fornece uma maneira de fazer alguma coisa - quando não oferece a opção de zigar ou zagar, mas fornece um único caminho linear para cada curso de ação possível, o usuário pode enviá-lo para baixo.
  • Quando você fizer tudo o que puder razoavelmente para reduzir o acoplamento entre classes; de modo que, se a Classe A depende da Classe B, e a Classe B é removida e a Classe C é colocada em seu lugar, pouca ou nenhuma mudança deve ser feita na Classe A. A Classe A deve ser o mais cega possível para o que está acontecendo no mundo exterior.
  • Quando seus nomes de classe, método e variável podem ser lidos e imediatamente entendidos por qualquer um que se deparar com o código - não há necessidade de 'pktSize' quando 'packetSize' for muito mais fácil.

Como outros já disseram, essencialmente, se você está fazendo Programação Orientada a Objetos, e quando chega a hora de mudar algo, você acha que é como tentar desvendar e rebobinar uma bola de lã, o código não está seguindo o bom objeto. Princípios orientados.

Eu recomendo o livro "Código limpo" se você estiver interessado em explorar um pouco mais isto. É uma boa leitura para novatos e especialistas.

    
por 25.03.2011 / 04:04
fonte
7

Eu diria que meus pontos principais seriam:

  • Legibilidade (para você e qualquer outra pessoa que tenha analisado seu código)
  • Manutenção (fácil de modificar)
  • Simplicidade (não complicar as coisas quando não há necessidade disso)
  • Eficiência (obviamente seu código deve ser executado rapidamente)
  • Clareza (se o seu código for autoexplicativo, não há necessidade de comentários na maioria das vezes, nomeie seus métodos / propriedades etc. sensatamente, divida o código longo, nunca copie & cole um bloco de código)

Não estou colocando o Design nesta lista, pois acredito que um bom código pode ser escrito sem se ater a um padrão de design, desde que seja consistente em seu projeto.

Bom artigo do MSDN sobre este tópico: O que torna o bom código bom?

    
por 25.03.2011 / 11:40
fonte
6

Procure um bom projeto de código aberto em seu idioma favorito e veja o que ele faz.

Por exemplo, sendmail é um lugar para ver se você escreve código de espaguete . Não é realmente culpa do sendmail; tem apenas 20 anos, então tem muita coisa. Então, se o seu código se parece com o código do sendmail, você provavelmente está no caminho errado.

Eu não olhei para o Postfix ultimamente, mas provavelmente é muito bem desenhado. Então, se suas coisas parecem mais com o postfix, você está no caminho certo.

Quando comecei a programar quando criança não havia Internet e você não tinha nada para comparar. Mas agora com um bazilhão de linhas de código disponíveis para visualização para comparação, você deve começar a ter uma ideia se estiver fazendo certo ou não.

E só porque o kernel do Linux é o kernel do Linux não significa que esteja bem escrito. Tenha isso em mente.

    
por 26.03.2015 / 12:12
fonte
6

Esta tem sido minha experiência desde a mudança do mundo universitário da programação para a indústria nos últimos cinco meses:

  • A facilidade de uso é tão importante que pagamos às pessoas apenas para projetar Interfaces de usuário. Os codificadores costumam chupar o design da interface do usuário.
  • Você descobre que o trabalho não é suficiente
  • As otimizações se tornam mais críticas em cenários do mundo real.
  • Existem mil maneiras de abordar um problema. No entanto, muitas vezes, a abordagem não leva em conta fatores levemente menos conhecidos que podem afetar adversamente o desempenho de sua abordagem, como a autenticação de banco de dados, transações, arquivo E / S , reflexão, só para nomear alguns aleatórios.
  • A manutenção é um aspecto muito importante da codificação. Só porque o seu código é super otimizado e super denso ... não significa que seja sexy. Às vezes é simplesmente rotulado como "codificação de herói".
  • Habilidades de design são aprendidas, não inerentes. Tenho certeza de que há algumas crianças intelectuais por aí, mas, de modo geral, o design sólido com relação aos problemas do mundo real é trabalhado no tempo, na investigação e, mais importante, na transmissão de conhecimento de seus superiores = P
  • Documentação não é uma conveniência, é uma necessidade.
  • O mesmo vale para os testes unitários (isso varia de empresa para empresa reconhecidamente)

Sugiro que você aproveite uma oportunidade com um projeto de código aberto. Você terá a chance de ver o quanto você realmente sabe se você trabalha lado a lado com outros programadores. Um projeto de código aberto é provavelmente a melhor maneira de descobrir com base no seu histórico.

    
por 26.03.2015 / 12:14
fonte
2

Quando você pode lê-lo como prosa.

    
por 25.03.2011 / 00:15
fonte
2

Do ponto de vista de código e design, gosto do que os outros já disseram sobre manutenibilidade.

Além disso, também olho para a estabilidade. Veja as estatísticas de suporte de produção. Se você está recebendo uma alta instância de correspondência de suporte para coisas que parecem uma funcionalidade fundamental, mas está descobrindo que muitas pessoas não conseguem entender como usar o software ou estão descobrindo que ele não atende às suas necessidades, então há algo errado.

Naturalmente, há alguns usuários que realmente não têm clareza, mas se, com o tempo, você ainda estiver recebendo denúncias de quebras, confusão ou solicitações significativas de mudança de recursos, isso é uma indicação de que um ou todos os itens a seguir se aplicam:

  • Os requisitos foram quebrados
  • O código está quebrado
  • O aplicativo não é intuitivo
  • O desenvolvedor não entendeu a necessidade do usuário
  • Alguém empurrou a data de entrega para a qualidade
  • Alguém não testou bem ou sabe o que testar para
por 25.03.2011 / 02:20
fonte
2

Leia o código bom e descubra porque é bom. Leia o código errado e descubra por que ele é ruim. Leia o código medíocre e descubra quais partes são boas, quais são ruins e quais são aceitáveis. Leia seu próprio código e faça o mesmo. Pegue um par de livros didáticos (bem conceituados) especificamente com o objetivo de examinar os exemplos e entender por que eles os escreveram da maneira que fizeram. Principalmente, leia o código até que você possa dizer a diferença entre ruim e bom, e pode fazer o seu próprio "Wtf". testes.

Você não pode saber se está escrevendo um bom código até reconhecer um bom código em geral. Só porque algo está acima da sua cabeça não significa que está bem escrito ...

("Leia o código de outras pessoas" apareceu em alguns comentários sobre este tópico, mas achei que merecia seu próprio post)

    
por 25.03.2011 / 16:46
fonte
2

Peça a alguém para assumir o seu trabalho por um dia e verificar o quanto ele está estressado no final do dia; -)

Eu sou ruim em documentar e limpar coisas - então é assim que eu verifico.

    
por 26.03.2015 / 12:09
fonte
1

That all being said, I feel like I never know if my programs are any good. Sure, they work - but is the code clean, tight, well-written stuff, or would another coder look at it and slap me in the head?

Já considerou perguntar ao outro codificador o que eles acham do seu código?

Alguns lugares usam "peer review", onde o código deve ser aceitável para outro codificador antes de ser aceito no repositório de código.

    
por 25.03.2011 / 07:21
fonte
1

IMHO, não há "código bom" por si só, mas há "bom pedaço de software".

Quando estamos trabalhando em algo, há muitas restrições em nosso trabalho, o que muitas vezes nos faria produzir o código que cai fora do padrão de "bom código" de outros programadores.

Alguns podem dizer que "código bom" é o código que é fácil de manter. O contra-argumento para essa declaração para mim é: como é fácil? Precisamos colocar um esforço de 200% na parte do código para torná-lo tão fácil de manter em prol do padrão "bom código", mesmo sabendo que não precisaremos mantê-lo tanto assim? Me desculpe, mas eu não penso assim.

Na verdade, sou eu quem realmente promove o "bom código" na minha equipe que ninguém realmente se importa com isso. Toda vez que olho para os códigos deles, nunca descobri que eles escrevem qualquer código perfeito. No entanto, devo aceitar que eles realmente fizeram o trabalho e também podem mantê-lo adequadamente para as necessidades de nossa empresa. É claro que o aplicativo às vezes é problemático, mas acabamos de chegar a tempo, deixando nossos clientes e usuários satisfeitos e garantindo que nossa empresa esteja muito à frente de nossos concorrentes.

Então, eu diria que "código bom" é o código que produz o que você precisa. Você só precisa pensar no que realmente precisa e usá-lo para avaliar seu código.

    
por 26.03.2011 / 07:44
fonte
1

O bom código é subjetivo para a pessoa. Um programador profissional que tenha lido muitos livros e participado de seminários e usado técnicas diferentes de codificação provavelmente rasgaria seu código em pedaços ... No entanto, descobri que o código é realmente indicativo de onde está o nível de experiência dos codificadores. Para mim, lê-se como um livro de história ou uma autobiografia. É o que o programador sabia na época ou a quais ferramentas ele estava limitado.

Pergunte a si mesmo ... Por que a Microsoft usa três versões de software para obter algo certo? Porque eles estão constantemente consertando os erros que fizeram nas versões anteriores. Eu sei que meu código sempre fica melhor e melhor depois de uma revisão. Claro que haverá pessoas aqui que dizem, eu escrevo código perfeito na primeira vez. Se você acredita nisso, então eu tenho um terreno pantanoso para te vender ...

Conforme você entende os conceitos, as coisas ficam mais fáceis. Para mim, o começo de aprender algo novo é "posso fazê-lo funcionar?", Então o próximo passo é "Eu me pergunto se eu posso fazer isso dessa maneira ...", então geralmente quando eu acertei eu pergunto "como posso fazer isso mais rápido" ...

Se você quer ser um programador, então você tem que mergulhar nele e apenas fazê-lo. É preciso muito trabalho e, para ser honesto, é como uma obra de arte que nunca pode ser concluída. No entanto, se você quer ser apenas um amador casual, então se ele funcionar, não se preocupe. Você tem que se adaptar ao seu entorno. Se você não tem uma maneira de fazer revisões de código, então a ignorância é bliss =)

Mas não importa o que ... Todo mundo vai ter sua própria opinião. Claro que existem maneiras corretas e maneiras erradas de fazer as coisas ... Mas, na maioria das vezes, descobri que existem modos basicamente melhores de fazer as coisas do que maneiras erradas ...

    
por 27.03.2011 / 17:09
fonte
1

Para uma parte específica do código:

Se funcionar e for sustentável (escolha suas boas práticas), é um bom código.

Para você como desenvolvedor ao longo do tempo:

Bom é um termo relativo e dinâmico, para o domínio da linguagem, o domínio do problema, as tendências atuais e, mais importante, a sua experiência. O teste ácido "GOOD" para este continuum pode ser simplesmente um retrospecto do seu trabalho anterior e se você disser " suspirar eu realmente resolvi assim?" então as chances são de que você ainda está crescendo e provavelmente continuará escrevendo um bom código.

Se você olhar para trás e ver o código perfeito, então - você é perfeito, e há um risco de estagnar e você pode em breve deixar de escrever um bom código.

    
por 26.03.2015 / 12:23
fonte
0

Libere seu código, deixe algumas pessoas mexerem nele para ter certeza de que ele faz o que é esperado. Ou, se desejar, crie uma especificação e verifique se ela atende a todas essas especificações. Se você passar por um ou ambos os testes, seu código será "bom agora". Para a maioria das pessoas, seu código nunca será ótimo, porque você voltará em um ano e dirá "Por que eu fiz isso quando ele teria funcionado muito melhor isso caminho? "

Com mais experiência, você obtém um código melhor. Mas se você pratica continuamente os mesmos hábitos, você cairá continuamente nas mesmas armadilhas. É apenas um simples exame de um velho ditado de "Prática torna permanente ". Se você continuamente faz as coisas da maneira correta (como testar seu código para sempre se certificar de que funciona para o que é suposto fazer), então você vai ficar melhor. Se você fizer as coisas de maneira errada (como nunca testar seu código para determinadas situações ou não reconhecer onde erros podem ocorrer), você ficará teimoso com seu código.

    
por 24.03.2011 / 22:16
fonte
0

Nada é melhor que alguém experiente analise seu código, mas existem alguns recursos para ajudá-lo a avaliar e melhorar seu código por conta própria. Dê uma olhada na Refatoração de Martin Fowler (ou site ). Os Padrões de Codificação C ++ de Sutter e Alexandrescu são bons se você estiver escrevendo em C ++. Muitas das recomendações são agnósticas, mas outras podem recomendar livros semelhantes para outros idiomas. O desenvolvimento orientado a testes pode ser muito útil para desenvolvedores solo, pois fornece uma espécie de verificação de qualidade e você sabe que, quando os testes se tornam difíceis de escrever, isso significa que seu código provavelmente poderia usar a reestruturação.

Alguns outros sinais são mais orientados para o processo. Eles geralmente levam a um código melhor, mas não diretamente. Isso inclui coisas como o uso do controle de código-fonte, um processo de criação automatizado, não o desenvolvimento direto no servidor ao vivo, o uso de software de rastreamento de bugs, etc.

    
por 25.03.2011 / 01:47
fonte
0

Você pode usar a ferramenta de análise de código, como FindBugs , PMD . Isso fornecerá algumas informações sobre a qualidade do seu código.

    
por 25.03.2011 / 08:59
fonte
0

No esforço de codificar bem, pretendo garantir que o programa seja altamente funcional e rápido. Certifique-se de que tudo esteja em um local adequado para que o arquivo, os dados, a função e as abstrações sejam bastante óbvios.

Após este ponto, eu o coloco em teste: encontre uma pessoa razoavelmente não-versada em computadores em geral, tente explicar alguns dos principais padrões de código. Se eles podem meio que ler, uau. Bom trabalho.

Principalmente apenas KISS e tente ser inovador sem deixar nada de lado. Eu também faria mais anotações sobre voltar ao código e ter um bom tempo melhorando e mantendo-o, mas isso foi muito bem tratado.

    
por 11.08.2011 / 23:52
fonte
0

nunca.

"Bom código" é apenas um código para o qual nenhuma forma de melhoria foi encontrada ainda. Como Jeff Atwood disse :

There are a handful of programmers in the world capable of producing brilliant, perfect code. All the rest of us can do is keep making our software less shitty over time-- a process of continuous improvement

E, a propósito, você não precisa atingir a perfeição, porque às vezes, " Design Suficiente significa design pobre ".

    
por 26.03.2015 / 12:21
fonte
-1

Eu uso 5 pontos para saber se o código é bom ou não:

    Os nomes de procedimentos, métodos e classes
  • são muito úteis e ainda assim me dizem o que fazem.
  • comentando qualquer inclusão causa falha na execução
  • olhando o código depois de um mês, posso acompanhar o fluxo
  • O código
  • é compilado e executado corretamente.
  • O programa
  • executa as ações pretendidas e apenas as ações pretendidas.

Para mim, GetCustIDFromDB (var & ast; DB, char & ast; customer) é melhor que getcid porque me diz para o que estou olhando. Mas * DBLookupCIDByName (var & ast; DB, char & ast; customer) também funciona.

Eu freqüentemente testo para ver se eu realmente ainda uso todos os meus #includes ... Se eu posso removê-lo, ótimo. Às vezes, é possível examinar seus cabeçalhos incluídos e ver se as funções necessárias estão realmente em algo que o cabeçalho inclui via #include ... mas eu só fiz isso raramente, e economiza um pouco de espaço também, tho 'isso pode tornar o processo de adicionar novos recursos muito mais difícil.

    
por 26.03.2011 / 00:20
fonte
-1

É uma coisa difícil de dizer. Há sempre uma questão de levar mais tempo para fazer o certo, ou levar menos tempo e fazê-lo mais cedo para que você possa trabalhar em outras coisas.

link

Voltei e olhei para o código que fiz há alguns anos, e acho que parece horrível. Estamos constantemente aprendendo neste campo, e a melhor maneira de codificar corretamente é olhar para os exemplos de outras pessoas e aprender com elas. Depois de aprender algo novo, compartilhe-o com outras pessoas para que todos possam se beneficiar dele.

    
por 26.03.2015 / 12:20
fonte