Ao fabricar um produto orgânico, um dos cuidados que se deve ter é com a validade da matéria-prima. O que acontece caso um item de matéria-prima esteja vencida?
E mesmo não sendo um item perecível, como saber a hora que ele deixa de ser útil?
Dia 4 de abril de 2014 ocorreu mais um evento do GUMA, sendo este especial pelo fato do mesmo estar completando 10 anos de existência, então o evento todo foi em ritmo de festa e comemorações.
Eu e o Guilherme Lacerda conduzimos um Dojo de PHP para a galera treinar um pouco de TDD, OO, comunicação e trabalho em equipe.
Abaixo seguem algumas fotos, bem como link para os slides e repositório com código fonte da solução para o problema proposto (Cifra de César).
Refatoração de código (Code Refactoring) é uma disciplina/processo que consiste em melhorar a estrutura interna de um software sem modificar seu comportamento externo, e uma Refatoração de Banco de Dados (Database Refactoring) parte do mesmo princípio, porém além de manter o comportamento externo também deve manter a semântica da informação que ele mantém/armazena, e por esse motivo é considerada mais difícil.
Um outro conceito que posso destacar a respeito de Database Refactoring é:
“Mudança disciplinada na estrutura de uma base de dados que não altera sua semântica, porém melhora seu projeto e minimiza a introdução de dados inconsistentes”
O ponto interessante deste último é o texto “minimiza a introdução de dados inconsistentes“, pois esse é o grande objetivo de realizarmos um refactoring na estrutura de um banco de dados, ou seja, melhorar o desing atual para melhorar a consistência dos dados e também a qualidade dos novos dados que serão adicionados ao seu banco de dados.
E esta tarefa não é das mais simples, pois existe um fator preponderante no que diz respeito a dificuldade de execução deste tipo de refactoring, que é o acoplamento.
Acoplamento
Figura 1. Baixo Acoplamento
É a medida de dependência entre dois elementos. Quanto mais acoplados dois elementos estiverem, maior a chance que a mudança em um implique na mudança em outro.
Simples assim, quanto mais o seu banco de dados estiver acoplado, ou seja, dependente de diversas aplicações externas, mais difícil será a aplicação de um refactoring.
Figura 2. Alto Acoplamento
A figura 1 demonstra um cenário “Single-Database Application” que é bem simplificado, onde a aplicação de um refactoring será mais tranquilo.
Com certeza o cenário da Figura 2, o “Multi-Database Application” é o pior caso, pois exige muito cuidado e planejamento para execução do refactoring, então veremos a seguir uma sugestão de processo para execução.
Processo de refatoração
Figura 3. Processo de Database Refactoring
Um processo é um conjunto organizado de atividades com um objetivo em comum. Executar um database refactoring em um cenário “Single-Database Application” ou “Multi-Application Database” requer um processo, por mais simples que seja. A grande diferença na execução em ambos cenários é que no caso do “Multi-Application Database” o período de transição (mais abaixo falaremos) geralmente será mais longo.
É bom sempre ter em mente que um database refactoring, como já vimos, não é uma atividade simples então caso seja identificada a real necessidade de refatorar um banco de dados então podemos usar o seguinte roteiro (processo) para se guiar:
Na Figura 4 é demonstrado um pequeno processo descrevendo um fluxo básico para aplicação de um refactoring.
Figura 4. Regra Geral Processo Refatoração
Atente bem para o “Período de Transição”, que é a fase mais importante, principalmente para cenários “Multi-Database Application” (Figura 2), onde você precisa ter em mente que não conseguirá realizar o refactoring e fazer o deploy em produção de todas as aplicações ao mesmo tempo. A grande verdade é que muito provavelmente você nem consiga alterar todas as aplicações ao mesmo tempo, principalmente se você tiver dependência de terceiros, então você precisará suportar o esquema original e o esquema resultante ao mesmo tempo, para somente quando todas aplicações estiverem suportando apenas o esquema resultante, ou novo esquema, você poderá aposentar de vez o antigo esquema e assim finalizar este período.
Estratégias de Database Refactorings
Existem alguns pontos a considerar com estratégias para adoção de um database refactoring:
Os items acima mostram apenas algumas sugestões, em forma de “lições aprendidas”, de algumas estratégias que você pode considerar quando tiver a necessidade de realizar um refactoring.
Para apoiar essas estratégias existe um catálogo que descrevem diversos tipos de refactorings em bancos de dados e exemplos de uso, que veremos a seguir.
Este catálogo é dividido em algumas categorias:
No meu github é possível encontrar exemplos práticos de aplicação passo-a-passo de um refactoring em um modelo inicial, passando por um período de transição e chegando ao modelo final.
Considerações Finais
Baseado no exposto podemos facilmente responder a pergunta “Por quê Refatorar?”:
E para refatorarmos precisamos ter conhecimento, disciplina, simplicidade, bom senso e persistência, sem contar no ponto fundamental que é organização.
Referências
Palestra realizada no FISL 2013 sobre cultura de aprendizagem por Rafael Helm e Guilherme Elias.
Nesta palestra Rafael e Elias falam sobre algumas ações que empresas e equipes podem realizar para disseminar conhecimento entre as pessoas, criando assim um ambiente de aprendizagem e melhoria contínua.
Estamos disponibilizando os exemplos de implementação de feature toggles usando design patterns (Strategy e Factory/Template Method), com arquivos de configuração.
Espero que gostem!
Já está disponível os slides da palestra realizada em Fortaleza, no AgileBrazil 2011. Em breve, disponibilizaremos também os exemplos de Feature Toggle. O mais legal é que, no mesmo dia de nossa palestra, Martin Fowler e Mike Mason gravaram um vídeo abordando o mesmo problema.
Atualização em 04/07: Já estão disponíveis os exemplos de feature toggle.
Já está disponível a apresentação realizada no dia 01/julho no WSL – Workshop de Software Livre, evento acadêmico vinculado ao Fórum Internacional de Software Livre – FISL 12. O trabalho descreve a implementação de um módulo de gestão de projetos, baseado em práticas do SCRUM para a ferramenta Expresso Livre. Este trabalho foi desenvolvido em conjunto com Rafael Raymundo (SERPRO) e o Prof. Vinicius Gadis Ribeiro (FACENSA/UniRitter).
Nesta semana, acontecerá o AgileBrazil, Conferência Brasileira de Métodos Ágeis. Esta segunda edição ocorre em Fortaleza (CE), com palestras dedicadas a diversos temas e assuntos, relacionados a indústria e academia.
Nós, do CbE, estaremos lá com a palestra “Trunk Based Development Explored”. Em breve, postaremos mais sobre a palestra e exemplos de código desenvolvidos.
Para iniciar os artigos do Blog, eu gostaria de relatar um pouco da minha experiência com desenvolvimento de software e sua relação com as Metodologias Ágeis. Descobri o desenvolvimento de software por acaso, através de um curso profissionalizante Técnico em Processamento de Dados (TPD) que iniciei em 1993, seguindo alguns amigos. No início, eu não estava muito interessado, até conhecer o universo da Programação. Descobri que aquilo me fascinava e, de certa forma, me desafiava também. Comecei a fazer fluxogramas, algoritmos até o meu primeiro programa em BASIC. Aquela experiência foi decisiva para a definição da minha carreira profissional.
Dali em diante, depois do uso de quase duas dezenas de linguagens de programação, alguns cursos e muito aprendizado e softwares desenvolvidos, estou aqui para compartilhar com vocês um pouco destas experiências.
A primeira e mais inusitada foi a descoberta das metodologias ágeis. Em 1996, eu era bolsista em uma Universidade, tinha entrado no Curso Superior, cheio de expectativas e anseios. No setor onde trabalhava (Assessoria Especial de Planejamento/Apoio Técnico Pedagógico), basicamente digitava textos. Em horários de folga, estudava novas tecnologias e procurava novos desafios. Em outubro deste mesmo ano, vi que os chefes do setor criaram uma espécie de questionário de avaliação, denominado Avaliação Institucional, que seria aplicado a professores e alunos. Esta era também uma exigência do MEC.
Quando olhei aqueles formulários, pensei diretamente no desenvolvimento do software. Muita empolgação, pouca experiência…
Inicialmente, este projeto seria desenvolvido pelo CPD da Instituição, onde trabalhavam grande parte dos professores. Quando disse que tinha condições de desenvolver o projeto, os chefes ficaram apreensivos, mas compraram a idéia. Para iniciar o projeto, precisei chamar um colega meu de TPD e de faculdade, que poderia trabalhar meio turno comigo. Fizemos uma reunião inicial com o coordenador do projeto (chefe do CPD) e conversas diárias com os chefes do setor de Planejamento.
A minha sala era muito pequena, razão pela qual tinha apenas uma máquina (486 DX2 66 Mhz) e uma impressora matricial IBM 132 colunas. Combinei com este meu colega de trabalharmos juntos pela manhã no projeto e a tarde eu desenvolvia mais algumas funções do software além do trabalho do setor, que não podia parar.
A tecnologia que utilizamos na época era Clipper, versão 5.2.
Pegamos aqueles formulários e após algumas análises preliminares, conseguimos esboçar um modelo conceitual. Como havia apenas um computador, trabalhamos juntos, ora eu pilotando, ora ele. Tivemos que realizar alguns trabalhos de importação, parte da base COBOL da Instituição e outra parte de uma base ZIM, do Recursos Humanos.
Foi muito interessante o nosso aprendizado, pois conseguimos produzir um código muito enxuto, cada vez mais otimizado e sem gerar desperdício, pois o cliente estava ali na sala ao lado para acompanhar e direcionar as funcionalidades do projeto. Cada vez que percebíamos uma oportunidade de melhoria, realizávamos. Procurávamos ter versões diárias, sempre verificando e validando informações com os usuários/clientes. Concluímos esta versão em dois meses. A primeira versão compreendia funcionalidades básicas de operação e módulo de digitação para professores e alunos. Ficou para depois o desenvolvimento de relatórios gerenciais, até porque o pessoal do setor não os tinha definido. Este software funcionou em 8 Campi Universitários, fazendo o registro de questionários de mais de 9 mil alunos. Nos anos seguintes, exigiu pouquíssima manutenção.
Até onde sei, este sistema funcionou até 2002, pois saí da Instituição em 2000.
Algumas práticas importantes:
Em 1997, comecei a trabalhar com OO e Smalltalk. Programei por dois anos nesta linguagem, onde tomei conhecimento de alguns trabalhos e pessoas envolvidas com a tecnologia, entre eles o de Kent Beck.
Passaram-se alguns anos e, em 2001, através de conversas com o Klaus Wuestefeld, fiquei sabendo um pouco mais sobre eXtreme Programming. Quando vi o nome de Kent Beck e qual era o objetivo deste processo, tive certeza que funcionava. Foi paixão a primeira leitura. Quanto mais eu estudava, mais eu lembrava do projeto de Avaliação Institucional que, através do sucesso obtido e da satisfação do cliente, foi um degrau muito importante na minha vida. Embora já tivesse estas convicções, decidi que iria desenvolver software focado na comunicação efetiva, simplicidade, feedback e respeito do cliente, tendo como base os princípios ágeis.
