Série 3 Refactoring e Manutenção de Software

Salve! Salve! Mas uma semana e estou aqui marcando presença com mais uma serie Refactoring.  Onde vou abordar como Refactoring influencia na manutenção de software e a opinião de alguns autores consagrados no mundo T.I pensam a respeito. Espero que gostem dessa ultima série refactoring.

Recomendo quem puder compre o livro do Fowler, realmente é um excelente livro.  E para os que não “curte”  livro inglês a tradução está de parabéns, eu tenho tanto o inglês quanto e português e fiz comparações de vários capítulos com a obra original e nada de erros grosseiros no processo de tradução.

Let’s GO…

Outros post da Série/Other post of the series

1.Refatoração

2.Vantagens/Desvantagens e Ferramentas

Summary

This article presents as a refactoring can contribute for maintenance of software. Refactoring help a develop software more fast because avert that the project of the system if damage, bettering the process of maintenance and optimization of the time spent in the developing. Last refactoring contributes for maintenance of the software.

Cenário Manutenção Software

Segundo Maia (2004), o custo e a complexidade de se manter um Software são amplamente reconhecidos. Estima-se que cerca de 50% do tempo de um engenheiro de Software é gasto com tarefas de manutenção e compreensão de código.

De acordo com Pressman (1995) a manutenção de Software pode ser responsável por mais de 70% de todo o esforço despendido por uma organização de Software. E essa porcentagem continua aumentando à medida que mais Software é produzido. Para este autor manutenção de Software é bem mais que “consertar erros”. Há quatro atividades que são levadas a efeito depois que o Software é liberado para uso. São elas:

-A primeira atividade de manutenção ocorre por que não é razoável prevenir que a atividade de testes do Software decorrerá todos os erros latentes num grande sistema de Software. E durante o uso de qualquer programa, erros ocorrerão e serão relatados ao desenvolvedor.

-A segunda atividade que contribuiu para uma definição de manutenção ocorre por causa da rápida mudança que é encontrada em cada aspecto da computação. Novos sistemas operacionais, novas gerações de hardware por exemplo.

-A terceira atividade quando um pacote de Software é bem-sucedido. À medida que o Software é usado, recomendações de novas capacidades de modificações em funções existentes e de ampliações gerais são recebidas dos usuários.

-A quarta atividade de manutenção ocorre quando o Software é modificado para melhorar a confiabilidade ou a manutenção futura, ou para oferecer uma base melhor para futuras ampliações.

O custo da manutenção de Software tem aumentado firmemente durante os últimos 20 anos. Durante a década de 1970, a manutenção era responsável por um índice entre 35% e 40% do orçamento de Software para uma organização de sistemas de informação. Esse valor pulou aproximadamente 60% durante a década de 1980. Se nada for feito para melhorar a manutenção, muitas empresas gastarão 80% de seus orçamentos de Software em manutenção. Quanto mais eficiente for à fase de manutenção do Software mais fácil é de mantê-lo. (Pressman, 1995)

Refatoração e Manutenção

A refatoração pode ser considerada uma técnica ou ferramenta de auxilio no desenvolvimento e manutenção, contribuindo para o tempo de vida do Software, já que o acréscimo de novas funcionalidades é de maneira fácil e rápida. (FOWLER, 2004)

Para Pressman (1995), quanto mais eficiente for à fase de manutenção do Software mais fácil é de mantê-lo.

Em seu livro Fowler diz que um sistema mal projetado normalmente precisa de mais código para fazer as mesmas coisas muitas vezes porque o mesmo código foi duplicado em diversos lugares diferentes. Quanto mais difícil é visualizar o projeto a partir do código, mais difícil será preservá-lo e mais rapidamente ele se desestruturará. A eliminação de código duplicado é um aspecto importante na melhora do projeto, sendo que reduzindo a quantidade de código faz uma grande diferença sobre a manutenção desse projeto.

Fowler (2004) defende que quanto mais código houver em um Software, mas difícil será modificar corretamente.

“[…] Reduzir a quantidade de código faz, todavia, uma grande diferença sobre a manutenção desse código. Quanto mais código houver, mais difícil será modificá-lo corretamente. Há mais código para ser entendido. Você altera trecho de código aqui, e o sistema não faz o esperado porque faltou alterar em outro lugar que faz a mesma coisa em um contexto levemente diferente […]”. (FOWLER, 2004, p. 54)

Sendo assim a refatoração ajuda a desenvolver Software mais rapidamente porque evita que o projeto do sistema se deteriore, melhorando o processo de manutenção e otimização do tempo gasto no desenvolvimento. Enfim refactoring contribui para manutenção do software.

Tem dúvidas por que usar a técnica de refactoring no ambiente de desenvolvimento?

Infelizmente a série de refactoring foi curta, mas aqui foi apenas o first time. Em breve venho com a segunda parte da série onde pretendo abordar outros pontos importantes referente à técnica de refactoring e apresentá-la a nível de código.  Recebi alguns emails perguntando a diferença entre Extreme Programming (XP) e Refactoring veja abaixo para quem dúvida a respeito das praticas:

XP

Uma metodologia que foi responsável pelo crescimento da visibilidade de aplicar refatoração foi Extreme Programming (XP). Uma das principais idéias Extreme Programming é que o desenvolvedor deve trabalhar em apenas um caso de uso por vez e assim deve projetar o Software para que fique coerente com o caso de uso em questão. Se um determinado caso de uso não ficou bem projetado, deve-se aplicar refatorações até que o caso de uso possa ser implementado de uma maneira coerente. XP é uma metodologia que é baseada em mudanças. Um dos principais pilares de XP é a continua e agressiva aplicação de refatorações. Sem elas, XP não funcionaria. (MAIA, 2004)

Reflexão:

Espero que a série refactoring tenha contribuído para a vida de você programador, desenvolvedor etc. E que a partir de “ontem” essa técnica venha fazer parte do ambiente de desenvolvimento.

O ponto que me chamou atenção, é que as empresas de T.I cobram varias siglas ao fazer um processo de admissão, porém de 10 vagas que consultei nos maiores sites de empregos de T.I nenhuma delas “queriam saber se você programador, desenvolvedor sabe algumas das boas práticas de desenvolvimento”.

O máximo que foi possível encontrar nas vagas era Design Patterns. Achei isso preocupante. Mesmo que uma empresa tenha uma política interna de desenvolvimento é importante que essa política seja baseada em algo, por exemplo: na técnica de refactoring, XP. Não considero boas práticas as empresas que definem:

– Aqui somente usamos IDE X

– E todas as variáveis de instancia são private e deve ser escrita da forma Y

– Os acessos as variáveis somente por método

Um bom programador já DEVE já saber isso por natureza. Já que essa nomeação vem lá da O.O

O que quero chamar atenção para as empresas de T.I um engenheiro, um arquiteto etc. Que antes de cobrar tantas siglas (JSF,JSP, SERVLET etc) analise também a questão se esse profissional sabe alguma das boas práticas de desenvolvimento a nível de código. Desenvolver uma aplicação e colocar para funcionar é apenas 20% do projeto os outros 80% do trabalho vai estar na manutenção (se o desenvolvedor morrer ou sair da empresa o projeto pode falhar se ninguém entender o código desenvolvido).

Recentemente peguei uma aplicação de um “bom programador” (meu amigo) que ela atendia todos os pré-requisitos do cliente (para o cliente melhor aplicação do mundo, já que atendia todas as suas necessidades). Porém fui analisar o código (apenas por curiosidade) meu deus, quase tinha um infarto. De tanta duplicidade, modificadores aplicados de forma indevida, e os tamanhos de cada comentário daria um livro.

Tenham bastante cuidado com isso. Eu acredito que no futuro teremos vagas somente para “Reestruturar Software sem mudar o comportamento observável”.

Abraço! E até próximo post!

Referências

Fowler (2004)

Pressman, R. S. (1995). Engenharia de Software (3ª ed.).

MAIA, P. H. (2004). REFAX:Um arcabouço para desenvolvimento de ferramamentas de refatoração baseado XML. Programa de Pós Graduação em Ciência da Computação . Ceará, Fortaleza: UFC