Where are we missing the way?
Em termos de desenvolvimento de software, sempre emcontramos divergências entre os paradigmas e soluções. Para resolver problemas no processo, recomendamos metodologias ágeis que, quando não bem interpretados, dão a entender que basta pegar algumas idéias e sair codificando. Para resolver problemas com o design, flexibilidade escalabilidade, sugerimos planejamento prévio e alguma documentação.
Para a equipe é importante possuir documentação, quando iniciar o desenvolvimento e, a rotatividade de profissionais em caso de projetos grandes, obriga que exista ao menos documentação técnica, definida com padrões e diretrizes a serem seguidas.
Então, como obter o melhor dos dois mundos? Como conciliar as duas abordagens?
Arquitetos de software e desenvolvedores são seres esquisitos e muito ocupados, que geralmente não tem vida social e pouquissímo senso de necessidade. Isso os leva a separar aquilo que deveria ser feito do que será feito. Frases como “Eu sei que aqui deveríamos fazer dessa forma, mas não dá tempo!” ou “Isso aqui foi feito assim, mas nós vamos refatorar isso pra que fique do jeito certo!”, nos passam a idéia de urgência. “Temos que entregar o sistema logo, senão cabeças vão rolar!”.
O que é urgente?
A palavra urgência derivada do latim urgentia, representa a qualidade do que é urgente. Algo que tem pressa, necessidade imediata. Também está relacionada com o voerbo urgir, que significa apertar, impelir, comprimir, não permitir delongas. Dessa forma, aquilo que é urgente na verdade é algo inadiável, que urge, que não admite delongas e que é necessário fazer-se rapidamente.
Imagine essa definição num contexto de desenvolvimento de softwares. Não sei para vocês, mas para mim soa como um mal cheiro no processo. Tudo aquilo que é urgente nos impele a agir de forma mecânica, sem pensar muito. Quando somos pressionados a fazer coisas às pressas, deixamos de lado boas práticas e abandonamos conceitos importantes, tudo por causa de algumas horas de impaciência de algum gerente de projeto. Isso não seria problema se fosse ocasional, mas o fato é que a maioria dos projetos sofre de urgência desde o início.
As consequências disso são catastróficas para o projeto. Código mal escrito, workarounds (pra não falar gambiarras mesmo!) e vários “Bad Smells” distribuidos pela aplicação. Porém a pior das consequências vem na parte de Design do software. O arquiteto fica sempre ocupado ajudando os desenvolvedores a resolver coisas urgentes que acaba deixando de trabalhar no design da arquitetura, seja para criar um design uniforme, ou memso para refatorar o design existente.
O que é importante?
Desenvolver software é uma arte e, como todo tipo de arte e, depende de um trabalho meticuloso para atingir um ponto satisfatório. Definir a arquitetura de um software, envolve diversas questões a serem respondidas e demandam tempo. Em geral, os arquitetos deixam de lado a simplicidade do modelo e se preocupam mais com questões de infrestrutura, segurança e afins e esquecem do design. Não digo que essas questões não sejam importantes, mas sei que o design merece uma atenção especial. Conceber um modelo de objetos para um determinado tipo de negócio é de extrema importância, e deve ser trado como tal.
Então o que há de errado com o que é importante? Nada! Porém o que é importante sempre é minimizado em prol do que é urgente. As equipes de desenvolvimento de software e arquitetura de systemas devem assumir que sempre o que é importante é prioritário, mesmo em relação ao que é urgente. Estamos falando de uma quebra radical de paradigma, que pode trazer divergências junto aos stakeholders do projeto. Sobre essa questão, sugiro a leitura do meu artigo “Uma questão de percepção” disponível no blog.fratech.net .
Away from OO
Após definir o que realmente é importante em seu projeto de software, a equipe deve preparar-se para utilização de boas práticas de desenvolvimento. O principal erro é criar modelos carregados de máquinas, de forma desordenada e nada similar à realidade.
É comum encontrarmos classes com nomes estranhos, como, PasswordValidator, PersonUnificator, UserIndentificator ou coisas desse tipo. Na verdade estamos realizando programação orientada a prestadores de serviço, sem nenhuma abstração do mundo real.
Domain Driven Design – What is this?
Anecessidade de se desenvolver um software é intimamente relacionada a solução de um problema, ou à evolução de um serviço. A orientação a objetos tem por objetivo facilitar a representação virtual do mundo real e, por isso, ao modelar um software, devemos ter em mente a realidade da situação que desejamos atender. Isso é denominado Domain Model.
Domain significa entre outras coisas “a esfera de conhecimento, inlfuencia e atividade”, por isso o domain de um negócio é a esfera de conhecimento, influência e atividades do negócio.
Domain Driven Design representa uma mudança no paradigma de desenvolvimento, rebuscando princípios da orientação a objetos, com o objetivo de melhorar a simplicidade e objetividade do sistema, facilitando a comunicação e utilização dos artefatos gerados no processo.
Orientar o desenvolvimento ao domínio do negócio nos obriga a investigar quais são os objetos que compõe o domínio do negócio. Por experiência, a melhor forma de se entender o domain de um negócio específico é conversando com os domain experts. Pessoas que conhecem profundamente as regras e detalhes sbre o negócio em questão e, não estamos falando aqui de analistas funcionais, mas sim, de pessoas que vivem o dia-a-dia da situação.
O Processo de Design
Desenhar um sistema utilizando Domain Driven Design ou qualquer outra técnica, devemos dedicar um esforço de tempo necessário. Nem pouco tempo, nem muito tempo. Normalmente se inicia o estudo sem muita idéia de qual é a real complexidade do negócio e dando menos importância aos requisitos não funcionais, como segurança e infraestrutura. Dedicar um tempo apenas para modelar os objetos de domain é fundamental para um bom design de qualquer sistema.
Mas como fazer isso quando o processo é baseado em uma metodologia ágil?
A impressão que as metodologias ágeis deixam é que não há tempo para perder com planejamento. Precisamos implementar as funcionalidades de acordo com o que o cliente pede primeiro. Em uma abordagem como essa, corremos o risco de acabar em um projeto extremamente bagunçado e sem estruturação em termos de design.
É fundamental que ao iniciar a implementação de um sistema, os desenvolvedores tenham uma referência sobre como o projeto deve se parecer. Entender o contexto da situação que envolve o sistema e, principalmente saber onde e como os metodos devem ser dispostos.
O design deve ser tratado como uma outra tarefa qualquer dentro do processo. Criar uma design macro da arquitetura e exemplificar como implementar algumas situações devem fazer parte do backlog do projeto. O modelo deve ser flexível e oferecer a possibilidade de evolução incremental, sendo incrementado sempre que uma tarefa específica exigir. Modificações mais abrangentes e de maior impacto devem ser tratadas como uma tarefa a parte e, ser acompanhado de perto pela equipe inteira.
Ao utilizar Domain Driven Design para modelar um software, estamos assumindo a premissa de que o modelo do software é um retrado apurado do negócio, portanto só deve ser alterado se o negócio como um todo sofrer alguma alteração. Nesse caso é imprescindível a participação do Product Owner e tamém dos Domain Experts, para assegurar que o novo modelo é coeso com a evolução do negócio.
The Language
Através do conceito de Ubiquitous Language (Linguagem Difundida) a utilização do Domain Driven Design também contribui para um outro aspecto do processo. A comunicação entre a equipe e o cliente. O cliente pode não saber nada sobre desenvolvimento de software e também não é obrigado a estudar um modelo incoeso, porém conhece profundamente o negócio para o qual o software está sendo desenvolvido. Quando os objetos e os nomes dos metodos são coesos com a realidade, fica fácil conversar com o cliente, auxiliando na visualização do software e, aumentando a percepção do cliente para o que está sendo feito.
Permanecer sempre alinhado ao negócio sempre é uma boa prática que traz produtividade e dinamismo ao desenvolvimento, porém é importante oferecer esforço e dedicação para que isso acontece. Na balança do que é válido, isso é sempre viável.
Abraços a todos!
