As primeiras afirmações citadas no livro, me fez dar continuidade na minha leitura, e acredito que o fato de você ter clicado no link e está lendo esse post devem ser por esses dois motivos:
- Há duas razões pelas quais você está lendo esse livro:
1- Você é um programador;
2 - Você deseja se tornar um programador melhor;
Se realmente forem esses os motivos por você está aqui, continue lendo esse post. 😅
Uma breve bibliografia do Robert Martin:
Robert C Martin, mais conhecido como Uncle Bob, é um profisional de software desde 1970, e consultor internacional desde 1990. Desde 70's ele já trabalhou em centenas de projetos. E em 2001, ele deu inicio a manifesto ágil, a partir das técnicas de programação Extreme. Ele também é membro do World Software Craftsmanship Movement - Clean Code. Ele já escreveu vários livros como: Programação Agile, Programação Extrema, UML, Programação Orientada a Objetos, Programação C ++.
A razão por me basear neste livro, é porque durante a leitura, ele não fala sobre o que pode ser feito, dando recomendações, mas o que ele fez, comprovando que obteve sucesso.
O que é Clean code (código limpo)?
- É ser eficiente;
- Simples;
- Direto ao ponto;
- Mínimas dependências;
- Sem duplicação;
- Fácil manutenção;
- Padrões definidos;
- Fácil leitura e entendimento;
- Ser coberto por testes;
- Elegante.
Deixo um link para você entender que essa síndrome, tem tudo a ver com o assunto.
(http://justificando.cartacapital.com.br/2015/05/26/a-desordem-gera-desordem-conheca-a-teoria-das-janelas-quebradas/)
"Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos entendem".
Martin Fowler.
Muitas vezes, não temos muito tempo para desenvolvermos uma feature, por n motivos, que já foram citados no meu post anterior falando sobre testes. (http://devhiranneri.blogspot.com.br/2017/06/testes-uma-pratica-necessaria.html)
Quando nós desenvolvemos um código ruim, feio, a nossa primeira intenção é tirar a culpa. Mas afinal, de quem é a culpa?
NOSSA!
OK, Agora que já entendemos o que é um código limpo, como eu consigo mensurar a qualidade de um código? Como eu consigo atingir os requisitos de um código limpo citados acima?
É isso que veremos agora, que são alguns capítulos abordados pelo livro.
1 - Os nomes
Uma prática muito comum no desenvolvimento é querer simplificar o nome das variáveis, funções, nome de arquivos e etc. E isso uma má prática, pois somente você, ou no máximo a equipe de desenvolvimento saberá o que ela é, para o que serve. Caso entre novos(as) devs. na equipe, será um retrabalho para passar o todo o contexto, todos os significados do que pode ser aquela variável e etc. (que deveria ser simples, já que está se contratando um dev.).
Então use nomes que expressam alguma intenção:
int d;
int distanciaPecorridaEmKM;
A primeira variável (d), não consigo saber o real sentido dela, já a segunda (distanciaPecorridaEmKM), fica muito mais claro e objetivo.
2 - Funções
NÃO IMPLEMENTE FUNÇÕES ENORMES, SEPARE-AS!
Seja pequeno!
Você terá mais facilidade de entender o que cada função faz, deixando-as menores, fazendo apenas 1 coisa.
Exemplo:
Tenho uma função de efetuarPedido(), nessa função deixe somente a implementação de efetuar um pedido, e não efetuar pedido, dar baixa no estoque, enviar mensagem ao usuário, tudo isso em uma função. Caso ocorra algum erro, você saberá exatamente onde refatorar o código desenvolvido.
Uma dica dada, é observar os níveis de endentação do código, se você perceber que está com muitos níveis, é bem provável que a função está fazendo mais de uma coisa.
Repetindo: AS FUNÇÕES DEVEM FAZER UMA COISA E DEVEM FAZÊ-LA BEM.
Só para complementar, argumentos booleanos, em geral, não são bons e o número ideal de argumentos para uma função é 0(zero).
Depois vem um mônade(1), seguido de díade(2). Sempre que possível devem-se evitar três parâmetros. Para mais de três deve-se ter um motivo muito especial (políade) - mesmo assim não devem ser usados.
3 - DRY (Don't repeat yourself) - Não se repita
Comentários não ajudam um código sujo. Como foi dito acima, caso o programador (ser humano, conhecedor da sintaxe da linguagem) não conseguiu enteder o código, então não será um comentário que ele entenderá.
Os comentários são aceitáveis quando:
- Explicarem sobre a licença, direitos de uso de uma lib, por exemplo.
- Comentários que explique a regra de negócio;
- Comentários informativos.
4- Classes
Devemos sempre seguir a convenção padrão do Java. Uma classe deve começar com uma lista de variáveis. As constantes estáticas públicas, se houver, devem vir primeiro.
Então variáveis estáticas privadas, seguidas por variáveis de instância privadas. Raramente há uma boa razão para ter uma variável pública.
As funções públicas devem seguir a lista de variáveis. As funções utilitárias deverão ser privadas, assim ajuda o programa a ler como um artigo de jornal.
AS CLASSES DEVEM SER PEQUENAS.
Assim como foi dito nas funções, que elas devem ser pequenas e realizar uma coisa de maneira correta, para a classe contamos quantas responsabilidades ela excerce.
O nome de uma classe deve descrever quais as responsabilidades que ela cumpre.
No decorrer do livro ainda existem muitos assuntos que são tratados, como Responsabilidade Única, Exceção, Concorrência e etc...
Confesso que a leitura desse livro pude aprender muita coisa sobre desenvolvimento, as quais implementava de maneira incorreta, apenas fazendo com o que a máquina entendesse o meu código, e acredito que assim como você, estamos sempre em crescimento e melhorando o nosso trabalho, e os meus projetos serão mais bem pensados e avaliados. Vale a pena ler, e aprender ainda mais.
Siga-me nas redes sociais:
Twitter: devhiranneri
Github: github.com/hiranneri
Linkedin: linkedin.com/in/hiranneri
Muito Obrigado e até a próxima! :)
Referências:
Livro Clean Code: https://www.amazon.com.br/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
https://pt.slideshare.net/rodrigokono/boas-prticas-tcnica-para-um-cdigo-limpo-clean-code
https://vidadeprogramador.com.br/
