Código Limpo - Habilidades Práticas do Agile Software

Receba em primeira mão o conteúdo exclusivo do Blog, além de promoções de livros e cursos de programação. Você receberá um email de confirmação. Somente depois de confirmar é que poderei lhe enviar o conteúdo exclusivo por email.

Email inválido.
Blog /Livros /Código Limpo - Habilidades Práticas do Agile Software

Código Limpo - Habilidades Práticas do Agile Software

Vinícius Thiengo28/01/2016
(1150) (1) (22)
Go-ahead
"Não compare você mesmo com outros, pois é ai que começa a perder confiança em si próprio."
Will Smith
Código limpo
Capa do livro Refatorando Para Programas Limpos
TítuloRefatorando Para Programas Limpos
CategoriaEngenharia de Software
AutorVinícius Thiengo
Edição
Ano2017
Capítulos46
Páginas598
Comprar Livro
Conteúdo Exclusivo
Receba em primeira mão o conteúdo exclusivo do Blog, além de promoções de livros e cursos de programação.
Email inválido
Capa do livro "Código Limpo" de Robert C. Martin
Título
Código Limpo - Habilidades Práticas do Agile Software
Categoria
Programação de computadores
Autor(es)
Robert C. Martin
Editora
Alta Books
Ano
2009
Edição
Páginas
423

Opa, blz?

Terminei a leitura do livro “Código Limpo” de Robert C. Martin (ou “Tio Bob"), editora Alta Books. Robert C. Martin deve ser conhecido por ti se já estudou ou está estudando sobre padrões de projeto e engenharia de software. Martin é um dos precursores do Agile Software.

No livro Código Limpo o autor junto a outros profissionais de codificação (tem partes do livro que foram feitas por outros coders / autores) apresenta um caminho para se obter mais de nossos códigos. Isso mesmo, um caminho, pois logo no início do livro Martin deixa claro que o que será apresentado é um possível caminho para melhoria da codificação e que existem outras linhas de desenvolvimento que também são boas.

O livro não é "hardcode", você não precisa codificar nada, apenas acompanhar alguns trechos de código. Somente no capítulo que fala sobre a refatoração da entidade SerialDate é que tem bastante código. O apêndice B, referente a esse capítulo, é somente o código da entidade e seus testes.

Uma dica se estiver com pouco tempo e já quiser ter ao menos um check list do que não fazer em seu código: leia diretamente o último capítulo, “Odores e Heurísticas”, mas é aquilo, será realmente um resumo, logo recomendo a leitura por completo do livro.

Enfim, voltando ao conteúdo do livro, vamos seguir com as dicas para se ter um código limpo.

Segundo o livro, tenha em mente que se você coloca comentários em seus códigos isso é devido a sua não habilidade ou preguiça em trabalhar um código melhor e auto comentado. Auto comentado? Sim. Um código auto comentado é um código onde os nomes das variáveis falam o que elas são ou armazenam, por exemplo, ao invés de utilizar $segundos para armazenar a data de registro do user em formato de segundos, utilizaria $dataUserRegistroEmSegundos, se essa variável for uma variável de instancia da classe User você não precisaria do User no nome.

A principio você pode olhar e imaginar que isso não é necessário, porém a coisa começa a complicar quando você volta a esse trecho de código depois de algum tempo e ali tem também outras variáveis que utilizam segundos como conteúdo. Mesmo que não tenham outras variáveis nesse contexto de segundos, somente ter uma variável de instancia com o nome segundos pode se tornar uma dor de cabeça. Mas enfim, essa dica dos nomes das variáveis já é antiga e hoje em muitas das libraries que utilizo não encontro esse problema, a falta de variáveis auto comentadas.

Seguindo com o conteúdo. Seus métodos têm de realizar apenas uma tarefa, suas classes devem ser responsáveis por uma parte mínima do projeto, isso tudo seguindo o Principio da Responsabilidade Única. Os métodos não devem ter muitas linhas de código (no livro há comentários do autor falando algo em torno de no máximo 10 linhas) e as classes devem ter somente os métodos e variáveis exatos para suas tarefas. Classes e métodos seguem a mesma convenção de nomes das variáveis, devem ser auto comentados.

Seus métodos se possível não devem utilizar parâmetros de entrada (muito menos de saída, o famoso “&” no PHP). Se for necessário utilizar parâmetros tente o mínimo possível, até três parâmetros é aceitável, ruim, mas aceitável. Mais que três você deve tentar alguma outra solução, pois isso provavelmente está indicando que seu método está fazendo mais de uma coisa, essa indicação de mais de uma tarefa sendo executada também é válida quando se utiliza parâmetros do tipo boolean.

Segundo o livro nós developers jamais devemos fazer isso, utilizar parâmetros do tipo boolean, pois essa é a mais clara evidência de que seu método está quebrando o Principio de Responsabilidade Única e realizando mais de uma tarefa.

Caso parâmetros de saída sejam necessários, utilize objetos, pois esses já são por padrão passados por referência (provavelmente isso é verdade em todas as linguagens que trabalham com orientação a objetos de forma nativa, sem a necessidade de trabalhar com ponteiros e cia de forma explicita).

Evite ao máximo o encadeamento de chamadas de métodos dentro de outros métodos, um exemplo no PHP: $user->getUniversity()->getStudentId( $semester ). Nesses encadeamentos, segundo o livro, você está criando uma dependência ainda maior entre seus métodos, colocando-os ainda mais acoplados, estratégia ruim a se seguir, pois se tiver de realizar alguma mudança em University, no método getStudentId(), você terá de alterar o método que realiza a chamada acima também.

Logo o ideal seria na classe User ter um método $user->getIdInUniversity( $semester ). Dessa forma o acoplamento é menor e a alteração no método getStudentId() da classe university está encapsulado no método getIdInUniversity() da classe User, que é a entidade que referencia diretamente a instancia de University, evitando que o método que está utilizando a instancia de User tenha de sofrer alterações.

Quando for necessária a utilização de if..else ou switch é melhor estudar uma estratégia de uso de Polimorfismo ou, caso não seja possível, a criação de outros métodos para desmembrar a utilização dos condicionais. Pois condicionais indicam que seu método está fazendo mais de uma coisa e isso complica ainda mais a leitura e entendimento do código. Lembrando que, segundo Martin, hoje o tempo utilizado na leitura de código na atualização ou continuação de um software é 10x maior que o tempo de escrita do software.

Há casos em que criar um método pra solucionar um problema fará com que esse método fique totalmente fora do contexto do problema do qual a classe atual foi feita para resolver. Exemplo: uma classe Carro tendo que ter um método getPrecoTabelaFipeEmAno( $ano ). Nesse caso o ideal seria ter uma classe (e o respectivo método) somente para essa tarefa, pode ser a classe TabelaFipe, por exemplo.

Sabe aqueles valores soltos, muito comum em condicionais como: if( $status == 2 ){…}. Esses valores (de qualquer tipo primitivo, incluindo string), também conhecidos como valores mágicos, devem virar constantes, que também devem receber nomes auto comentados. Exemplo: o 2 viraria const DESLIGADO = 2 em uma classe PHP e o uso ficaria da seguinte maneira if( $status == self::DESLIGADO ).

Não repita código, cada entidade em seu lugar. Repetir código vai complicar o crescimento do software. Essa parte de repetição junto a parte de Desenvolvimento Dirigido a Testes (TDD - sigla em inglês) tem muita ênfase no livro, porém a parte de TDD é somente comentada, várias vezes, mas não há uma linha de utilização do TDD sendo explicada no livro, aliás esse é um dos pontos negativos, pois se você ler na contracapa do livro, um dos pontos comentados é o ensino de como trabalhar com testes unitários e o desenvolvimento dirigido a testes.

Repetição é algo tão comum que muitos dos padrões criados até hoje são variações para evitar repetição de código.

Testes. Apesar da não explicação mais detalhada do uso do TDD o autor ressalta frequentemente que devemos desenvolver com testes, testar tudo e ter em mente que quando um trecho do código passou nos testes é porque não há falhas ou nós não criamos testes eficazes para gerar as falhas. Uma única resposta errada é o suficiente para jogar a lógica utilizada por terra e então a necessária refatoração daquele trecho de código.

Um outro ponto negativo do livro, além da expectativa sobre o TDD, é que ele fala de concorrência, Threads e cia, porém não comenta sobre padrões para manter o código limpo quando envolve persistência de dados, na verdade ele somente fala sobre a existência do Active Record Pattern, mas nada de mais.

A formatação do livro é outro ponto negativo. As páginas têm, algumas vezes, dois tamanhos de fontes diferentes. Em alguns trechos os textos estão bem juntos e têm então bastante conteúdo em pouco espaço, mas de repente os textos voltam a forma comum, com a separação correta.

A verdade é que nenhum dos problemas apontados fazem não valer a leitura do livro. Outro ponto percebível que pode parecer um problema no uso das técnicas apresentadas é que aplicar tais técnicas de engenharia de software fazem com que, provavelmente, o tempo de codificação aumente logo no início do projeto, porém depois com cada entidade em seu lugar, a reutilização do código vai fazer com que as coisas andem mais rapidamente.

E, se pouco o ponto mais inspirador do livro, não existe gênio, o autor deixa claro que a melhora da codificação vem com muita prática e que ele, até hoje, não começa criando um software limpo, na verdade ele começa por criar uma classe nem de perto aplicando o principio da responsabilidade única. Os métodos são grandes e realizam várias tarefas.

Porém terminada a solução do problema que a entidade veio a resolver, começa o processo de refatoração, criando outros métodos menores vindos daquele maior e se necessário, outras classes também. O processo de refatoração é contínuo, nas classes e métodos que surgiram com a primeira refatoração você terá de aplicar o mesmo processo para melhorar ainda mais o código, e assim segue.

Entenda que parte da confiança creditada ao livro é porque o autor junto aos outros convidados têm nada mais nada menos que quatro décadas na área de desenvolvimento de software. De vez em quando no livro você irá ler histórias que giraram em torno da década de 70. Esses camaradas têm uma bagagem de problemas e soluções longa além de serem todos programadores que se preocupam com o código, aplicam refatoração.

O livro é excelente. O que passam é que saber codificar é muito mais do que apenas resolver problemas via software, codificar é arte, é deixar o software no melhor caminho possível para a evolução e utilização por outros developers. Essas técnicas de engenharia de software juntamente com o estudo mais detalhado de padrões de projeto vão lhe dar um poder de desenvolvimento ainda maior e com maior produção.

Apesar do autor ser pouco tolerante com comentários eu ainda prefiro utiliza-los em partes críticas. Alias, no livro, o capítulo 4 fala somente sobre comentários, caso esses sejam necessários, devem ser bem feitos e apresentarem somente o essencial.

Vou de cinco estrelas e se você é coder deve sim ler o livro, pois as técnicas são simples e apesar do livro ser de 2009 e os códigos serem em Java, o conteúdo é atual para a melhoria da codificação e os códigos em Java não atrapalham em nada o entendimento.

Dica: um estudo sobre padrões de implementação no core, padrões como: Factory, Active Record, Singleton, … seria uma excelente escolha para complementar a leitura de "Código Limpo”. Um possível conteúdo é o livro “Padrões de Implementação” de Kent Beck.

Vlw.

Receba em primeira mão o conteúdo exclusivo do Blog, além de promoções de livros e cursos de programação.
Email inválido

Relacionado

Monetização Eficiente no Android com APPODEALMonetização Eficiente no Android com APPODEALAndroid
Business Model GenerationBusiness Model GenerationLivros
KISS - Mantenha Isso Estupidamente SimplesKISS - Mantenha Isso Estupidamente SimplesAndroid
Engenharia de Software: Código Limpo na PráticaEngenharia de Software: Código Limpo na PráticaDesenvolvimento Web

Compartilhar

Comentários Facebook (1)

Comentários Blog

Para código / script, coloque entre [code] e [/code] para receber marcação especifica.
Forneça seu nome válido.
Forneça seu email válido.
Forneça o comentário.
Enviando, aguarde...