REFACTORING

• ENTROPIA DE SOFTWARE

  • PROGRAMAS COMEÇAM NUM ESTADO BONITO, BEM PROJETADOS MAS, COM TEMPO, AS SUCESSIVAS ADIÇÕES E MUDANÇAS FAZEM O PROGRAMA PERDER SUA ESTRUTURA

  • RESULTADO FINAL: ESPAGUETE

• MOTIVOS

  • PROGRAMA MUDA EM FORMAS NÃO PREVISTAS

  • PROGRAMA NÃO É PERFEITAMENTE ENTENDIDO (MESMO SENDO NOSSO!) E O ENXERTO É MENOS PERFEITO DO QUE PODERIA SER

  • PRESSÕES DE TEMPO

  • SERIA MELHOR REPROJETAR O SISTEMA PARA LIMPÁ-LO, MAS PREFERIMOS EMPURRAR COM A BARRIGA

• REFACTORING É UM TERMO USADO PARA DESCREVER TÉCNICAS QUE DIMINUEM A DOR DE REPROJETAR

  • MUDANÇAS FEITAS A UM PROGRAMA QUE ALTERAM APENAS SUA ORGANIZAÇÃO, NÃO SUA FUNCIONALIDADE

  • TRANSFORMAÇÕES QUE PRESERVAM O COMPORTAMENTO

• POR QUE REFACTORING É IMPORTANTE?

  • A ÚNICA DEFESA CONTRA A ENTROPIA DE SOFTWARE

  • PARA CONSERTAR "BUGS" DE REUSABILIDADE

  • PERMITE ADICIONAR PADRÕES DE PROJETO APÓS ESCREVER O PROGRAMA

  • PERMITE TRANSFORMAR UM PROGRAMA NUM FRAMEWORK

  • DEIXA VOCÊ PENSAR NA GENERALIDADE AMANHÃ!

    • HOJE: BASTA DEIXAR FUNCIONANDO

    • PARECE ALGO ESTRANHO A DIZER, MAS VEREMOS QUE A TURMA DO EXTREME PROGRAMMING ACEDITA NISSO PIAMENTE!

  • NECESSÁRIO PARA SOFTWARE BONITO

• PROBLEMAS QUE REFACTORING PODE RESOLVER

  • CÓDIGO DUPLICADO

    • ELIMINA DUPLICAÇÃO COM NOVOS MÉTODOS, NOVOS OBJETOS, MOVENDO COISAS COMUNS NUMA SUPERCLASSE

  • MÉTODOS LONGOS

    • MÉTODOS DEVEM SER COESOS (SER LONGO É DICA DE QUE NÃO ESTÁ COESO)

    • MÉTODOS DEVEM CABER NUMA TELA

    • MÉTODOS DEVEM SER DO MESMO NÍVEL DE ABSTRAÇÃO

    • MÉTODOS DEVEM ESTAR NA CLASSE CORRETA

  • ACOPLAMENTO FORTE DEMAIS

  • LONGAS LISTAS DE PARÂMETROS

    • ENCAPSULA NUM OBJETO

    • MUDA O MÉTODO PARA ACESSAR O OBJETO

    • VÊ O QUE MAIS DEVERIA ESTAR NO OBJETO

  • SWITCH E VARIÁVEIS "TIPO-DE-OBJETO"

    • MUDAR PARA POLIMORFISMO

  • INTRODUZIR INTERFACES E AUMENTAR O POLIMORFISMO

• COMO FAZER REFACTORING?

  • NÃO FAÇA REFACTORING E ADIÇÃO DE FUNCIONALIDADE AO MESMO TEMPO

  • TENHA TESTES AUTOMÁTICOS PRONTOS ANTES DE FAZER REFACTORING

  • FAÇA MUDANÇAS MUITO PEQUENAS DE CADA VEZ E TESTE, TESTE, TESTE

• QUANDO FAZER REFACTORING?

  • QUANDO PARECE DIFÍCIL DE ENXERTAR NOVA FUNCIONALIDADE

  • SE UMA NOVA FUNCIONALIDADE ADICIONOU CÓDIGO FEIO

  • QUANDO VOCÊ NÃO AGUENTA OLHAR PARA SEU PRÓPRIO CÓDIGO!

EXTREME PROGRAMMING (XP)

• ALGUNS SUPER-PROGRAMADORES (E IRREVERENTES!) DE SMALLTALK DECIDIRAM CRIAR UM PROCESSO SIMPLES DE DESENVOLVIMENTO DE SOFTWARE

  • TALVEZ ACHANDO QUE OS OUTROS PROCESSOS ERAM COMPLEXOS?!?

  • WARD CUNNINGHAM, RON JEFFRIES, MARTIN FOWLER, KENT BECK

    • CUNNINGHAM E BECK SÃO A TURMA DO CARTÃO CRC

  • CUIDADO! XP FOI TESTADO PARA TIMES PEQUENOS E TALVEZ REQUEIRA EXCELENTES PROGRAMADORES. NÃO SE SABE A APLICABILIDADE GERAL DA TÉCNICA

  • NÃO É PARA QUALQUER UM, MAS PODE TER RESULTADO IMPRESSIONANTES

  • MUITA INFORMAÇÃO AQUI SOBRE ISSO. VALE A PENA CONFERIR.

• ALEGAÇÃO BÁSICA: SOFTWARE É DIFÍCIL DEMAIS PARA GASTAR TEMPO COM COISAS QUE NÃO SÃO IMPORTANTES

• ENTÃO, O QUE É IMPORTANTE?

  • CODIFICAR: SE, NO FINAL DO DIA, O PROGRAMA NÃO FUNCIONA E NÃO AJUDA O CLIENTE A GANHAR DINHEIRO, VOCÊ NÃO FEZ NADA

  • TESTAR: VOCÊ TEM QUE SABER QUANDO TERMINOU. OS TESTES DIZEM ISSO. SE VOCÊ FOR INTELIGENTE, VAI ESCREVÊ-LOS PRIMEIRO PARA SABER INSTANTANEAMENTE QUANDO VOCÊ TERMINOU

  • ESCUTAR: TEM QUE SABER QUAL É O PROBLEMA A RESOLVER. ESCUTE CLIENTES, GERENTES E PESSOAS DO NEGÓCIO

  • REFATORAR: VOCÊ TEM QUE ESCUTAR O QUE O PROGRAMA ESTÁ DIZENDO PARA VOCÊ SOBRE SUA PRÓPRIA ESTRUTURA E COLOCAR ESTE CONHECIMENTO DE VOLTA NO PROGRAMA

  • SE ALGUÉM FALAR PARA VOCÊ QUE FAZER SOFTWARE É OUTRA COISA (ALÉM DE CODIFICAR, TESTAR, ESCUTAR, REFATORAR), ELE ESTÁ TENTANDO LHE VENDER ALGO

    • NÃO FALEI QUE ERAM IRREVERENTES?!

• POR ISSO, INVENTARAM UMA DISCIPLINA DE DESENVOLVIMENTO DE SOFTWARE (XP) BASEADA NOS SEGUINTES VALORES:

  • SIMPLICIDADE

  • COMUNICAÇÃO

  • FEEDBACK

  • AGRESSIVIDADE

• AS PRÁTICAS DE XP FORAM DEFINIDAS PARA BALANCEAR AS FORÇAS AGINDO NO PROJETO

• RESUMO DO PROCESSO (COM LINKS PARA O WIKI)

  • PLANEJAMENTO FEITO COM O PlanningGame

    • AUTORIDADE É DELEGADA PARA OS CLIENTES DEFINIREM OS REQUISITOS USANDO UserStories (PARECEM USE CASES)

    • AUTORIDADE É DELEGADA PARA OS CLIENTES ESTABELECEREM AS PRIORIDADES DE DESENVOLVIMENTO DAS ESTÓRIAS

      • DESTA FORMA, O CLIENTE PODE MAXIMIZAR O BUSINESS VALUE (BusinessValueFirst)

    • AUTORIDADE É DELEGADA PARA OS DESENVOLVEDORES ESTIMAREM QUANTO TEMPO CADA ESTÓRIA LEVARÁ PARA SER DESENVOLVIDA

    • ESTA DELEGAÇÃO DE AUTORIDADE (QUE É RARA!) PROVÊ UM AMBIENTE DE DESENVOLVIMENTO LIVRE DE ESTRESSE

  • OS CLIENTES POSSUEM BOA INFORMAÇÃO SOBRE QUANTO TEMPO AS COISAS LEVAM E PODEM PORTANTO MAXIMIZAR O CUSTO-BENEFÍCIO DAS ESTÓRIAS QUE SÃO DESENVOLVIDAS PRIMEIRO

  • OS DESENVOLVEDORES POUCO SE IMPORTAM COM AS FUNCIONALIDADES PEDIDAS (O QUE TAMBÉM É RARO!), PORQUE ELES ESTIMAM QUANTO TEMPO AS COISAS LEVAM

  • JÁ QUE DELEGAR AS PRIORIDADES PARA O CLIENTE PODE SER PERIGOSO EM ALGUNS CASOS (PEDIR ALGO FUNDAMENTAL MAS DIFÍCIL NO FIM DO PROJETO É PERIGOSO!), HÁ UMA REGRA QUE BALANCEIA AS COISAS: AS PIORES COISAS SÃO ATACADAS PRIMEIRO (WorstThingsFirst)

    • SEMELHANTE AO PROCESSO UNIFICADO "RISK-CONFRONTING"

  • O TRABALHO É ACOMPANHADO ATRAVÉS DE UM CRONOGRAMA (CommitmentSchedule) REVISADO A CADA POUCAS ITERAÇÕES

    • PARA AVALIAR NOVOS RISCOS E OPORTUNIDADES

  • AS ITERAÇÕES SÃO PLANEJADAS (IterationPlanning) ENTRE DESENVOLVEDORES E CLIENTES

  • NADA É FEITO QUE NÃO SEJA IMEDIATAMENTE ÚTIL E NECESSÁRIO PARA NÃO IMPACTAR OS PRAZOS DE DESENVOLVIMENTO (YouArentGonnaNeedIt)

    • ELES NÃO ACREDITAM EM PENSAR MUITO NO FUTURO PARA SE PREPARAR PARA O QUE VEM DEPOIS

    • FAÇA FUNCIONAR O UserStory DE HOJE!

  • A SIMPLICIDADE SEMPRE REINA: SÓ SE USA A SOLUÇÃO MAIS SIMPLES QUE SATISFAÇA OS REQUISITOS DO PROBLEMA (DoTheSimplestThingThatCouldPossiblyWork)

  • AS DUAS REGRAS ACIMA (YouArentGonnaNeedIt E DoTheSimplestThingThatCouldPossiblyWork) ACABAM GERANDO CÓDIGO QUE PRECISA SER ALTERADO ÀS VEZES. PARA SIMPLIFICAR A MANUTENÇÃO/EVOLUÇÃO, O CÓDIGO TEM QUE ESTAR SEMPRE LIMPO E NÃO DUPLICADO. A REGRA É REFATORAR IMPIEDOSAMENTE (RefactorMercilessly).

• PARA TERMINAR ESTA INTRODUÇÃO, EIS A LISTA DE PRÁTICAS DE XP (LEIA CADA UMA DESSAS PRÁTICAS NO WIKI E RESUMA CADA UMA EM UMA FRASE NAS SUAS PRÓPRIAS PALAVRAS)

  • DoTheSimplestThingThatCouldPossiblyWork ENCORAJA NÃO SOBRE-PROJETAR (NEM SUB-PROJETAR)

  • AskTheCode PORQUE ELE SABE (... DIZER QUE PRECISA SER REFATORADO, ... DIZER ONDE ESTÁ O BUG, ...)

  • UnitTests: ESSA TURMA TESTA, TESTA, TESTA ... PARA NÃO QUEBRAR O CÓDIGO UM DO OUTRO. UNIT TESTES SÃO ESCRITOS PARA CADA CLASSE E TESTADOS USANDO O TestingFramework. TESTES DE UNIDADE PERTENCEM AO DESENVOLVEDOR.

  • FunctionalTests PARA TESTAR AS ESTÓRIAS E SABER SE AS NECESSIDADES DO USUÁRIO ESTÃO SENDO ATINGIDAS. OS USUÁRIOS FORNECERAM OS DADOS USADOS NESTES TESTES. TESTES FUNCIONAIS PERTENCEM AO CLIENTE.

  • ContinuousIntegration GERANDO UM PROCESSO ITERATIVO PARA EVITAR IntegrationHell. A INTEGRAÇÃO DE UMA NOVA VERSÃO DE ALGO (MESMO PEQUENO) É QUASE INSTANTÂNEA, LOGO DEPOIS DOS TESTES.

  • ContinuousIntegrationRelentlessTesting (COMO ACIMA, MAS LEMBRANDO QUE TEM QUE TESTAR, TESTAR E TESTAR)

  • RefactorMercilessly MANTÉM O CÓDIGO LIMPO O O PROGRESSO RÁPIDO (VER TAMBÉM WikiPagesAboutRefactoring). SÓ FUNCIONA BEM SE TIVER MUITOS TESTES PARA SE ASSEGURAR DE QUE NÃO QUEBROU NADA.

    • RECOMENDA-SE CHEGAR À ExtremeNormalForm

    • "Your classes are small and your methods are small; you've said everything OnceAndOnlyOnce and you've removed the last piece of unnecessary code.

      Somewhere far away an Aikido master stands in a quiet room. He is centered.. aware.. ready for anything.

      Outside a sprinter shakes out her legs and settles into the block, waiting for the crack of the gun while a cool wind arches across the track.

      Softly, a bell sounds.. all of your tests have passed.

      Your code is in ExtremeNormalForm.. tuned to today and poised to strike at tomorrow."

  • ProgrammingInPairs PROVÊ QUALIDADE MAIS ALTA, TREINAMENTO MÚTUO E VELOCIDADE MAIS ALTA. USE UMA PESSOA MENOS EXPERIENTE NO TECLADO E UMA MAIS EXPERIENTE JUNTO.

  • SpikeSolution SOLUÇÕES EXPLORATÓRIAS RÁPIDAS PARA CERTOS PROBLEMAS

  • ModelFirst MAIS SpartanUserInterface AJUDAM A MANTER O FOCO NAS NECESSIDADES DO USUÁRIO. SpartanUserInterface SIGNIFICA FAZER UMA INTERFACE SIMPLES E DEIXAR O USUÁRIO USAR, MELHORAR O QUE ATRAPALHA, JOGAR FORA O QUE NÃO É USADO ATÉ QUE O RESULTADO SATISFAÇA.

  • ExtremePlanning BOLAR UM MAPA RÁPIDO DA SOLUÇÃO GLOBAL COM REFINAMENTOS INCREMENTAIS

  • PlanningGame PARA FORMALIZAR OS PAPEIS E RESPONSABILIDADES NO PLANEJAMENTO

  • CountDownToRelease DISCUTE COMO USAR ExtremePlanning QUANDO A DATA DE RELEASE FINAL SE APROXIMA. AS REGRAS:

    • DEIXA O CLIENTE DECIDIR O QUE FALTA ATÉ SOLTAR O PRODUTO

    • REUNIÃO SEMANAL PARA TRATAR DE IterationPlan

    • StandupMeeting DIÁRIO RÁPIDO

  • ExtremeReuse ADOTANTO SOFTWARE DE TERCEIROS E ADEQUANDO-O A XP PELA CONSTRUÇÃO DE TESTES

  • TossIt PARA FAZER E MANTER PROJETOS MAGROS, JOGUE O QUE NÃO PARECE ÚTIL PELA JANELA. NÃO PRECISA SER MANTIDO, DOCUMENTADO, ETC.

  • SystemMetaphor FORMAS DE COMUNICAR O SISTEMA PARA OUTROS E OS PRÓPRIOS DESENVOLVEDORES. OUTRAS PALAVRAS PARA ARQUITETURA

    • POUCA COISA: ALGUMAS CLASSES, ALGUNS PADRÕES, ...

  • XpDesign QUEM PROJETA EM XP E QUANDO?

    • SOLUÇÃO: O TIME (PEQUENO) INTEIRO USANDO CRC

  • ExtremeDocuments DOCUMENTAÇÃO FAZ PARTE, EMBORA ELA SEJA DIFERENTE ÀS VEZES

    • PARA REQUISITOS: UserStories E FunctionalTests (SIM! TESTES FUNCIONAIS SÃO REQUISITOS QUE DEVEM SER SATISFEITOS! PENSE SOBRE ISSO ...)

    • PARA ANÁLISE E DESIGN: NENHUM DOCUMENTO, SÓ CARTÕES CRC

    • PARA CODIFICAÇÃO: UM COMENTÁRIO POR CLASSE, SE NECESSÁRIO

    • SE O USUÁRIO QUISER UM DOCUMENTO, MANUAL, ETC. É SÓ FAZER UM UserStory PEDINDO!

  • SupportCrisis O QUE FAZER QUANDO A M..... BATE NO VENTILADOR?

    • REGRA 1: PAREÇA CALMO (NÃO PRECISA SÊ-LO, SÓ PARECER)

    • REGRA 2: ESCREVA CADA PROBLEMA NUM CARTÃO

    • REGRA 3: ATRIBUA UM FATOR DE URGÊNCIA A CADA CARTÃO

    • REGRA 4: TRATE DE UM CARTÃO DE CADA VEZ. FAÇA O PRIMEIRO. FAÇA O SEGUNDO, ... ATÉ QUE A CRISE VÁ EMBORA.

FRAMEWORKS

• O QUE É UM FRAMEWORK?

  • UM CONJUNTO CLASSES COESAS QUE COLABORAM PARA COMPOR UM PROJETO REUTILIZÁVEL PARA UMA CLASSE ESPECÍFICA DE SOFTWARE

  • A ARQUITETURA É DEFINIDA PELO FRAMEWORK

    • O FRAMEWORK DIZ:

      • COMO É A ESTRUTURA DO SOFTWARE

      • COMO ESTÁ PARTICIONADO EM CLASSES E OBJETOS

      • AS RESPONSABILIDADES-CHAVE DAS CLASSES E OBJETOS

      • COMO OS OBJETOS COLABORAM

      • COMO É O THREAD DE CONTROLE

  • O FRAMEWORK CONTÉM CLASSES CONCRETAS E (MAIS IMPORTANTES) CLASSES ABSTRATAS E INTERFACES QUE DEVEM SER OBEDECIDAS NA SOLUÇÃO FINAL

  • PARA UTILIZAR O FRAMEWORK, PRECISA-SE NORMALMENTE DEFINIR SUBCLASSES DE CLASSES EXISTENTES E ESTENDER OS SERVIÇOS DO FRAMEWORK PARA RESOLVER UM PROBLEMA PARTICULAR

  • AS CLASSE ABSTRATAS FREQUENTEMENTE CONTÊM MÉTODOS CONCRETOS (COMPORTAMENTO DEFAULT)

  • USA O "HOLLYWOOD PRINCIPLE"

    • "DON'T CALL US, WE'LL CALL YOU"

    • CLASSES DEFINIDAS PELO USUÁRIO DO FRAMEWORK RECEBERÃO MENSAGENS DAS CLASSES PREDEFINIDAS DO FRAMEWORK

    • HÁ PORTANTO UMA INVERSÃO DE CONTROLE ENTRE O SOFTWARE DO USUÁRIO E O SOFTWARE DO FRAMEWORK (COMPARADO COM UMA BIBLIOTECA, POR EXEMPLO)

• PERMITE QUE O DESENVOLVEDOR SE CONCENTRE APENAS NAQUILO ONDE SUA APLICAÇÃO É DIFERENTE DO "NORMAL"

• UM FRAMEWORK É MUITO DIFÍCIL DE CONSTRUIR, NORMALMENTE E DEMORA MUITO A ATINGIR A MATURIDADE

  • O ARQUITETO APOSTA QUE UMA ARQUITETURA SERÁ SUFICIENTEMENTE GERAL PARA MUITAS APLICAÇÕES DE UM CERTO TIPO

• NÃO MOSTRAREMOS AQUI COMO PROJETAR FRAMEWORKS

  • FICA PARA OUTRA DISCIPLINA!

  • REQUER USO DE DESIGN PATTERNS E UM GRANDE PODER DE GENERALIZAR CASOS CONCRETOS

  • FRAMEWORKS ESTÃO SE TORNANDO EXTREMAMENTE IMPORTANTES

• EXEMPLOS:

  • CONSTRUÇÃO DE APLICAÇÕES

  • DESIGN GUI

  • FRAMEWORKS PARA EDITORES GRÁFICOS

  • PLATAFORMAS DE GERÊNCIA DE REDES

  • TEM UM BELO EXEMPLO SIMPLES AQUI: UM FRAMEWORK PARA TESTES EM JAVA

    • O CÓDIGO FONTE INTEIRO ESTÁ AQUI