Clean Code

O primeiro objetivo dos desenvolvedores quando criam uma funcionalidade é fazê-la funcionar. Tudo bem, está funcionando, mas e o código, como esta? Será que o código que faz tudo funcionar está legível, fácil de ser entendido, ou seja, será que está limpo?
  É preciso preocupar-se com o código, garantir que  está legível e bem escrito, pois somente o próprio código pode dizer de forma confiável o que o software realmente faz.

Mas afinal, o que é código limpo?

Em suma um código limpo deve ser:

·         Elegante (distinto)

·         Eficiente

·         Legível

·         Simples

·         Direto

·         Único, sem duplicidades

·         Bem escrito

·         Deve ser escrito cuidadosamente

·         E deve sempre possuir UMA responsabilidade

O código é importante e deve agregar valor ao negócio. Somente um código limpo pode oferecer a qualidade e entendimento que esperamos quando abrimos uma classe. Portanto é necessário que seu código seja limpo e legível para que qualquer um que encontrá-lo possa facilmente entendê-lo evitando perda de tempo e facilitando o trabalho de todos.

Nomes significativos

Vamos começar pelos nomes. Escolhemos nomes para tudo, desde variáveis até métodos e classes, por causa disso devemos escolhê-los bem.

Os nomes devem nos dizer três coisas: Porque existem, o que fazem e como são usados. Devem revelar sua intenção e ser significativos, devem dizer o que estão fazendo e o que significam.

Faça distinções significativas, use nomes diferentes dentro de um mesmo escopo. Nomes como a1, a2, a3 são o oposto de nomes que demonstram intenção. São confusos e não informam nada. Evite também usar abreviações ou trocadilhos, escreva exatamente o que você quer dizer, o nome deve ser auto-explicativo. É comprovado que um desenvolvedor passa muito mais tempo lendo código do que escrevendo, por isso não se preocupe em economizar caracteres ao escolher um nome, o fato de um ser claro e objetivo poupará muito mais tempo do futuro do que os caracteres a menos que você digitar ao escolher um nome curto e ruim.

Métodos e funções

O que os tornam métodos e funções fáceis de se ler e entender? A primeira regra dos métodos é que eles devem ser pequenos, a segunda é que eles devem ser menores ainda.

Métodos devem conter no máximo 20 linhas e seu nível de identação não pode ser maior que dois. Quanto ao conteúdo, um método deve ter somente UMA responsabilidade. É difícil dizer o que é “uma responsabilidade”, mas uma maneira de descobrir se um método está fazendo mais de uma coisa, é tentar extrair uma parte dele em outro método. Se for possível, realmente o primeiro método tinha mais de uma responsabilidade.

Evite passar muitos parâmetros para um método, porque isso pode causar confusão além de dificultar a escrita de testes unitários, pois assegurar que todas as combinações de parâmetros diferentes funcionarão é bem mais trabalhoso. Passar parâmetros booleanos (verdadeiro ou falso) também não é uma boa prática, além complicar a assinatura do método, claramente a função tem mais de uma responsabilidade. Outro detalhe importante  que devemos nos preocupar são os efeitos colaterais, esses efeitos são mentiras. Seu método diz que fará uma coisa, mas faz outras “escondidas”.

Observe o método abaixo:

public boolean checkPassword(String username, String password) {

String passwordStatus = cryptographer.decrypt(password);

if(passwordStatus.equals(“OK”)) {

     Session.initialize();

     return true;

}

return false;

}

O método checkPassword tem o objetivo de verificar a validade da senha, mas além disso está abrindo um sessão, o que não está coerente com a finalidade do método. Não se esqueça, seu método deve sempre ter somente um objetivo.

Comentário

Comentários podem ser úteis se colocados nos lugares certos, mas também podem ser mentirosos e trazer desinformação. Na verdade, o melhor comentário é aquele que não precisa ser escrito. Podemos usá-los de forma benéfica para informar o leitor de alguma conseqüência ou fornecer a intenção de uma decisão tomada, mas um dos principais motivos para você escrever um comentário é porque o código está difícil de ser entendido. Você acha que o código ficou meio confuso e acha melhor adicionar um comentário? Não, você acha melhor refatorar

Quando você pensa em adicionar um comentário em seu código, é um forte indício que ele não está muito bom, não está claro

Não use comentários quando você pode usar métodos ou variáveis,explique-se no código, lembre-se que apenas o código pode dizer o que ele realmente faz

Formatação

A formatação do código é importante, pois se trata da forma de comunicação do desenvolvedor, um código todo bagunçado e sem formatação dificulta o entendimento de quem o está lendo

A legibilidade do código terá profundo efeito sobre todas as mudanças que serão feitas, seu estilo e disciplina sobrevive sobre estas mudanças.

Procure escrever  classes com no máximo 500 linhas, classes menores são mais fáceis de se entender. Já para as linhas de código, tente estabelecer um limite de caracteres por linha. Uma boa identação ajuda a visualizar melhor todo o escopo e facilita a identificação de situações e regras relevantes. Tente manter conceitos relacionados mais próximos verticalmente, para criar um fluxo na leitura do código. Use espaços entre operadores, parâmetros e vírgulas. Evite deixar o código todo grudado.

Tratamento de erro

Quando estamos programando devemos tratar os possíveis erros que nossa aplicação poderá lançar, as coisas podem dar errado e temos que estar certos que nosso código fará o que deve fazer

Prefira lançar uma exception ao invés de retornar um código de erro, estes retornos desorganizam a chamada do método e pode-se facilmente esquecer de verificá-los

Defina o fluxo do método separando as regras de negócio de erros ou outras situações. Para seus erros crie mensagens informativas, mencionando a operação que falhou e o tipo de falha.

Testes unitários

Há alguns anos atrás, pouco se ouvia falar de TDD (Test Driven Development). Para muitos TDD erá apenas trechos de código que garantia que o programa “funcionasse”. Mas essa idéia amadureceu bastante entre todos nós, hoje em dia programar com TDD é um conceito de alto nível, por isso, todos os testes que criamos devem ser escritos com código limpo.

Queremos dizer muito em nossos testes, por isso que eles devem ser legíveis, claros e simples de entender. Um teste com código ruim e difícil de entender é muito mais trabalhoso para se dar manutenção. Cada teste deve possuir apenas um conceito para facilitar seu entendimento, também deve sofrer alterações da mesma maneira que o código que está testando, tudo isso para manter a flexibilidade e a manutenabilidade do código.

Lembre-se que o código do teste é tão importante quanto o código da produção.

Todos sabem que o TDD nos manda escrever o teste antes do código de produção em si, considere essas três regras do TDD:

1.     Você não pode escrever o código até que você tenha criado um teste que falhe.

2.     Você não pode escrever mais testes do que seja suficiente para falhar.

3.     Você não pode escrever mais código do que o suficiente para passar o teste que está falhando.

Se você conseguir seguir essas regras ao desenvolver, você estará praticando TDD corretamente.

Classes

Para começarmos a falar de classes limpas podemos partir da organização das classes. De acordo com os padrões Java, uma classe deve começar com uma lista de variáveis de preferência nesta ordem:

1.     variáveis publicas e estáticas

2.     variáveis privadas e estáticas

3.     variáveis privadas

Depois das variáveis vêm os métodos públicos. Os métodos privados aparecem depois de suas chamadas. Assim como os métodos, as classes também devem ser pequenas. Ninguém gosta de encontrar classes gigantes onde é difícil até mesmo de se encontrar dentro delas. Mas a pergunta é: O quão pequenas elas devem ser?

O nome da classe deve representar a sua responsabilidade. Tentar fazer uma breve descrição da classe, explicando o que ela faz pode ajudar a escolher o nome certo. Esta descrição deve ter no máximo 25 palavras e não  conter palavras como “mas”, “e”, ”ou”, “se”, pois expressam mais de uma coisa mostrando que há mais de uma responsabilidade.

Outra maneira de descobrir o tamanho ideal da classe é analisarmos suas responsabilidades. O Princípio da Única Responsabilidade (Single Responsibility Principle) diz que uma classe deve ter uma, e apenas uma razão para mudar. Quando uma classe possui mais que um motivo para ser alterada é porque provavelmente ela esta fazendo mais coisas do que devia, ou seja, ela têm mais de um objetivo. O princípio nos dá definições de responsabilidade e uma diretriz para o tamanho de uma classe. Tentar identificar responsabilidades nos ajuda a melhorar nosso código e criar melhores abstrações.

Para concluir, queremos nosso sistema com pequenas classes, cada uma com uma única responsabilidade, tendo uma razão para mudar e colaborando com outras para alcançar o comportamento desejado do sistema.

Design emergente

Design emergente é um design que nunca é o final, sempre está em evolução. Para conseguirmos criar boas estruturas de código tornando mais fácil de aplicar princípios como SRP e DIP, e assim facilitar a criação de um de bom design de software, Kent Beck estipulou 4 regras para um design simples (Simple Design):

1. Rode todos os testes

Fazer um sistema testável nos obriga e usar boas práticas como classes e métodos pequenos de apenas uma responsabilidade.

Quanto mais testes fazemos mais e melhores maneiras e princípios seguiremos para evitar o acoplamento de nosso código. Lembre-se, um sistema testável possui sempre todos os seus testes passando. Um sistema que não é testável, não é verificável e assim não pode ser entregue para produção.

2. Remova duplicação

Duplicação é o primeiro inimigo de um bom design, ela representa trabalho e riscos adicionais além de uma maior e desnecessária complexidade. Ela se manifesta em linhas de códigos iguais ou parecidas além de aparecerem nas implementações. Usar padrões como Template Method é uma saída para remover duplicações mais complexas.

3. Expresse sua intenção

Escrever código que nós entendemos é fácil pois estamos concentrados e ligados no problema que estamos tentando resolver. Mas o próximo que pegar o código para fazer manutenção, não estará tão ligado ao problema como você estava quando implementou a solução.

Expressar-se bem no código pode trazer grandes benefícios para o desenvolvimento de um sistema. Além de poupar tempo de quem o mantém. Você pode expressar-se bem em seu código escolhendo bons nomes, deixando métodos e classes pequenas, separando responsabilidades. Lembre-se que você pode sem o próximo a ler este código.

4. Diminua o número de classes e métodos

Sempre que possível, nosso objetivo é manter sistemas pequenos enquanto ao mesmo tempo se mantém  métodos e classes pequenas.

Princípios e boas práticas não substituem a experiência, mas a partir delas pode se dar o primeiro passo para desenvolver um bom design.

Conclusão

Ao longo do tempo, comecei a perceber a diferença que estas técnicas fazem no meu dia-a-dia como desenvolvedor, pois, elas ajudam a pensar de uma forma mais  clara e objetiva sobre o código que escrevo. Pequenas coisas podem fazem grandes diferenças.

Tendo em mente estas observações, passei a escrever códigos mais legíveis, de fácil manutenção e mais eficientes. Sempre que vejo um trecho de código que não está muito legível, sinto-me na obrigação de refazê-lo, tornando-o legível limpo e eficiente.

Extreme Programming

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

Simplicidade

Coisas simples são mais fáceis de entender, manter, construir em cima, se for necessário, derrubar e refazer.

Ser simples não é um ato de desespero, é um ato de consciência e absoluta precisão. Muitas pessoas confundem simplicidade e facilidade. O mais simples nem sempre é o mais fácil e também não é escrever menos código. Simplicidade significa codificar o necessário para que um requisito seja atendido e entregue ao cliente.

FeedBack

Quanto antes você tiver feedback sobre uma situação, mais rápido você pode agir.

O cliente aprende com o sistema que utiliza e com este aprendizado consegue reavaliar o produto recebido, com isso pode realimentar a equipe de desenvolvimento com as suas reais necessidades. Com o feedback , o cliente conduz o desenvolvimento do seu produto, estabelece prioridades e informa aquilo que é realmente importante.

Um ponto que muitas empresas de software falham é não dar valor ao que o cliente realmente deseja, utilizam cegamente metodologias e acabam esquecendo o real propósito de um software: facilitar o trabalho de pessoas.

Para que o feedback entre cliente e desenvolvedor possa ser efetuado com sucesso é necessário ter uma boa comunicação entre eles. A XP prega que esta comunicação ocorra da forma mais direta e eficaz possível, oferecendo agilidade aos assuntos tratados. Recomenda-se o contato direto (face-a-face) entre cliente e desenvolvedor, para evitar qualquer tipo de especulação ou mal entendido entre as partes e para que possíveis dúvidas possam ser resolvidas de imediato.

Coragem

“Coragem é resistência ao medo, domínio do medo, e não ausência do medo” (Mark Twain)

Por ser um processo de desenvolvimento novo e baseado em diversas premissas que contrariam o modelo tradicional, o XP exige que os desenvolvedores tenham coragem para:

·         ·         Desenvolver software de forma incremental;

·         Manter o sistema simples;

·         Permitir que o cliente defina prioridades;

·         Fazer desenvolvedores trabalharem em pares:

·         Investir tempo em refactoring ;

·         Investir tempo em testes automatizados;

·         Estimar estórias na presença do cliente;

·         Expor código a todos os membros da equipe;

·         Integrar o sistema diversas vezes ao dia;

·         Adotar ritmo sustentável de desenvolvimento;

·         Abrir mão de documentos que servem como defesa;

·         Propor contratos de escopo variável;

·         Propor a adoção de um processo novo.

·         Assumir em relação ao cliente possíveis atrasos e problemas de implementação;

·         Colocar desenvolvedores e clientes frente a frente;

·         Implantar uma nova versão do sistema no cliente semanalmente;

·         Apostar em seus colaboradores aumentando suas responsabilidades;

·         Modelar e documentar apenas quando for de extrema necessidade.

 Jogo de planejamento

A XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja trabalhando naquilo que gere o máximo de valor para o cliente. Este planejamento é feito várias vezes durante o projeto. é o momento onde o cliente solicita as funcionalidades desejadas através de estórias, onde a equipe estima o custo de cada estória e planeja as releases e as iterações.

O XP tem por objetivo gerar valor para o cliente ao longo do projeto, para isto o software é desenvolvido de forma incremental, onde a cada entrega o cliente possa utilizar o sistema e obter benefícios do mesmo. Estas entregas o XP denomina como sendo releases , pequenos intervalos de tempo, máximo 2 meses, onde funcionalidades que gerem valor ao cliente sejam entregues.

Stand up meeting

O dia de trabalho de uma equipe XP sempre começa com um stand up meeting . é uma reunião rápida pela manhã, com aproximadamente 20 minutos de duração e onde seus integrantes permaneçam preferencialmente em pé.

Segundo estudos uma reunião em pé é mais rápida, evita bate-papos paralelos e faz os integrantes irem diretamente ao assunto. Mais uma vez, ágil e simples.

A reunião tem por objetivo atualizar a equipe sobre o que foi implementado no dia anterior e trocar experiências das dificuldades enfrentadas. Neste momento também são decididas as estórias que serão implementadas no dia e em conjunto definir os responsáveis por cada uma delas.

Refactoring

Um desenvolvedor ao deparar com um código mal escrito ou pouco legível mas que esteja funcionando, nos modelos tradicionais de desenvolvimento, dificilmente efetuaria alterações neste código, mesmo que tivesse que implementar novas funcionalidades.

O XP prega que todo desenvolvedor ao encontrar um código duplicado, pouco legível, mal codificado, sem padronização, lento, com código legado ou uso incorreto de outras implementações, tem por obrigação alterar este código deixando-o mais legível e simples, porém esta alteração não pode mudar o comportamento do código em questão.

Esta prática anda de mãos dadas com o código coletivo, já que todo desenvolvedor tem a possibilidade de melhorar qualquer código do sistema.

A padronização oferece facilidades aos desenvolvedores no momento de implementar novas funcionalidades ou efetuar qualquer tipo de manutenção, uma vez que o código se encontra simples e claro.

Uma questão importante é que a prática de refactoring esta apoiada pelos testes automatizados, pois facilmente o desenvolvedor terá um feedback se a alteração por ele efetuada irá gerar qualquer tipo de comportamento anormal no sistema, sofrendo o aprendizado sobre a alteração por ele efetuada.

Código coletivo

No modelo tradicional de desenvolvimento, é comum dividir o projeto em partes e colocar responsáveis por cada uma destas partes. Porém apenas uma pessoa torna-se conhecedora daquela parte.

Este tipo de divisão traz sérios problemas ao projeto, uma vez que se aquela parte necessitar inúmeras alterações, apenas uma pessoa estará capacitada para alterá-la. Com estas inúmeras alterações, esta pessoa pode se tornar um gargalo no projeto.

O XP trava uma batalha contra este tipo de divisão, já que não existe uma pessoa responsável por uma parte do código. Cada desenvolvedor tem acesso a qualquer parte do sistema e tem liberdade para alterá-la a qualquer momento e sem qualquer tipo de aviso.

Esta prática tem como conseqüência um código revisado por diversas pessoas e caso algo não esteja claro, com certeza será alterado por alguma pessoa (refactoring ) para que o mesmo torne-se legível.

Padrões de desenvolvimento

Um dos valores do XP é a comunicação, e o código também é uma forma da equipe se comunicar. Uma forma clara de se comunicar através do código, é manter um padrão no projeto para que qualquer um possa rapidamente entender o código lido.

O XP recomenda a adoção de um padrão desde o início do projeto, preferencialmente padrões utilizados pela comunidade da linguagem de desenvolvimento. Havendo a necessidade de modificações e adaptações durante o projeto, que visam agilizar o desenvolvimento, as mesmas devem ser efetuadas.

Design simples

Nota-se que todas as práticas do XP focam que o maior valor possível seja gerado para o cliente, para tal premissa ser verdadeira o XP prega um design do sistema da forma mais simples possível para que atenda a necessidade do cliente.

Umas das premissas do desenvolvimento tradicional é que o custo de uma alteração no sistema cresce exponencialmente ao longo do projeto, com isto tenta-se criar soluções genéricas preparando o sistema para futuras alterações.

Este tipo de pensamento dá margens para especulações e implementações que na maioria dos casos não terá utilidade para o cliente. O XP parte do princípio que o custo de uma alteração tende a crescer lentamente e se estabilizar ao longo do projeto, esta premissa é dita em função dos avanços nas linguagens e práticas de programação, novos ambientes e ferramentas de desenvolvimento, utilização de orientação a objetos no desenvolvimento e em conjunto com estes novos avanços existe o fruto das outras práticas XP, deixando o código simples, legível e passível de alteração a qualquer momento.

Ritmo sustentável

Uma grande problema nos projetos de software é a falta de tempo para encerrar o mesmo, e uma das técnicas mais adotadas para compensar a falta de tempo é submeter os desenvolvedores (humanos) a trabalharem até mais tarde e muitas vezes sacrificarem seus finais de semana.

Nos primeiros momentos este tipo de atitude tem efeitos positivos, porém passado alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentração no desenvolvimento, justamente pelo cansaço físico do desenvolvedor.

O XP proíbe que os desenvolvedores trabalhem até mais tarde. O XP sugere um ritmo sustentável de 40 horas semanais, respeitando assim a individualidade e o físico de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.

Integração contínua

No desenvolvimento tradicional geralmente as equipes são organizadas de modo que uma parte (módulo) fiquei sob responsabilidade de um desenvolvedor, cabe a esta pessoa efetuar testes e codificação que dizem respeito a sua parte. Esta estratégia reduz a complexidade e as preocupações de um desenvolvedor.

Interfaces de integração são convencionadas para que futuramente estas partes possam se comunicar, este tipo de desenvolvimento esta propenso a sérios erros de integração, uma vez que os períodos em que as partes são integradas e testadas são extremamente longos.

O XP propõe uma integração contínua, se possível deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém desenvolvido. Com esta prática o feedback sobre a alteração efetuada será retornado em um menor espaço de tempo.

Releases curtos

No modelo tradicional o projeto é dividido em fases, de um modo que o cliente começará a ter benefício com o sistema muito próximo de o mesmo estar finalizado. A maior parte do investimento do projeto é feita antes mesmo de estar concluído, sem ter gerado qualquer tipo de valor econômico ao cliente.

O XP recomenda que pequenos investimento sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, o XP pretende dar o máximo de valor econômico ao cliente em um curto espaço de tempo.

Release é um conjunto de funcionalidade bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento.

                        

Equipe XP

Em uma equipe de XP existem papéis a serem desempenhados por um ou mais desenvolvedores. Estes papéis serão listados a seguir.

Gerente de projeto

Pessoa responsável pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento.

O gerente de projeto é responsável por filtrar assuntos não relevantes aos desenvolvedores e aspectos que só devam ser implementados em iterações futuras.

Para um bom exercício de gerente de projeto é necessário que a pessoa conheça e acredite nos valores e práticas do XP para que possa cobrar isto da sua equipe.

Coach

Pessoa responsável pelas questões técnicas do projeto, recomenda-se que esta pessoa seja a com maior conhecimento do processo de desenvolvimento, dos valores e práticas do XP. é de responsabilidade do coach verificar o comportamento da equipe frente o processo XP, sinalizando os eventuais erros cometidos pela equipe.

Analista de teste

Pessoa responsável em garantir a qualidade do sistema através dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iteração verificar se o software atende todos os casos de testes.

Recomenda-se que esta pessoa não seja um desenvolvedor, para evitar uma visão tendenciosa já que não conhece o código desenvolvido. O analista de teste deve ter uma visão muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator técnico.

Redator técnico

Pessoa responsável em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicação ao trabalho de codificação.

Esta pessoa deve estar em plena sintonia com os desenvolvedores e cliente para que a documentação reflita o código escrito e as regras de negócio atendidas pelo sistema.

Desenvolvedor

Pessoa responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.

Naturalmente existe níveis distintos de desenvolvedores dentro de uma equipe, mas com as práticas do XP, como pair programming , a tendência é a equipe se tornar uniforme em suas habilidades.

Conclusões

A metodologia de desenvolvimento Extreme Programming pode ser considerada extremamente nova, porém vem acompanhando as necessidades humanas dos desenvolvedores pelo mundo.

Gurus da tecnologia da informação vem aprimorando as concepções desta metodologia para atender as necessidades do mercado e principalmente das pessoas.

Um empresa ao utilizar este processo por completo, só estará agregando valor aos seus negócios e melhorando o ambiente de seus colaboradores e clientes, tratando-os como pessoas e parceiros. Está é chave no mundo dos negócios, o bem estar de seus colaboradores e a parceria entre o fornecedor e seus clientes, criando um laço de confiança ou até mesmo um sentimento de amizade.

Entender as necessidades do cliente não é ciência, é arte. Dar incentivo a ela é o mínimo que podemos fazer.