Design ágil é um processo continuo de princípios, modelos, e praticas visando a melhoria da arquitetura do software.
Design de uma aplicação não são apenas diagramas UML. Os diagramas UML podem representar partes do design, mas ainda não é o design propriamente dito. O design de um software é um conceito abstrato que representa de uma forma macro a estrutura do sistema como um todo e ao mesmo tempo de forma detalhada cada módulo, classe e método.
O design pode ser representado por diversas maneiras, mas no fim das contas, o código fonte é a principal fonte de design. Um design mal feito, consequentemente um código mal desenvolvido, pode acelerar o processo de decomposição do software, sendo que a velocidade de decomposição de um software está diretamente ligada à sua qualidade, ou seja, quanto maior a velocidade de decomposição do software, menor é a qualidade. Para evitar tal decomposição, deve-se ficar atento aos sintomas ou odores que o software exala.
Desenvolvedores ágeis se dedicam para manter o design coeso, limpo, e livre de sintomas ou odores sempre que possível. Eles sabem como fazer isso porque sempre seguem alguns passos antes de escrever qualquer linha de código:
1. Eles acham o problema seguindo praticas ágeis;
2. Eles analisam o problema aplicando princípios de design;
3. Eles resolvem o problema aplicando o modelo de design apropriado ao caso.
Dificilmente um software perfeito livre de defeitos é produzido por alguém. O que pode ser feito para minimizar os defeitos no fim do processo e em sua manutenção, é ter conhecimento dos motivos que levam um software a decompor. Um software suscetível à decomposição exala os seguintes odores:
Rigidez: Rigidez ocorre quando é necessário um grande esforço para alterá-lo, mesmo quando a alteração é pequena.
Fragilidade: Fragilidade é a tendência que o programa tem para dar problema em diversos pontos quando uma única alteração é feita.
Imobilidade: Imobilidade ocorre quando o software contém muitas partes que podem ser reaproveitadas em outros softwares, mas para reutilizar essas partes é necessário um grande esforço junto com um alto risco, pois não foram planejadas para ser reutilizadas. Logo, uma grande parte do sistema terá que ser levada junto sem necessidade nenhuma.
Viscosidade: Um projeto viscoso é aquele que quando uma alteração é necessária, devido ao seu design não planejado para trabalhar de forma componentizada, fica difícil fazer a alteração do modo correto, gerando desvios para que a alteração seja mais fácil e mais rápida de programar.
Complexidade desnecessária: Acontece quando o design do sistema é superdimensionado e implementado para prever situações que nem sequer foram especificadas. Isso torna o software complexo demais e difícil de entender.
Redundância desnecessária: Acontece muito quando o programador necessita do mesmo código utilizado em outra função para resolver um problema, porém com algumas alterações. Acontece que isso acaba gerando redundância de código tornando a manutenção difícil e trabalhosa já que o erro deve ser corrigido em todas as repetições de código.
Opacidade: Opacidade é a falta de clareza na hora de escrever o código fonte. Muitas vezes o código é legível apenas para quem o programou. Isso pode ser evitado utilizando padrões na hora de escrever o código e fazendo com que outras pessoas revisem o código.
Rigidez: Rigidez ocorre quando é necessário um grande esforço para alterá-lo, mesmo quando a alteração é pequena.
Fragilidade: Fragilidade é a tendência que o programa tem para dar problema em diversos pontos quando uma única alteração é feita.
Imobilidade: Imobilidade ocorre quando o software contém muitas partes que podem ser reaproveitadas em outros softwares, mas para reutilizar essas partes é necessário um grande esforço junto com um alto risco, pois não foram planejadas para ser reutilizadas. Logo, uma grande parte do sistema terá que ser levada junto sem necessidade nenhuma.
Viscosidade: Um projeto viscoso é aquele que quando uma alteração é necessária, devido ao seu design não planejado para trabalhar de forma componentizada, fica difícil fazer a alteração do modo correto, gerando desvios para que a alteração seja mais fácil e mais rápida de programar.
Complexidade desnecessária: Acontece quando o design do sistema é superdimensionado e implementado para prever situações que nem sequer foram especificadas. Isso torna o software complexo demais e difícil de entender.
Redundância desnecessária: Acontece muito quando o programador necessita do mesmo código utilizado em outra função para resolver um problema, porém com algumas alterações. Acontece que isso acaba gerando redundância de código tornando a manutenção difícil e trabalhosa já que o erro deve ser corrigido em todas as repetições de código.
Opacidade: Opacidade é a falta de clareza na hora de escrever o código fonte. Muitas vezes o código é legível apenas para quem o programou. Isso pode ser evitado utilizando padrões na hora de escrever o código e fazendo com que outras pessoas revisem o código.
Todos esses odores são pontos extremamente importantes que devem ser considerados ao desenvolver um software. Em ambientes não ágeis, o design de um sistema degrada pois os requisitos mudam de uma forma que o design inicial não previa causando a mudança do design original, tornando-o desorganizado e ineficaz.
Um time ágil investe um pouco a mais no design inicial para tornar o sistema resistente a mudanças evitando que ele apodreça.
Nos próximos posts vou falar sobre os princípios de design ágil que podem ser utilizados para evitar o apodrecimento do software. Esses princípios são: Divisão de responsabilidades, Aberto / Fechado, Substituição de Liskov, Inversão de dependências e Segregação de interfaces.
Um comentário:
Belo post.
Espero que continue com mais discas sobre desenvolvimento agil.
Postar um comentário