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?
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 .)
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)
Você sabe que está escrevendo um bom código quando:
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".
Esta é uma lista mais longa de cheiros de código que também deve ser útil.
Para mim, pessoalmente, acho que é quando esqueço o código. Em outras palavras:
É 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.
Eu tenho três regras de ouro:
Essas regras me guiaram para fazer algumas melhorias reais na arquitetura, acabando com classes / métodos pequenos, limpos e de fácil manutenção.
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?
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.
Eu diria que meus pontos principais seriam:
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?
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.
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:
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.
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:
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)
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.
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.
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.
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 ...
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.
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.
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.
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.
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 ".
Eu uso 5 pontos para saber se o código é bom ou não:
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.
É 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.
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.
Tags code-quality