Refatorando Mindset
No decorrer do desenvolvimento de software muitos encontram-se no seguinte dilema: desenvolver novas funcionalidades ao sistema ou refatorá-lo para suportá-las?
A decisão se torna crucial a medida que as funcionalidades no topo do backlog geram valor para o cliente, porém caso seu código não esteja preparado para tais mudanças pode ser impossível implementá-las ou até mesmo mante-las.
Como Scrum Master passei por momentos em que a refatoração se fez necessária, mas a questão que me vinha a cabeça era: A refatoração é responsabilidade do Time de desenvolvimento, Líder técnico,Gerente da área ou é um débito atrelado ao projeto que deve ser compartilhado com o Product Owner e Stakeholders?
Por ser uma tarefa técnica, pesquisei sobre referências no assunto e decidir escrever esta postagem para ajudar outros com este tema tão delicado.A ideia não é sair com uma definição sobre a estratégia a ser seguida, mas o que deve ser considerado!
Quais motivos levam um código a ser refatorado?
O objetivo principal da refatoração é reescrever um código com o intuíto de facilitar o entendimento para outra pessoa sem mudar o seu comportamento atual. Segundo Martin Fowler, um programador passa maior parte do tempo lendo o código do que “codando”, ou seja, quanto mais legível for o código maior será o entendimento e consequentemente será mais rápida sua modificação.
Dentre o motivo já mencionado de legibilidade e manutenibilidade. Outros fatores também devem ser considerados:
- Rotatividade: No decorrer do desenvolvimento do projeto diversos profissionais de diferentes níveis e entendimento sobre o projeto podem atuar no time.Caso estes não tenham a preocupação em deixar o código simples e de fácil entendimento pode ser necessário refatorar este código.
- Yuck: Uma técnica interessante para saber se algo precisa ser refatorado é quando você ver um código que você não tem orgulho(Indigesto)mesmo que não seja seu mas que não mostraria a ninguém é uma boa prática refatora-lo para que o próximo não tenha essa mesma sensação.
- Difícil entendimento: Quando você não consegue mais entender facilmente a lógica de um código e depois de algum tempo “digerindo” passa a enteder é uma boa iniciativa após este momento de reflexão que você refatore essa lógica para que o próximo a ler não perca este tempo.Um amigo sempre usa a seguinte frase:
Sotware se faz com empatia então pense no próximo desenvolvedor que irá atuar neste código fonte.
- Produtividade: Como dito antes, um desenvolvedor eventualmente lê mais código do que escreve e esse tipo de mudança otimiza o entendimento e leitura de todo time.
Codifique sempre como se o cara que for dar manutenção seja um psicopata violento que sabe onde você mora(Use a cabeça JAVA — Kathy Sierra e Bert Bates)
- Tecnologia: Com a constante evolução da tecnologia é possível que novos recursos incentive a refatoração de um código.Por exemplo:Um app escrito em Objetive-C pode ser refatorado em Swift para obter todos os benefícios da nova linguagem sem mudar o comportamento padrão.
- Arquitetura: As metodologias ágeis pregam ciclos curtos de desenvolvimento e validação. Pela característica dos projetos estarem em constante evolução, muitas vezes são adaptados para atender funcionalidades não antes planejadas e para suporta-lás a arquitetura do projeto deve ser modificada.
- Evolutiva: Naturalmente no desenvolvimento de software você já deve ter criado uma lógica que anteriormente fazia todo sentido e hoje faria diferente. Esse também é um fator relevante para que ao revisitar esse código ele seja alterado.
- Melhoria contínua: Fazendo analogia ao termo:The Boy Scout Rule(Regra do Escoteiro) deixe o seu código melhor do que você o encontrou. Sugere uma abordagem alternativa, que é simplesmente tentar e garantir que com cada commit, você deixar o código melhor do que você o encontrou. Talvez apenas ligeiramente. Seguindo este princípio, as equipes podem melhorar a qualidade de seu código ao longo do tempo, enquanto continua a oferecer valor aos seus clientes e partes interessadas.
De quem é a responsabilidade da refatoração em um projeto ?
Levando em consideração os motivos já mencionados e as metodologias ágeis o time de desenvolvimento tem as pessoas mais qualificadas para indicar quando um código ou projeto deve ser refatorado.Porém outros papeis são decisivos para disseminar esta cultura.
Líderes técnicos- Eles precisam saber as técnicas de refatoração para mentorar o time e auxiliar para que seja feita de forma escalável. Dessa forma, é evitado que se dependa de um “Herói da situação” e aumenta o engajamento do time.
Scrum Master- Este papel tem como responsabilidade manter o Framework e dar suporte aos demais papéis em prol do objetivo do projeto, ou seja, ele pode auxiliar o time e alinhar com os envolvidos sobre os beneficios da legibilidade do código.
Product Owner/Product Manager e Stakeholders- Segundo Martin Fowler as pessoas de negócio não deveriam ser convencidas de que a refatoração é importante,pois é dever do time de desenvolvimento manter o código saudável para que seja economicamente viável adicionar novas features.Esse é um ponto que discordo,visto que, o código assim como as regras de negócio evoluem durante o tempo e como qualquer mudança exige esforço e faz parte da transparência que todos os envolvidos saibam o que esta acontecendo e quais benefícios serão gerados com a refatoração. Outro ponto deve ser considerado é que cada alteração no código existente pode causar efeitos colaterais.
Quais itens devem ser considerados em uma refatoração?
- A refatoração deve ser feita em pequenas doses e não deve ser deixado na mão de apenas uma pessoa.
- Escolha um mentor para guiá-lo e ele tem o papel de disseminar o conhecimento entre o time. Algumas pessoas aprendem melhor através de mentoria do que através de um livro.
- Livro Refactoring: Improving the Design of Existing Code (Martin Fowler) ou site https://martinfowler.com/tags/refactoring.html
- Livro Test Driven Development: By Example(Kent Beck)
- Filipe Deschamps — Canal youtube usei muitos conceitos dele.
- Apresentação Martin Fowler @ OOP2014 “Workflows of Refactoring”
- Refactoring: Second Edition — A Conversation with Martin Fowler
- Tem que PRATICAR!
Contudo, o mais importante é ter em mente os benefícios da refatoração e ser uma prática do dia-a-dia e não uma situação sem escapatória no qual caso não seja realizada inviabilize todo o projeto. Refatoração pode ser um item na nossa Definition of Done para nos lembrar que sempre podemos melhorar algo.
Outras postagens:
O Testamento de um Scrum Master
O Tripalium não dignificar o Homem!
Delegation Board — Você sabe delegar?
Como contratar um Scrum Master?
Sobre
Roberto Martins
Scrum Master
ti.robertomartins@gmail.com