Design Ágil: salve seu software do apodrecimento

Olá galera,

Neste post falarei sobre design de software, passando pelos principais design smells e discutindo sobre o que ocasiona o apodrecimento do código. Finalizo mostrando uma luz no fim do túnel, com o processo de design ágil.

Boa jornada!

Para começar, o que é design de software? Dando uma “googlada”, vamos encontrar várias definições que se assemelham com “o ato de transformar os requisitos de usuário em software” (ou transformá-los em um documento para que seja repassado ao programador, eca!).

Podemos esclarecer melhor?

Podemos! Primeiro dizendo o que o design NÃO É. O design não é um diagrama ou conjunto de diagramas UML. Talvez essa associação direta com um diagrama venha da própria palavra design (que, além de “projeto”, pode ser traduzida por “desenho”, “esboço”, “planta”, entre outros). Diagramas colaboram para representar o design, ou partes dele, mas não é o design.

O design de um software é algo abstrato, ligado diretamente à estrutura do software, seus módulos, classes e métodos. De uma forma mais simples, podemos dizer que o código-fonte do software É o design.

O QUE LEVA AO APODRECIMENTO DO SOFTWARE?

Os indícios de que um software está apodrecendo são chamados de design smells. Abaixo vou dar uma passada em cada um deles (aposto que vocês já os conhecem bem!):

Rigidez – um software é rígido quando ele é difícil de mudar. Uma “simples” mudança requer uma série de mudanças em cascata em vários módulos dependentes. É aquele típico caso que o programador pensa que é simples (1 dia, por exemplo) e acaba levando 1 semana para entregar.

Fragilidade – uma mudança em uma parte do código acaba quebrando várias outras partes. Muitas vezes, as partes danificadas sequer tem relação conceitual com a parte alterada. Um módulo ou funcionalidade muito frágil está constantemente na lista de bugs e muitas vezes o programador tem medo de mexer ali. Junte isso à falta de testes automatizados e teremos funcionalidades “explodindo” em tempo de execução (e no pior caso, em produção!).

Imobilidade – temos este problema quando identificamos partes do design que podem ser reutilizadas em outros softwares, mas o risco e esforço de extraí-las do software original é muito grande, seja pela alta rigidez ou fragilidade daquelas partes.

Viscosidade – há dois tipos: viscosidade do software e do ambiente de desenvolvimento. A viscosidade do software ocorre quando mudar o código preservando o design é mais difícil do que mudá-lo usando algum atalho (ou gambiarra). Em outras palavras, é mais fácil fazer do jeito errado do que do jeito certo! A viscosidade do ambiente, que também afeta o design, ocorre quando o ambiente de desenvolvimento é ineficiente. Por exemplo, se um check-in no servidor é muito lento, os programadores começarão a ser guiados por essa lentidão, fazendo mudanças no código que exijam poucos check-ins, sendo a qualidade do design preservada ou não.

Complexidade desnecessária (overdesign) – O design contém elementos desnecessários, criados na ânsia de se atender funcionalidades futuras, que muitas vezes nem chegam a se tornar realidade. Tentando prever inúmeras situações e garantir que qualquer alteração futura seja o menos traumática possível, o programador acaba inflando o design, deixando-o complexo demais para ser entendido. Lembrem-se: KISS e YAGNI!

Repetição desnecessária (redundância) – Essa talvez seja a mais famosa: DUPLICAÇÃO DE CÓDIGO. O programador do tipo “ctrl-c, ctrl-v” espalha a mesma porção de código por várias partes do sistema, dificultando a manutenção do mesmo. (Este daria um post só pra ele! É triste!)

Opacidade – essa trata da pura dificuldade de entender o código. O código não expressa o negócio, é desorganizado, com nomes confusos.

Podemos afirmar, então, que um software apodrece quando atinge um nível muito alto de design smells. De leve odor passamos para cheiro de carne podre.

E por que chegamos à essa situação? Sabemos que mudanças nos requisitos podem levar à degradação do software, mas será que são elas as grandes vilãs? Um programador comum normalmente diz que sim. Ele culpa as constantes mudanças no software pelos atuais smells.

Este tipo de mentalidade vem da cultura tradicional de desenvolvimento, que luta contra mudanças, que amarra contratos tentando evitá-las de todas as formas e que trabalha no “design” (leia-se documentação e diagramas) do software primeiro, como uma etapa única, antes da codificação. É a ideia de que “como já se investiu muito tempo no início com o design, não há porque ficar mudando”(Leia sobre BDUF – Big Design Up Front).

Nesse contexto anti-mudanças, mudanças acabam degradando o software porque o programador não está preparado para elas e nem quer estar. Ele não vê aquela mudança como uma oportunidade de melhorar o design e sim como algo que veio para lhe incomodar e quer se livrar dela o mais rápido possível.

Então, o programador faz o mais simples, aquela “gambizinha-ninja” que resolve logo o problema. Meses depois, uma nova mudança naquele mesmo código leva-o a incrementar sua “gambi” e assim sucessivamente, até que aquele trecho de código se transforme em um monstro.

O programador, neste contexto, se esquece que ele é um PROFISSIONAL e que, como tal, deveria manter procedimentos básicos para a sustentabilidade do software! Triste mas verdade….

DESIGN ÁGIL

Um programador ágil não deixa o software apodrecer, porque, em primeiro lugar, ele aceita mudanças!! Afinal a única coisa que sabemos logo de início em um projeto de software é que HAVERÁ MUDANÇAS. Sendo assim, a missão do programador é garantir que o software permaneça sadio mesmo após inúmeras mudanças.

Em segundo lugar, o design ágil de software é feito de forma incremental, conforme os programadores vão aprendendo sobre o negócio e o software em si. Em cada iteração, o design deve ser mantido o mais apropriado para os requisitos daquela iteração e o mais limpo possível, combatendo design smells assim que são identificados.

Quando uma mudança aparece, devemos enxergá-la como oportunidade de melhorar o design. Por exemplo, se o cálculo de uma taxa em um Pedido tiver que ser alterado para permitir 2 tipos de cálculo, pode ser uma oportunidade de melhorar o design de modo que o cálculo possa ser feito usando estratégias diferentes (Padrão Strategy) ao invés de encher o código de “if..else’s” e ver-se obrigado a alterar o método toda vez que surgir uma forma de cálculo diferente (ferindo o Open-Closed Principle).

Entretanto, é preciso conhecimento para que o design seja melhorado. Em um processo de design ágil, o programador deve conhecer princípios de design para que possa identificar um design smell e design patterns, para que possa resolvê-los.

CONCLUSÃO

Design smells, aliados à falta de cultura favorável a mudanças de requisitos (o que leva à negligência por parte dos programadores), colaboram para o apodrecimento do código, gerando enormes gastos com manutenção, insatisfação do cliente e até mesmo a morte do software.

Seguindo práticas ágeis e aplicando princípios e design patterns, o programador ágil zela pela qualidade do design, prolongando a vida útil do software. Esta contínua aplicação de práticas, princípios e padrões para manter o design legível, bem estruturado e flexível, constitui o processo de design ágil.

Mas cuidado! Um programador ágil não sai aplicando princípios e design patterns indiscriminadamente para não gerar overdesign. Eles devem ser aplicados para resolver um problema, normalmente um design smell, quando este de fato existir.

Já falei sobre o design pattern Strategy <aqui> e em post futuros voltarei a falar sobre design, outros padrões e alguns dos princípios de design OO mais conhecidos.

E então…você está pronto para ser um programador ágil?

————————————————–
Referência:
Martin, Robert C. Martin, Micah. 2007. Agile Principles, Patterns, and Practices in C#. Prentice Hall.

Anúncios

6 comentários em “Design Ágil: salve seu software do apodrecimento

    1. Olá, Stefano
      Fico feliz com seu comentário. É bom saber que está sendo útil 🙂
      Nos últimos tempos tenho focado os posts mais em boas práticas do que em ferramentas/frameworks.
      []s e estamos aí!

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s