Tornar seu código limpo e bonito é uma ótima maneira de cumprir prazos. Robert Martin acertou em cheio com uma de suas declarações concisas: “A única medida verdadeira da qualidade do código é a unidade What-The-F**ks/Minute .” “no original). Deixe-me explicar o que isso significa. Cada vez que reviso o código, meu cérebro passa por uma das três emoções:
“Que merda?! Que diabos?!" (com nojo) - não é isso... está tudo muito ruim....
“Que merda?! Que diabos?!" (com admiração) - hmm, um cara esperto conseguiu!
“Que merda?! Que diabos?!" (com irritação) - algum tipo de confusão, do que estamos falando?!
Então, o que é fundamental e o que exatamente avaliamos quando vemos algum código? É isso: sua pureza e beleza. A capacidade de escrever código limpo e bonito é um indicador de um desenvolvedor altamente profissional. O treinamento nesta habilidade é baseado em dois componentes – conhecimento e trabalho. O conhecimento ensina padrões, princípios, práticas, heurísticas. Você precisa deles para crescer profissionalmente. Somente você deve absorver esse conhecimento como uma esponja, por meio de prática constante e trabalho árduo. Resumindo, escrever código limpo não é fácil. Este é um trabalho árduo e meticuloso, e você terá que trabalhar duro para isso. Por tentativa e erro, você melhorará repetindo as mesmas etapas indefinidamente até encontrar a solução desejada. Simplesmente não existe maneira mais simples. Abaixo estão algumas dicas para ajudá-lo a aprender como escrever código limpo.
O que há em um nome
Kendrick Lamar (artista americano de hip-hop - nota do editor) certa vez observou com precisão: "Se vou contar a história real, tenho que começar com meu nome." Os nomes no desenvolvimento de software estão por toda parte. Nomeamos funções, classes, argumentos, pacotes, programas – tudo. Nomeamos arquivos de origem e livros de referência e tudo relacionado a eles. Nomeamos as coisas infinitamente e isso se torna uma parte crítica do trabalho para a criação de um código limpo. O nome que você dá a algo deve refletir a intenção. Encontrar um bom nome não é fácil, leva tempo, mas também economiza muito tempo quando você tem que lidar com o código e a situação fica complicada. Portanto, tenha cuidado com esse processo e não tenha medo de alterar os nomes posteriormente, caso encontre algo mais adequado. Todos que lidam com seu código ficarão muito gratos a você.
Lembre-se que o nome de qualquer variável, classe, função deve responder a três questões principais: por que ela (variável, função, etc.) existe, o que faz e para que serve.
Isto requer não apenas boas habilidades descritivas, mas também erudição geral e uma visão ampla. E ninguém pode lhe ensinar isso melhor do que você mesmo.
“Uma função” - uma coisa
Louis Henry Sullivan (arquiteto racionalista e modernista americano) disse certa vez: “a função determina a forma ” . Ele disse isso sobre a arquitetura das casas, mas isso não muda a essência. Cada sistema é construído em alguma linguagem específica de domínio que os programadores criam para descrevê-lo com precisão. As funções atuam como verbos da linguagem e as classes são substantivos. Na maioria das vezes, as funções são fundamentais na organização de uma linguagem de programação, e escrevê-las corretamente é a essência da criação de um bom código. Existem apenas duas regras de ouro para escrever funções de qualidade:
Eles deveriam ser pequenos
Eles devem fazer uma coisa, uma tarefa, e fazê-la bem
Ou seja, sua função deve ser pequena e não conter estruturas aninhadas. Assim, os níveis de recuo da função não devem ser superiores a um ou dois. Essa abordagem torna o código muito mais fácil de ler, entender e compreender. Além disso, devemos ter certeza de que as expressões dentro da função estão no mesmo nível de abstração. Misturar níveis de abstração dentro de uma função sempre cria muita confusão e eventualmente leva a um código incontrolável. Os melhores programadores tratam as funções como histórias a serem contadas, não apenas como códigos para escrever. Eles usam as ferramentas da linguagem de programação escolhida para criar um bloco de código rico, expressivo e mais limpo que pode essencialmente atuar como um grande contador de histórias.
“Comentários não compensam códigos ruins”
Venus Williams, tenista americana e pentacampeã de Wimbledon, acertou em cheio ao dizer: “Todo mundo deixa seus comentários. É assim que os rumores aparecem . ” Os comentários são como uma faca de dois gumes. Um comentário bem colocado é algo muito útil. Por outro lado, nada ocupa mais espaço do que comentários frívolos e inúteis. Mas os comentários mais prejudiciais são aqueles que espalham desinformação e mentiras. Em suma, os comentários são uma espécie de mal necessário. Nem sempre, mas na maior parte. Por que? É simples: quanto mais antigo o comentário, mais difícil é mantê-lo, e a maioria dos programadores, como você sabe, nem sempre altera os comentários junto com as alterações no código. O código se move e evolui. Partes do código são movidas para frente e para trás, mas não há comentários. E isso se torna um problema!
Lembre-se: código limpo e claro com poucos comentários é muito melhor do que código complexo e desordenado. Não desperdice sua energia explicando o caos que você criou nos comentários. Melhor gastar esse tempo limpando essa bagunça.
“A formatação do código é sempre uma prioridade”
Isto foi dito por ninguém menos que Robert C. Martin (Robert Cecil Martin), também conhecido como Tio Bob, desenvolvedor, autor de vários livros sobre desenvolvimento de software, consultor, coautor do manifesto Agile e assim por diante. E acrescentou: “Formatar código é uma espécie de comunicação. E a comunicação é uma prioridade máxima para qualquer desenvolvedor profissional.” A afirmação acima não deve ser subestimada, pois fala de uma das características mais importantes de um excelente desenvolvedor. O código formatado permite que você olhe profundamente em sua mente. Queremos impressionar as pessoas com a nossa limpeza, atenção aos detalhes, capacidade de organizar e expressar os nossos pensamentos com clareza. Mas se, ao olhar o código, as pessoas virem algum tipo de confusão, que lembra um vinagrete, sem começo nem fim, isso anula seus esforços e diminui a reputação do desenvolvedor. Nem duvide! Você está muito longe da verdade se pensa que o principal neste negócio é que “o código simplesmente funciona”. A funcionalidade que você cria hoje provavelmente será alterada na próxima versão, mas a legibilidade do código não mudará. O estilo do código e sua boa legibilidade facilitam a manutenção do código por um longo tempo, mesmo depois que o código original foi alterado de forma irreconhecível.
Nunca se esqueça que no futuro o que provavelmente será lembrado não será o seu código em si, mas sim o seu estilo e consistência. Portanto, certifique-se de que o código esteja bem formatado e siga regras simples e compreensíveis para todos os membros da equipe.
Primeiro crie um bloco "try-catch-finally"
Georges Canguilhem (historiador da ciência, filósofo) observou com razão: “Cometer erros é natural para uma pessoa, mas insistir nos erros é do diabo . ” A solução de problemas é algo que todos os programadores fazem. Dados inválidos podem entrar na entrada e os dispositivos podem falhar. E como desenvolvedores, precisamos ter certeza de que o código faz o que deveria. A questão não é apenas o tratamento de erros, mas o tratamento de erros “limpo e fácil de ler”. Muitos programas se adaptam ao tratamento de erros. Se você fizer isso, tudo se tornará um caos tal que o propósito e a lógica do código principal serão destruídos. Isso está errado, não deveria ser assim. O código deve ser limpo e confiável, e o tratamento de erros deve ser integrado de maneira contínua e natural ao código. Este é um indicador de um programador de alta classe. E uma das maneiras de conseguir isso é através do aninhamento adequado e da cobertura de todos os erros nos blocos try-catch. Esses blocos definem o escopo do seu código. Ao executar o código na parte try de um bloco try-catch-finally, você está afirmando que a execução pode ser abortada a qualquer momento e então retomada em um catch. Portanto, recomendamos começar com try-catch-finally ao escrever código. Isso ajudará a determinar o que o usuário pode esperar do código, independentemente do que der errado com o código durante a tentativa.
Lembre-se sempre de que cada exceção lançada deve conter contexto suficiente para determinar a localização e a origem do erro. Mensagens de erro criativas e informativas são lembradas muito depois de o código ser escrito, mesmo quando o programador já está ocupado com tarefas completamente diferentes.
Vamos resumir
Uma frase incomum nos ajudará a resumir todos os itens acima. Este é o senso de código ou “um senso de código comum”, uma espécie de programador equivalente ao bom senso. Nas palavras de Robert Martin: “Escrever código limpo requer o uso sistemático de muitas pequenas técnicas, aplicadas como resultado de uma sensação meticulosa e um tanto dolorosa de “limpeza”. Essas pequenas técnicas são chamadas coletivamente de sentido de código . ” Alguns de nós têm esse “senso de código sonoro” desde o início, enquanto outros precisam desenvolvê-lo por meio de prática persistente. Esse instinto ajuda não apenas a reconhecer a diferença entre códigos ruins e bons, mas também auxilia na formação de estratégias que visam transformar códigos ruins em bons. Código ruim estraga tudo. Falando figurativamente, se você cobrir o bolo mais delicioso com cocô de cachorro, então... uh... dificilmente alguém vai gostar. O senso de código ajuda um programador a usar as ferramentas certas para atingir seu objetivo de criar código limpo. Um programador que entende o que é o sentido do código é um artista que pode criar uma obra de arte em uma tela em branco que será lembrada por muitos anos. Como Harold “Hal” Abelson, professor de ciência da computação no Mit e diretor fundador da Creative Commons e da Free Software Foundation, resumiu: “Os programas precisam ser escritos primeiro para que as pessoas possam lê-los e depois para que possam ser executado." carro" . O que você pode ler sobre o tema: “Um manual de Agile Software Craftsmanship” - Robert Martin. “Um manual de estimativa ágil” - Mike Cohn Sobre o autor: Ravi Shankar Rajan é gerente global de programas de TI de Mumbai (Índia). Blogueiro famoso, poeta de haicai, ávido arqueólogo e fã de história. Você pode se conectar com ele no Twitter , Médio , LinkedIn
GO TO FULL VERSION