Posts Tagged "programação"
Uncle Bob Martin, um grande exemplo para nós Desenvolvedores
Fábio Akita, recentemente publicou uma entrevista com o famoso Uncle Bob Martin, grande personalidade da comunidade de desenvolvimento de software, métodos ágeis e software craftsmanship.
Uncle Bob é, sem dúvida, um grande exemplo para todos nós desenvolvedores de software, apesar de seus 46 anos de experiência com desenvolvimento de software, ele nunca parou de aprender. Programadores não devem nunca pensar que a linguagem que aprendem na faculdade ou que utilizam agora são A linguagem, ao invés disso, devem abrir suas mentes e estar sempre aprendendo uma nova linguagem de programação, disse ele.
What I'm reading and re-reading por Earl
Se você programar somente em Java, por exemplo, e não for além disso, você será um programador muito fraco, porém se for em busca de aprender novas linguagens e aprender novos paradigmas você voltará para o seu Java com muito mais conhecimento e será ainda mais eficiente, afirmou Bob. “Eu, por exemplo, estava aprendendo Ruby e agora estou estudando Clojure”, disse.
Depois de ter escrito o livro Clean Code (Código Limpo), Bob está escrevendo um outro livro agora, chamado Clean Coder (Codificador Limpo), falando sobre como gerenciar o tempo, como lidar com pressões, como estimar, como lidar com chefes, etc. Estamos aguardando ansiosos pela nova publicação.
Bob disse que toda boa idéia que fica popular, tornar-se um hype, muita gente usa isso para seus próprios interesses, muitas vezes invertendo os propósitos. Cuidado! Escolha bem quem o ajudará a aprender métodos ágeis. Volte as fontes, busque os livros de quem estava lá no inicio. Martin Fowler e Kent Beck, são ótimas referências.
Muita gente está agora em ágil, defendo ágil, alerta Bob, mas está apenas pela corrida do ouro, ou seja, não conhecem e nem acreditam nos princípios e valores dos métodos ágeis, apenas estão ensinando ou utilizando ágil para manter-se lucrativos em virtude do movimento do mercado que está sendo impulsionado pelo hype.
Veja o vídeo da entrevista, que foi gentilmente disponibilizado sob a licença Creative Commons pelo Akita.
http://blip.tv/play/AYHm7HIC
Siga os conselhos de Uncle Bob Martin, aprenda como um louco, leia, leia, leia.
Bluesoft Podcast: Um podcast sobre Métodos Ágeis em Português
É com grande satisfação que anuncio o Bluesoft Podcast, um podcast em português que tem como objetivo difundir as metodologias ágeis e desenvolvimento de software apresentado por mim e Luiz Faias Jr.
Speaker por DRB62
O Podcast já está em seu 4º episódio e abordou temas como:
“Cultura de Aprendizagem”
“Batman da Iteração”
“Restrospectiva do Seis Chapéus”
“Programação em Par“.
Além do tema principal, o podcast apresenta as principais novidades da última quinzena das comunidades ágeis nacional e internacional.
Disponível em aúdio e vídeo, possui um feed que pode ser assinado e um canal no iTunes.
Convido todos a ouvir ao podcast. Sugestões e críticas serão sempre muito bem vidas, mande-as para podcast arooba bluesoft ponto com ponto br.
Refactoring: Como eu perdi o medo do código velho
Este post é a tradução de um trecho do post “Dr. Strangecode, or How I Learned to Stop Worrying and Love Old Code” do Chris Boran, em ele que conta como foi descobrir a maravilha que é refatorar!
Alguns anos atrás, eu estava em minha livraria predileta quando vi o livro “Refactoring: Improving the Design of Existing Code” do Martin Fowler. Este livro mudou a minha carreira. Até então, eu tinha muito medo de mudanças. Eu enxergava o código antigo como um castelo de cartas – se não fosse extremamente cuidadoso, tudo poderia desmoronar. Sempre que meu chefe me pedia uma opinião sobre determinada área de código, minhas respostas eram mais ou menos assim:
O risco de fazer qualquer mudança, por menor que seja, é enorme – então, ou fazemos alguma gambiarra e nos arrependemos mais tarde, ou reimplementamos tudo.
Tudo bem, nós podemos conviver com a gambiarra por enquanto, e mais pra frente nós vamos arrumar um tempo pra fazer isso da forma certa.
Evidentemente, a cada release, nós eramos forçados a fazer varias decisões como essas. Quando a próxima release viesse, teriamos como prioridade corrigir código que já estaria em produção. Na prática poderíamos ter sorte e de gastar um montão de tempo reescrevendo um único e pequeno subsistema, mas introduzir pequenas gambiarras, poderiam comprometer outros sistemas. O resultado final é carinhosamente referido como uma “Grande Bola de Lama (Big Ball of Mud)”. Isso mesmo! É tão agradável como parecer ser. A vida pode ser bem miserável quando você sabe que está trabalhando todos os dias apenas alimentando a bola de lama (com + e + gambiarras). Você não gosta disso! Sua equipe não gosta disso! O seu chefe não gosta disso! Mas por algum motivo, você sente que as coisas nunca estam progredindo.
Eu pensava que o código velho precisava ser jogado fora e não re-vitalizado, mas eu queria ver se esse negócio de refectoring funcionava mesmo, então resolvi tentar. Fui bastante cuidadoso para seguir as técnicas exatamente como estavam descritas no livro. Assegurei que não estava usando a palavra refatorar quando eu queria dizer apenas re-escrever. Eu fui cuidadoso para refatorar o código toda a vez que eu queria mudar alguma coisa no código e não apenas procrastinar para mais tarde. Eu me assegurei de que os meus refactorings eram pequenos. E assim fui fazendo…
Obviamente esta forma de trabalhar também exigiu que eu fizesse testes unitários muito bons, mas eu já sabia alguma coisa sobre Test Driven Development e já tinha escrito testes unitários antes de corrigir bugs em uma tentativa de prevenir regressões. Rodar esses testes depois de cada refactroing não foi um desafio tão grande assim pra mim. Pouco a pouco eu fui descobrindo a verdade: Aplicando técnicas de refactoring, eu poderia pegar trechos de código que pensava precisar reescrever completamente e melhorá-los enquanto resolvia bugs. Eu podia matar dois coelhos numa tacada só.
Test Driven Development
O contato com Scrum, XP e Agile em geral, me levaram à diversos conceitos que até então desconhecia, um dos quais resolvi me aprofundar foi TDD (Test Driven Devolpment), para isso li o livro ”Test-Driven Development by Example” escrito por Kent Beck. O Livro é muito esclarecedor e divertido de ler, apresenta diversos conceitos e técnicas através de exemplos de implementações de pequenas soluções.
TDD ou Desenvolvimento Dirigido por Testes, é uma técnica de desenvolvimento de software que consiste em pequenas iterações onde testes são escritos primeiro e o código produzido é somente o necessário para fazer o teste passar, e finalmente o código é refatorado para acomodar as mudanças. TDD proporciona feedback rápido depois de cada mudança. Não é considerado somente uma ténica de escrita de testes, mas uma técnica para design de software.
chemistry por tschoppi
TDD pode ser facilmente explicado em cinco simples passos:
- Adicione um teste rapidamente.
- Execute todos os testes e observe o novo teste falhar.
- Faça uma pequena mudança para fazer o teste passar .
- Execute todos os teste e observe que foram bem sucedidos.
- Refatore e remova o código duplicado.
Para melhor entender este ciclo de cinco fases, vamos constuir um pequeno programa Java para realizar um simples cálculo de potência. Para executar os testes precisamos de uma ferramenta de testes unitários, utilizaremos o JUnit.
O JUnit possui uma classes chamada TestCase, a qual nossa classe de teste deverá extender. Essa classe possui uma série de métodos que nos auxiliarão no processo de testes unitários, tais métodos fazem o teste falhar caso determinadas condições não sejam satisfeitas.
Ex: O método “AssertEquals(x,y)“ faz o teste falhar caso x seja direferente de y.
assertEquals(“TDD”,”DDD”); //Falha assertEquals(100, 100); //Passa
Começaremos então pelo teste:
public class CalculadoraTest extends TestCase { public void testCalcularOitoAoQuadrado(){ Calculadora calculadora = new Calculadora(); assertEquals(calculadora.calcularPotencia(8, 2), new BigDecimal(“64”)); } }
Se tentarmos executar nosso teste, o JUnit nos apresentará uma barra vemelha o que signfica que o teste falhou, e falhou porque a classe Calculadora e o método estático calcularPotencia ainda não existem. Vamos então criar a classe e o método para fazer o teste ao menos compilar.
public class Calculadora { public void calcularPotencia(Integer a, Integer b){ return null; } }
Nossa missão agora é fazer, rapidamente, o teste passar. Para isso vamos então retornar o valor que nosso primeiro teste espera, 64.
public class Calculadora { public void calcularPotencia(Integer a, Integer b){ return new BigDecimal(“64”); } }
Se executarmos o teste novamente o mesmo passará… Eu seu, eu sei, que isso pode parecer meio estranho no inicio, mas não se assuste, você se acostumará e entenderá melhor o que está por traz disso tudo com o tempo. Vamos adicionar mais um método de teste em nossas classe de testes
public void testCalcularDoisAoCubo(){ Calculadora calculadora = new Calculadora(); assertEquals(calculadora.calcularPotencia(2, 3), new BigDecimal(“8”)); }
E vamos fazer a alteração mais simples possível para fazer o teste passar:
public class Calculadora { public void calcularPotencia(Integer a, Integer b){ if (b == 2) return new BigDecimal(“64”); else return new BigDecimal("8"); } }
Agora que os dois testes estam passando, realizaremos o processo de refatoração para remover as constantes e a redundancia do código, assegurando que o teste continue passando.
public void calcularPotencia(Integer a, Integer b){ BigDecimal result = new BigDecimal(a); for (int I = 0; I < b; I++) { result = result.multipliedBy(BigDecimal.valueOf(a)); } return result; }
Pronto! Refatoramos nosso código removendo as constantes e se executarmos nossos testes verificaremos que este será bem sucedido! Este é o processo básico de TDD.
Ops!!! O que acontecerá se tentarmos executar o método executar uma potencia de um número elevado a zero? Problemas!!! Todo o número elevado a Zero é igual a 1 (Um), dessa forma devemos adicionar um novo teste que verifique se um número elevado a zero retorna 1, fazer o teste passar, refatorar e assegurar de que os outros testes continuem passando.
public void calcularPotencia(Integer a, Integer b){ if (b.equals(0)){ return BigDecimal.valueOf(1); } BigDecimal result = new BigDecimal(a); for (int I = 0; I < b; I++) { result = result.multipliedBy(BigDecimal.valueOf(a)); } return result; }
public void testTodoNumeroElevadoAZeroDeveRetornarUm(){ Calculadora calculadora = new Calculadora(); assertEquals(calculadora.calcularPortencia(21, 0), new BigDecimal(“1”)); assertEquals(calculadora.calcularPortencia(8, 0), new BigDecimal(“1”)); }
É isso pessoal! Parece simples, mas não é fácil. Depois muito treinamento e prática em diferentes cenários isso começa a ficar mais natural e você passa a enxergar mais claramente os benefício desta poderosa técnica. Estou a disposição para esclarecimento de dúvidas. Comentários são sempre muito bem vindos.
