Posts Tagged Engenharia de Software
Refatoração
Posted by Godoy in Engenharia de Software on October 30th, 2008
Refatoração é a técnica ou um processo no qual melhora-se a parte não funcional de um sistema sem alterar seu comportamento funcional. Quê? Vamos por partes..
Quantas vezes (digo isso por experiência própria) temos que fazer sistemas, ou mesmo criar um módulo para um sistema, e você escuta a célebre expressão: “é pra ontem” ? Não digo que o sistema ficará uma droga, ou que não funcionará, mas o código ficará pobre: trechos duplicados, má indentação, métodos longos, de difícil entendimento. Enfim, o tempo que seria gasto para fazer o trabalho “bem feito”, será gasto quando o sistema necessitar de manutenção/alteração.
É aí que pode entrar a refatoração. Um sistema bem feito, de código limpo e com métodos que “generalizam” a funcionalidade pode ser reaproveitado posteriormente para outros sistemas que necessitem dessas mesmas funcionalidades. A idéia seria, após o sistema ser entregue dentro do prazo exigido, voltar com o projeto para a linha de produção. Os programadores revisam todo o código, retirando as “impurezas” e deixando um código limpo, buscando um melhor desempenho e generalizando ao máximo os métodos.
Situações em que refatorar é interessante:
1- Quando você tem que adicionar uma funcionalidade a um programa e o código do programa não está estruturado de uma forma que torne a implementação desta funcionalidade conveniente, primeiro refatore de modo a facilitar a implementação da funcionalidade e, só depois, implemente-a.
2- Quando se implementa uma nova funcionalidade às pressas, refatore e transforme essa funcionalidade em um módulo, para reaproveitamento em outros sistemas.
3- O código foi tão “porcamente” escrito, que dois meses após o desenvolvimento, se o projeto retornar para manutenção, nem mesmo a equipe que desenvolveu consiguirá compreender a lógica de negócio. Então, antes que o projeto perca o foco dos desenvolvedores, refatore.
Alguns indícios que sugerem a refatoração (retirados da wikipedia):
- Código duplicado (duplicated code)
- Método longo (long method)
- Classe grande (large class)
- Lista de parâmetros longa (long parameter list)
- Má indentação(Bad Indentation)
Links sobre o assunto:
Wikipedia
Martin Fowler – Refactoring
Métodos Ágeis – devagil.wordpress.com
Desenvolvimento de Software – Dr. Analista
Posted by Godoy in Engenharia de Software on September 15th, 2008
1- Desenvolva software iterativamente
2- Gerencia Requisitos
3- Utilize arquiteturas baseadas em componentes
4- Utilize modelagem visual
5- Verifique qualidade continuamente
6- Mantenha alterações sob controle
Se você trabalhasse em uma empresa pequena, com recursos limitados, onde você pudesse escolher apenas um destes itens, qual você escolheria?
Essa pergunta foi feita por meu professor, na aula de Engenharia de Software.
De certo modo, todos os 6 itens estão relacionados e, na teoria, são indispensáveis. Mas e se de fato tivéssemos que escolher um deles para seguir rigorosamente?
De nada adianta o desenvolvimento iterativo sem qualidade. Não estou de forma alguma desmerecendo o RUP e o desenvolvimento iterativo. Muito pelo contrário, cada vez que me aprofundo no estudo de processos de desenvolvimento rápido, mais interessado fico. O que quero dizer é que em nada adianta repetir fases do processo à medida que o desenvolvimento avança, se o processo for uma merda ruim.
De maneira análoga, não resolve muita coisa uma arquitetura baseada em componentes, se os componentes não possuirem qualidade, se foram mal projetados.
Acredito que, como ocorreu na aula, a grande maioria ficaria entre os itens 2 e 4. De fato, um dos problemas que mais afetam uma empresa pequena é a análise incorreta dos requisitos. Após desenvolvido, o software retorna várias vezes porque não estava do modo que o cliente queria. E a culpa é de quem? Do cliente que não disse desde o início o que queria? Ou do analista que não soube abstrair da conversa com o cliente as informações de que precisava? Veja bem, quando estou passando mal e vou ao médico, tenho que dizer todos os sintomas de forma detalhada? “Senhor médico, estou com dor de cabeça. Além disso, estou com a perna direita doendo, tem uma áfita na minha boca (no canto superior esquerdo), minha unha está incravada e estou tendo alucinações. Ah.. e faz 3 dias que não me alimento.”
É claro que não é assim que deve funcionar. “Estou com dor de cabeça” ou “Preciso de um software para X”. E o médico/analista é quem deve realizar as devidas inferências, para identificar as causas do problema, e decidir o melhor modo de resolver o problema.