Posts Tagged "testes"

Software Craftsmanship com Uncle Bob Martin

Posted by andrefaria on Nov 30, 2009 in Agile | 3 comments

O pessoal da Software Engineering Podcast acabou de publicar a entrevista de Markus Völter com o consagrado Robert C. Martin, também conhecido como Uncle Bob Martin autor diversos livros como Clean Code e evangelista do movimento Software Craftsmanship. Recomendo que todos ouçam ao podcast (em inglês) na integra, mas gostaria de enfatizar alguns pontos importantes.

Sobre o Arquiteto de Software

Foto por Anirudh Koul

Segundo Uncle Bob, pensar arquitetura e design vale muito a pena, porém, ele não gosta nada da idéia de se separar a arquitetura da codificação. Os melhores arquitetos são aqueles que codificam e vivem no “mundo que constroem para os outros”, disse. Se um arquiteto não codifica ele fica desconectado das decisões que toma, porque não é afetado por elas, ele  ”não tem que dormir na cama que faz”.
O importante é que arquitetos mantenham seus dedos no teclado, a final, você não pode liderar um time a menos que os conheça e entenda. Você tem que experienciar o que o time está fazendo para saber o que ele realmente precisa.

Documentação

O código é documentação mais imporante. Todos os outros documentos devem refletir o que o código faz. O código digire todos o resto e não é apenas resultado de outros documentos como sugure o waterfall.

Software Crafsmanship

O termo foi criado com a publicação do livro de Pete McBreen em 2002.  Fala-se sobre aprender com mestres. Aprenda as habilidades e como tomar decisões, mas você deve aprender com outras pessoas ajudando-as a fazerem seu trabalho.

• Você deve sentir orgulho da forma que você trabalho.
• Sinta orgulho de poder fazer Test Driven Development.
• Sinta orgulho de ter alta cobertura de código.
• Sinta orgulho de desenvolver software de alta qualidade.
• Sinta orgulho de ter um bom design de código.
• Sinta orgulho de desenvolver software que realmente agregue valor de negócio aos clientes.

Uncle Bob sugere como práticas TDD, Integração Contínua e Programação em par, e afirma que bons times trabalham em par na maior parte do tempo, no entanto, afirma que não se deve ser religioso quanto a isso, “você não precisa trabalhar em par 100% do tempo”, diz.

Qualidade e Relacionamento com Clientes

Não basta funcionar, o software deve ser bem escrito e fácil de manter. Foque em agregar valor. Deve haver um parceira com os clientes. Você deve realmente envolver-se com as decisões tomadas e garantir que o que cliente pede realmente vai agregar valor para ele. Não faça simplesmente porque é seu trabalho se você já sabe que não vai dar certo. Comprometa-se com o resultado do seu trabalho.

Produtividade

Aprenda os Shortkeys (atalhos de teclado). Tente fazer o máximo que você puder sem usar o mouse. Um desenvolvedor de software deve estar altamente integrado com seu ambiente.
Utilize uma boa ferramenta de SCM (Source Code Control), o CVS é razoável, o SVN é melhorzinho, mas meu favorito é o Git.

Bug Tracking Systems são importantes, mas use com certo cuidado. Devem ser leves  e simples de usar.
Use ferramentas para teste como  jUnit (xUnit), rSpec, Cucumber, JBehave e Fit.
Linguagens dinamicas são muito produtivas e se você faz TDD o “perigo” vai embora. Você não precisa mais de um compilador para te dar uma falsa segurança.

Desenvolvimento de Carreira

A coisa mais importante para um desenvolvedor de software é noção de aprendizado contínuo. Você nunca pode parar de aprender. É como um médico.

Você deve aprender o máximo de linguagens que puder, e deve conseguir escrever código em todas essas linguagens ainda que não seja um especialista em todas elas. Não adianta. Aprenda no mínimo uma linguagem estática, uma dinâmica e uma funcional. Robert diz que todos devem aprender LISP.

Recado de Uncle Bob no Rails Conf 2009

Uncle Bob Martin na RailsConf 2009 porFabio Akita no Vimeo

Mais Informações sobre Robert C. Martin

• Palestra Principles of Agile OO Design na InfoQ
• Siga-o Uncle Bob no Twitter

jQuery: Poder e Simplicidade

Posted by andrefaria on Nov 30, 2008 in Agile, Software | 16 comments

No início deste ano conheci o jQuery e desde então não escrevo mais JavaScript sem ele. Gostaria de apresentar um pouco dessa biblioteca, e citar algumas boas razões para que você se aprofunde mais a respeito e pense em utilizá-lo.

O que é jQuery?

jQuery é uma biblioteca JavaScript rápida e concisa que simplifica percorrer documentos HTML, manipular eventos, criar animações e interações Ajax para um desenvolvimento web rápido. O jQuery foi desenvolvido para mudar a forma com que você escreve JavaScript [1].

Porque eu deveria utilizá-lo?

Simplicidade e Baixa Verbosidade

Quando bem usado o jQuery pode ajudá-lo a tornar seu web-site ou aplicação mais interativo, interessante e excitante, além disso, é simples de entender e fácil de utilizar, o que significa que a curva de aprendizado é pequena, enquanto as possibilidades são (quase) infinitas. [2].

Participação no "Falando em Agile 2008"

Posted by andrefaria on Oct 26, 2008 in Agile, Eventos | 11 comments

Nos dias 23 e 24 de Outubro participei do evento “Falando em Agile 2008” realizado pela Caelum aqui em São Paulo. Da mesma forma que fiz no “Rails Summit 2008“, tentarei transmitir um pouco da minha visão sobre o evento.

No primeiro dia, Alexandre Magno fez a abertura apresentando a proposta do evento e lançou uma questão para que as pessoas refletissem: “Agile simplesmente está na moda ou veio para ficar”?

Em seqüencia houve o Keynote de David Anderson, uma grande personalidade do mundo ágil envolvido na criação da metodologia Feature Driven Development (FDD), ele foi trazido à São Paulo pela Heptagon para ministrar o treinamento Zen Of Agile. Algumas pessoas já falaram sobre a palestra do David, mas gostaria de comentar alguns pontos que me chamaram atenção.

Working Hard - Foto por Karol M

“Working harden rather than smarter:” David questionou sobre simplesmente trabalhar duro ao invés de trabalhar e forma inteligente, e comentou sobre a fato de as pessoas não terem vida social ou tempo para a família porque trabalham mais (ou muito mais) de 40 horas semanais. Será que isso é mesmo necessário?

Starbucks citado por David - Foto por Rob

“The workers are not the problem, managers are:” Essa é uma frase de Barry Boehm que foi citada para começar uma reflexão sobre diversos problemas de gerenciamento de software, segundo David, um fraco gerenciamento pode encarecer o desenvolvimento de software mais intensamente do que qualquer outro fator. O palestrante disse acreditar que os gerentes do Starbucks são melhores do que a maioria dos gerentes de projetos de desenvolvimento de software: – “Eles simplesmente fazem o que tem que ser feito“.

“Todo trabalhador do conhecimento é um executivo:” No sentido de que tomamos milhares de decisões todos os dias para realizar nosso trabalho, não se trata apenas de seguir uma especificação.

Bugs - Foto por Michael Porter

“Software quase sem defeitos é possível:” David afirmou que um software sem defeitos pode até ser impossível, mas quase sem defeitos, com certeza, é possível. Comentou sobre a idéia que vem do Lean de parar tudo para resolver defeitos e falou da importância incentivar e dar condições aos desenvolvedores de fazer tudo de forma apropriada (inclusive dando a eles mais tempo se for necessário).

Alguns outros bons conselhos de David foram:

• Reduza a quantidade de Trabalho em Progresso (WIP)
• Pratique revisão de código e design
• Utilize ferramentas de análise estática e dinâmica de código.
• Faça testes unitários e pratique Test Driven Development (TDD).
  
• Faça Integração Contínua
• Não abra mão de testes formais por um testador profissional
• Estude mais sobre Kanban
• Utilize templates para User Stories
• Faça Programação em Par
• Treine sua Equipe
• Utilize padrões e templates de Arquitetura, Design, Codificação
• Tenha uma forte definição de pronto.

Arte por Nilson - www.nilson.de

O Adail Retamal da Heptagon fez uma apresentação sobre Agile Thinking (Pensamento Ágil) onde apresentou diversas técnicas que utiliza como apoio ao desenvolvimento ágil. Adail fez um tributo a filósofos e pensadores que o ajudaram a formar seus principais conceitos: Platão, Aristóteles, Arquimedes, Newton, Professor Júlio César de Melo, Richard Feynman e Eliyahu Moshe Goldratt.

Mind Map - Foto por Keith Davenport

Em seqüencia, foi apresentada a técnica de desenhar Mapas Mentais, que são um tipo de diagrama voltados para a gestão de informações, de conhecimento e de capital intelectual, que pode ser usado para desenvolver documentação de projetos. Foi sugerido que se faça um mapa para projetos que responda as perguntas:

• O que?
• Por que?
• Quem?
• Quando?
• Onde?
• Como?
• Quanto Custa?

Adail explicou como funciona a UML em cores, e apresentou o conceito de Teoria das Restrições (TOC), e como utilizá-los no desenvolvimento de software para melhoria contínua, identificar problemas, encontrar raízes de problemas, manter o foco no que é importante, e suas solucionar problemas.

Foto por ScottieT812

A Galera da Sea Tecnologia e o Tenente Souto apresentaram um case de desenvolvimento ágil de software dentro da aeronáutica, comentaram sobre a experiência adquirida na quebra de paradigmas e enfrentando diversas dificuldades culturais.

O Guilherme Chapiewski da Globo.com fez uma apresentação sobre liderança em equipes ágeis, os principais conceitos na minha perspectiva foram os seguintes:

• Um bom líder deve ter a Visão que incluí o Propósito, a Missão e os Valores, e deve transmitir isso para sua equipe.
• Deve dar as direções para equipe.
• Deve construir um bom ambiente para que as pessoas se desenvolvam.
• Deve ter paixão pelo que faz.
• Deve ser útil.
• Deve estar presente.
• Deve dar o melhor de si.
• Deve ser autêntico.
• Dever dar bom exemplo.
• Deve incentivar as pessoas a tomar iniciativa para resolver problemas sozinhos (deve ser descentralizador).
• Deve garantir que o trabalho está alinhado as expectativas.
• Deve ser tolerante.
• Não deve dar respostas deve ajudar as pessoas a encontrá-las.
• Deve garantir que as pessoas têm as ferramentas necessárias para trabalhar.
• Deve manter o seu time e contratar novos membros.

Happy Hour no Bar Opção - Foto por Victor Hugo

No final no primeiro dia, claro, assim como no Rails Summit, tivemos um Happy Hour no bar opção que fica na região da Avenida Paulista com presença da maioria dos palestrantes e uma galera super bacana.

No segundo dia, o Danilo Bardusco da Globo.com falou sobre como foi a introdução do Scrum na Globo.com, como surgiu a idéia, quais eram as necessidades, quais foram as dificuldades e como eles estão as vencendo. Entre as dificuldades, Danilo citou a quebra do paradigma do Big Design Up Front (BDUF), ter a equipe toda trabalhando em uma historia por vez e enfrentar a resistência de quem acha que está perdendo o poder. Achei interessante a idéia de utilizar personas para ajudar entender as histórias e reuniões periódicas entre disciplinas (arquitetos da informação scrum masters, etc.). Os Slides da apresentação estão disponíveis no blog do Bardusco.

Foto por Sara Petagna

O Daniel Cukier e o Professor Fábio Kon, ambos da Agilcoop e do IME/USP fizeram uma apresentação sobre “Padrões para Introduzir Nova Idéias” com base no livro “Fearless Change” de Linda Rising e Mary Lynn Manns, uma ótima abordagem quem está implementando metodologias ágeis em organizações. Recomendo assistir à esta entrevista (em inglês) e ouvir à este podcast da Agilcoop (em português) para mais informações sobre o assunto.

O Daniel Wildt da Dell em sua palestra contou um pouco sobre sua experiência na implantação de metodologias ágeis em equipes distribuídas, acho que a principal mensagem da palestra foi “Qualidade não é um opção“. Segundo Daniel, os princípios de qualidade da norma ISO 9000 são coerentes com o Manifesto Ágil.

O Antonio Carlos Silveira do Yahoo falou sobre o papel o Product Owner e a Priorizarão do Product Backlog. Os principais recados foram:

• Entenda o cliente. Utilizar personas (pessoas que representam seus usuários) podem ajudar.
• O Product Owner precisa entender muito bem do domínio do problema e precisa saber e ser muito bom em tomar decisões.
• O Product Owner pode ser técnico? Depende do domínio do problema, se o domínio for técnico, claro que pode.

Antônio também apresentou as técnicas “Kano Model” e “Benefício Relativo” para estimativa de histórias, mas disse que no fim das contas a o chute é a técnica que impera.

Arte por Leo Reynolds

O Phillip Calçado “Shoes” da ThoughtWorks em sua palestra “A Maldição da Fábrica de Software” falou sobre algumas lições que aprendeu em projetos que trabalhou na Austrália.

O Primeiro problema citado foi o de um projeto onde muitas pessoas foram envolvidas e como “gente demais compromete a comunicação” as coisas foram ficando complicadas, até chegar a um ponto em que 4 pessoas desenvolveram a mesma coisa no mesmo dia. Eu acho que este tipo de coisa acontece porque algumas pessoas ainda não entenderam que a idéia de que “o fato de 1 mulher poder ter 1 filho em 9 meses não significa que 9 Mulheres podem ter 1 filho em 1 mês“.

O Segundo problema foi referente a um projeto com um pouco de BDUF em que havia um arquiteto super-herói que dizia aos programadores o que e como desenvolver. Como resultado, a primeira versão do projeto foi entregue em metade do tempo planejado porém, na segunda versão os programadores queriam começar tudo de novo porque era impossível dar manutenção no código que havia sido desenvolvido. Isso aconteceu principalmente porque não houve refactoring.

De acordo com Shoes problemas como os citados acima acontecem porque as pessoas muitas vezes não entendem que tudo em métodos ágeis é um ciclo e que como as práticas estão relacionadas, jogar uma prática fora pode comprometer as outras, por isso experimente antes de jogar fora. Isso não quer dizer que você não possa adaptar métodos ágeis a uma forma mais adequada a sua realidade, mas quer dizer que você deve tomar cuidado e adaptar conscientemente. Saiba o que você está fazendo e pense no que você perde.

Algumas dicas do Shoes:

• Estude e Entenda os Conceitos. Saiba o que você está fazendo.
• Lembre-se que você desenvolve software.
• Não leve nada a ferro e fogo.
• Cuidado com quem você contrata (existem falsos agilistas).
• Só melhoria contínua salva.
• É muito fácil ser medíocre, mas você precisa ir além.

Além das palestras citadas, houveram outras de excelente qualidade apresentadas por Danilo Sato, Francisco Trindade, Professor José Papo, Alexandre Magno e  Robinson Caiado.

Meus parabéns a toda a equipe da Caelum pela realização do evento, a Globo.com, ao Yahoo e a Borland pelo patrocínio, e todas a pessoas que tornaram o “Falando em Agile 2008″ realidade.

Fique Ligado nos próximos eventos: OpenHack 2008 e Lançamento da InfoQ Brasil.

JUnit 4 em 60 Segundos

Posted by andrefaria on Aug 22, 2008 in Agile, Software | 1 comment

Esse artigo que foi escrito por Abdullah Çetin ÇAVDAR em inglês, apresenta de forma simples e rápida como utilizar a nova API do JUnit. Veja também o artigo original.

Brinquei um pouco com JUnit 4  esse final final de semana, e aqui vai uma pequena introdução:

@Test

Anote seus testes com @Test. Você não precisa mais usar o prefixo test nos métodos de testes, e além disso, sua classe também não precisa mais extender TestCase.

@Test
public void addition() {
   assertEquals(12, simpleMath.add(7, 5));
}
 
@Test
public void subtraction() {
   assertEquals(9, simpleMath.substract(12, 3));
}

@Before e @After

Utilize as anottations @Before e @After para para “setup” e “tearDown” respectivamente. Eles serão executados antes e depois de cada um dos seus casos de testes.

@Before
public void runBeforeEveryTest() {
   simpleMath = new SimpleMath();
}
 
@After
public void runAfterEveryTest() {
   simpleMath = null;
}

@BeforeClass
public static void runBeforeClass() {
   // executado uma vez antes de todos os testes serem executados
}
 
@AfterClass
public static void runAfterClass() {
   // executado uma vez depois de todos os testes serem executados
}

@Test(expected = ArithmeticException.class)
public void divisionWithException() {
   // divisao por zero
   simpleMath.divide(1, 0);
}

@Ignore("Não está pronto para ser executado")
@Test
public void multiplication() {
   assertEquals(15, simpleMath.multiply(3, 5));
}

@Test(timeout = 1000)
public void infinity() {
   while (true);
}

//public static void assertEquals(Object[] expected, Object[] actual);
//public static void assertEquals(String message, Object[] expected, Object[] actual);
 
@Test
public void listEquality() {
   List expected = new ArrayList();
   expected.add(5);
 
   List actual = new ArrayList();
   actual.add(5);
   assertEquals(expected, actual);
}

public static junit.framework.Test suite() {
   return new JUnit4TestAdapter(SimpleMathTest.class);
}