Metodologias Ágeis de Desenvolvimento de Software FEUP, MEI e LEIC, 2005/06

Transcrição

1 Metodologias Ágeis de Desenvolvimento de Software FEUP, MEI e LEIC, 2005/06 Ademar Aguiar ademar.aguiar at fe.up.pt FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 1

2 Papéis XP FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 2

3 Papeis principais Programador Cliente Tester Tracker Coach Consultant Big Boss FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 3

4 Estratégia de Desenvolvimento FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 4

5 Today s problem today, tomorrow s problem tomorrow A programação é considerada a actividade principal no XP. XP adiciona pequenas práticas à actividade típica de programação, tais como os testes automatizados. Continuous Integration reduz os conflitos na equipa. Collective Ownership encoraja a cooperação da equipa. Pair Programming liga todo o processo. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 5

6 Continuous Integration Novo código deve ser integrado em poucas horas (1,2,4..7) Ao fim de cada dia de desenvolvimento, deve ser produzida uma nova release em que todos os testes correm a 100%. A integração contínua tem as vantagens dos estilos de desenvolvimento programador individual e integração instantânea Como programador parece que se está sózinho. Como integrador consegue-se identificar onde estão os conflitos em termos de definições de classes e métodos. Ao correr os testes pode-se identificar onde estão os conflitos em termos semânticos. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 6

7 Continuous Integration... É importante usar ferramentas que possibilitem um ciclo rápido integrate/build/test. O refactoring motiva a escrita de código fácil de compreender, simples e desacoplado. Os riscos do projecto são minimizados porque os conflitos são detectados muito rapidamente na altura de integração. Todos sabem construir uma release, porque o fazem todos os dias várias vezes ao dia. O compartimentar do trabalho em pequenas unidades learn/test/code/release dão ritmo ao desenvolvimento, o que é motivador porque o progresso é facil de avaliar. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 7

8 Collective Ownership Anyone can change any piece of code at any time :? Sem testes, isto seria impensável. Sem integração contínua, isto seria muito ineficaz. O código complexo passa a ter um tempo de vida reduzido de acordo com o nível médio da equipa, porque todos o podem e devem simplificar quando o acham complexo. O refactoring ajuda neste processo de simplificação. Os testes ajudam a validar se as simplificações foram feitas de forma correcta, sem corromper o sistema. Esta prática aumenta a sensação de poder pessoal no projecto, o que é bom e motivador, levando a um equilibrio saudável e natural na equipa. Não se pode culpabilizar os outros porque algo está mal e poderia estar melhor... O conhecimento sobre o projecto é facilmente disseminado pela equipa ao longo da vida do projecto, de par em par, o que também reduz os riscos do projecto. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 8

9 Pair Programming Não é uma pessoa a programar e outra a observar. Não é uma pessoa a ensinar outra, embora pares formados por pessoas com níveis de experiência muito diferentes o possam parecer, pelo menos inicialmente. Com o tempo, os pares ficam mais homogéneos porque aprendem muito uns com os outros e podem-se ajudar mutuamente. O valor principal é COMUNICAÇÃO: o conhecimento é rapidamente disseminado pela equipa, de par em par, e enriquecido com a experiência e ideias de cada um. Existem pessoas que não gostam de trabalhar em pares. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 9

10 Pair Programming... A programação em pares provou ser mais produtiva do que a divisão do trabalho em dois e depois integrar: um é operacional enquanto o outro actua a um nível mais estratégico. A programação em pares permite ainda melhor qualidade final, melhor conhecimento global do sistema, reduz riscos do projecto. Em stress tende-se a esquecer testes, refactoring, integração... Mas a programação em pares tende a reduzir o risco de ocorrência destas tentações. Todo o processo de desenvolvimento beneficia com a programação em pares porque todos, pouco a pouco, ficam a conhecer todo o sistema e a ter capacidade de trabalhar em qualquer uma das suas partes. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 10

11 Estratégia de Design FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 11

12 The simplest thing that could possibly work Todos os valores de XP actuam no design. Comunicação Um design complicado é mais dificil de compreender do que um simples. O design deve ser comunicativo, e transmitir de forma rápida os aspectos mais importantes do sistema. Simplicidade O design deve ser simples, mas a estratégia que o origina também deve ser simples. ( Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior ) Feedback O design está certo ou errado? Design simples é rápido de codificar e de avaliar. Coragem Não ter medo de desenhar apenas uma parte do sistema e ter confiança de que se poderá continuar o desenho depois, quando e se for necessário. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 12

13 The simplest thing that could possibly work... Pequeno investimento inicial O investimento deve ser reduzido até se tirar beneficio do design. Assumir a simplicidade Ter coragem para assumir que o design mais simples funciona. Alterações incrementais O design irá ser refinado continuamente, evoluindo gradualmente e incrementalmente ao longo do tempo, à medida das necessidades. O design nunca estará completo, embora existam partes dele que se encontram bastante estáveis há muito tempo (princípio aberto-fechado ). Travel light O design não deve ter mais do que o estritamente necessário, tudo o que é necessário, mas nem mais um pouco. Ao programar somos tentados a antecipar problemas e portanto a fazer overengineering... O XP tenta evitar estes delírios quase nunca necessários. Test-Driven Development: escrever teste, fazer compilar o teste, fazer passar o teste, refactoring para simplificar o código e o design. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 13

14 Simplest O sistema deve comunicar tudo que se pretende comunicar. O sistema não deve ter código duplicado. O sistema deve ter o menor número possível de classes. O sistema deve ter o menor número possível de métodos. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 14

15 Estratégia de Teste FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 15

16 Write tests before coding... Escrever testes antes de escrever o código. Obriga a definir bem os requisitos a ser satisfeitos pelo código. Documenta os requisitos. Simplifica o design. Os testes serão preservados ao longo do tempo e executados sempre que o sistema é integrado e construído. Escrever testes para documentar os requisitos do ponto de vista do cliente. Os testes são automatizáveis. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 16

17 Code to pass the tests, fast! Escrever código para passar os testes rápidos, obrigam a concentrar no essencial, simplificando a implementação. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 17

18 Then, refactor... A redundância e erros de design introduzidos deverão ser eliminados por refactoring imediatamente a seguir aos testes passarem, mas apenas então. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 18

19 TDD Test Driven Development FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 19

20 Test-Driven Development (TDD) The rhythm of Test-Driven Development (TDD) can be summed up as follows: 1. Quickly add a test. 2. Run all tests and see the new one fail. 3. Make a little change. 4. Run all tests and see them all succeed. 5. Refactor to remove duplication. (Kent Beck, Test-Driven Development, Addison-Wesley, 2003) FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 20

21 Test-Driven Development: um exemplo Escrever e testar uma rotina que converte um inteiro n entre 0 e numa string com a sua representação por extenso em português. Sugestão: considerar sucessivamente números com mais dígitos Caso do zero Unidades de 1 a 9 Números de 10 a 20 Dezenas exactas Dezenas compostas Centenas exactas Centenas compostas Milhares exactos Milhares compostos... FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 21

22 Refactoring FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 22

23 O que é Refactoring? A ideia tem origem na tese de Bill Opdyke, A refactoring is a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior [Fowler 2000] O processo de refactoring envolve a eliminação de duplicação, a simplificação de lógica complexa e clarificação de código, tornando-o mais fácil de entender. Exemplos: alterar nome de variável, dividir um método grande, instanciar um padrão de design. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 23

24 Como fazer refactoring? Refactoring implica alterar código funcional logo é necessário ter testes para nos dar segurança de que o refactoring não alterou a funcionalidade do sistema. Os testes automatizados permitem-nos rapidamente confirmar que a funcionalidade do código alterado se mantém. Deve-se fazer refactoring de forma contínua sempre que se ache que o código deve ser evoluído, e não por fases, e em pequenos passos sucessivos para evitar a introdução de defeitos. Pequenos refactorings podem demorar segundos ou minutos. Grandes refactorings podem demorar horas ou meses, mas deverão ser sempre feitos em pequenos passos. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 24

25 Porquê fazer refactoring? Facilitar a inserção de código novo e novas funcionalidades. Melhorar o desenho do código existente. Compreender melhor o código. Tornar o código mais agradável de manipular, menos aborrecido de lidar, tanto individualmente como colaborativamente. Limpar e arrumar o código. Baixar o défice de design devido a não se fazer na altura certa e dose certa: o remover de duplicação, simplificar e clarificar o intuito do código. Evoluir uma arquitectura existente. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. [Fowler 2000] FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 25

26 Quando fazer refactoring? Quando se adicionam novas funcionalidades Para melhor compreender o código a modificar Para melhorar o design do código existente e assim facilitar a adição das novas funcionalidades Quando se pretende encontrar um bug Para melhor compreender o código com o bug e assim o identificar Quando se está a fazer revisão de código FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 26

27 Dificuldades de refactoring Bases de dados Aplicações fortemente dependentes dos esquemas das BDs Alterações na interface das classes Quando não se tem acesso a todo o código que usa uma interface que se pretende alterar o refactoring dessa interface pode ser complicado. - Don't publish interfaces prematurely. - Modify your code ownership policies to smooth refactoring. O código não funciona Nesta situação de nada serve fazer refactoring... FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 27

28 Refactoring e Design As actividades de refactoring e design são complementares. Design: da ideia à melhor solução Refactoring: da ideia à solução mais razoável. A aplicação contínua de refactoring conduz a design mais simples, resultando numa forma mais eficaz de na prática se chegar a uma boa solução de design. A ênfase é a mesma: idealizar a melhor solução. Na prática, implementa-se apenas a solução mais simples que funciona, pois sabe-se que se pode evoluir essa solução quando for efectivamente necessário fazê-lo. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 28

29 Refactoring e Performance Antes de se tentar melhorar a performance de código ajuda muito fazer-se refactoring para eliminar duplicação, simplificar e melhor entender o código e só depois afinar a sua performance. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 29

30 Formato dos Refactorings Nome Resumo Motivação Mecânica Exemplos FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 30

31 Catálogo de Refactorings Add Parameter Change Bidirectional Association to Unidirectional Change Reference to Value Change Unidirectional Association to Bidirectional Change Value to Reference Collapse Hierarchy Consolidate Conditional Expression Consolidate Duplicate Conditional Fragments Convert Dynamic to Static Construction by Gerard M. Davison Convert Static to Dynamic Construction by Gerard M. Davison Decompose Conditional Duplicate Observed Data Eliminate Inter-Entity Bean Communication (Link only) Encapsulate Collection Encapsulate Downcast Encapsulate Field Extract Class Introduce A Controller (Link only) Introduce Assertion Introduce Business Delegate (Link only) Introduce Explaining Variable Introduce Foreign Method Introduce Local Extension Introduce Null Object Introduce Parameter Object Introduce Synchronizer Token (Link only) Localize Disparate Logic (Link only) Merge Session Beans (Link only) Move Business Logic to Session (Link only) Move Class by Gerard M. Davison Move Field Move Method Parameterize Method Preserve Whole Object FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 31

32 Refactoring to Patterns FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 32

33 Refactoring + Patterns "Refactoring to patterns is a revolutionary approach to applying patterns that combines the top-down utility of design patterns with the bottom-up discovery of iterative development and continuous refactoring. FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 33

34 Design patterns Existem muitas formas possíveis de implementar/instanciar um padrão de software, umas mais simples, outras mais complexas e mais próximas da estrutura sugerida no padrão. Implementações minimalistas fazem parte do prática de design evolutivo. Muitas vezes, uma implementação não-baseada em design patterns tem que evoluir para poder incluir um padrão. Neste caso, pode-se fazer refactoring do design para uma implementação simples de um padrão. Isto é Refactoring to Patterns! FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 34

35 Direcções possíveis para refactoring Refactoring to (para)... Refactoring towards (no sentido de)... Refactoring away (de)... FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 35

36 Catálogo de Refactorings to Patterns Creation Simplification Generalization Protection Accumulation Utilities FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 36

37 Referências William F. Opdyke, Ph.D. diss., "Refactoring Object-Oriented Frameworks. " University of Illinois at Urbana-Champaign, Fowler, Martin. Refactoring: Improving the Design of Existing Code. Boston, MA: Addison-Wesley, Kerievsky, Joshua. Refactoring to Patterns. Addison-Wesley, FEUP/LEIC Ademar Aguiar Metodologias Ágeis de Desenvolvimento de Software, 2005/06 37