Ubiquitous Language

Sempre que encontro com meus amigos guitarristas é uma festa... O assunto principal, como não poderia deixar de ser, é sempre sobre guitarras e tudo que essas preciosidades podem fazer. Falamos sobre as pickups que nossos ídolos utilizam, se vamos colocar jumbo frets em nossos necks para obter maior sustain, comentamos sobre os tipos de bridge que mais gostamos, entre outros assuntos.

Não está entendendo nada desse assunto? Não esquenta, somente nós guitarristas (malucos) entendemos. Essa é a nossa linguagem, a que usamos normalmente para comunicar nossas ideias e nossa paixão pela música.

Imagine uma situação hipotética, na qual esse grupo de amigos tivesse encomendado a uma equipe de programadores um sistema de controle de guitarras, um software no qual pudéssemos encontrar e colocar todo o tipo de informação pertinente da nossa área de atuação. De que modo você pensaria em modelar esse sistema? Qual seria um design apropriado para esse problema?

Um programador com linguagem puramente técnica tentaria explicar como desenvolveria o sistema usando DAOs, controladores, queries, Design Patterns e outras coisas que nada tem a ver com a área (apenas me deixando preocupado se ele realmente teria entendido) o negócio que gostaríamos de ver solucionado.

De outra forma, um programador poderia aproveitar o nosso vocabulário para modelar uma solução que usasse a nossa linguagem como apoio para o design. Nesse modelo, ele me mostraria como criaria guitarras, pickups, tremolos e repositórios diretamente na solução. Deixaria bem claro como esses elementos estão associados usando a mesma linguagem que nós utilizamos normalmente. A essa linguagem damos o nome de ubiquitous language.


Repare onde a ubiquitous language naturalmente se encontra, um meio-termo que une especialistas em domínio com especialistas em tecnologia:

A ubiquitous language é fundamental para o Domain Driven Design, metodologia que foca na construção de sistemas a partir do desenvolvimento (e isolamento) de um rico domain model, capaz de resolver problemas com eficiência e apoiado na linguagem que os usuários utilizam no dia a dia.

Eric Evans nos dá a direção:

"Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communications within the team and in the code. Use the same language in diagrams, writing, and especially speech. Recognize that a change in the ubiquitous language is a change to the model."

Nós devemos ser capazes de desenvolver sistemas que comuniquem bem seu design para os usuários que realmente o utilizarão. Mantenha apenas o modelo, código e testes como artefatos permanentes do desenvolvimento. Use a linguagem no dia a dia e a incorpore em todo o lugar, dos diagramas de classe aos códigos Java e C#. Isole o domain model e deixe o aparato técnico para ser discutido apenas por especialistas em tecnologia.

Próximos posts veremos como a arquitetura DDD é feita de forma a permitir o isolamento desse domain model.

Curso agile pronto

Fala pessoal!
Tudo bem?

O curso agile ficou pronto e já saiu do forno... Montei um compacto das melhores práticas de engenharia do XP com as práticas de gestão de projetos do Scrum.

Modéstia à parte, ficou bem bacana. hehehe

Quem quiser conferir clique aqui.

Abração e qualquer dúvida é só postar que eu respondo. :)

Formação Agile

Fala pessoal!

Ando meio sem tempo para postar por conta da formação agile que estou criando em parceria com o Infnet.

Será um mix de Scrum e XP com muita informação legal para desenvolvedores e gestores.

Aguardem notícias muito em breve aqui no blog!

Abraços.

Agile Project Management

Debates fervorosos acontecem, atualmente, na comunidade de gestão de projetos de sotware. O grande centro das discussões encontra-se na questão sobre qual seria a melhor metodologia a ser aplicada no gerenciamento desses projetos. Devemos seguir as boas práticas do PMBOK ou aplicar uma abordagem ágil, utilizando métodos como Scrum e XP? Minha resposta: devemos sempre adotar o que for melhor para cada projeto em particular.

Não devemos gerenciar projetos no estilo "by the book". Procurar por cartilhas que nos digam exatamente o que fazer é um caminho perigoso e que tem poder de levar um projeto ao fracasso. Um profissional sério deve se aprofundar no conhecimento dos frameworks e metodologias existentes no mercado para, como um médico, diagnosticar um quadro geral e indicar o tratamento mais adequado. É preciso entender a situação primeiro para depois poder traçar uma estratégia coerente, um plano de ação que seja eficaz para o case específico.

E por que não mesclar as técnicas para preencher as lacunas que cada método possui?

Podemos estar gerenciando com foco no PMBOK e mesmo assim aplicar técnicas ágeis como abordagem iterativa, cliente-onsite e reuniões de retrospectivas. Analogamente, podemos utilizar Scrum e aplicar técnicas como gestão de riscos e construção de uma visão para o produto. Conhecer mais ferramentas dá maior poder de escolha para o gestor, evitando vícios como a incessante procura pela "bala de prata" das metodologias, comportamento que engessa a atuação de qualquer profissional (não apenas de gestão).

Sendo assim, independente do método utilizado, há sempre dois pontos que são os mais importantes em qualquer projeto (especialmente os de software): pessoas e comunicação. Qualquer abordagem que priorize os complexos relacionamentos que existem entre os interessados de um projeto, facilitando a comunicação entre os envolvidos e buscando dar mais autonomia e responsabilidade às pessoas tem muito mais chance de terminar com sucesso.

Verdades e Mitos sobre a Programação Orientada a Objetos

1- Objetos são "abstrações" do mundo real.  

Mito. Objetos nem sempre representam "coisas" do mundo real. Eles são unidades especializadas compostas por dados e comportamento, que atuam de forma colaborativa para compor uma aplicação. Podem ou não representar algo do mundo real. Por essa definição, tanto um servlet, um dataset ou um cliente podem representar objetos válidos em um sistema. A confusão se dá devido às instâncias de classes que representam conceitos de um domínio e que são chamadas de business objects. Essas são bastante valiosas para vários tipos de aplicações, pois servem como Domain Model do negócio que o software pretende atender, com suas regras de negócio, linguagens compartilhadas e necessidades específicas (abordagem da técnica conhecida como Domain Driven Design).

Obs: objetos que não possuem comportamento são conhecidos como objetos anêmicos, termo cunhado por Martin Fowler para designar entidades "burras" que funcionam apenas como depósito de dados.

2 - O Desenvolvimento OO é mais lento.

Verdade. Aplicações OO são compostas de pequenas classes especializadas nas várias funcionalidades que uma aplicação necessita para atender a uma área de negócio. O foco é nas entidades que realizam o processo e não no seu fluxo (marcante no desenvolvimento procedural). Há "seres" responsáveis em gerenciar conexões, executar cálculos, mapear dados, imprimir relatórios, gerar visualizações, etc. A criação dessas classes demanda um esforço inicial maior por parte do time de desenvolvimento - esforço que será recompensado por uma maior facilidade de manutenção, reutilização e evolução do software em questão.

Obs: esse atraso no desenvolvimento é parcialmente compensado pelo uso de frameworks que auxiliam na construção da infra das aplicações como mapeamento de entidades, segurança, configuração e logs.

3 - Programar em Java ou C# gera automaticamente software OO.

Mito. O desenvolvimento OO começa na mente do programador. É, acima de tudo, uma forma de design. Linguagens como Java, C# e VB.Net são ótimas pois permitem que o design OO imaginado  pelo projetista/programador seja facilmente implementado pelo time de desenvolvimento. Elas são equipadas de recursos como herança, polimorfismo, encapsulamento e permitem a criação de classes, objetos, interfaces, enumerações, etc. Porém, sem o domínio de como fazer design OO, estaremos usando essas ferramentas, na melhor das hipóteses, para gerar um código procedural "disfarçado" de software OO.

4 - Para aprender OO é preciso aprender UML.

Mito. A Unified Modeling Language (UML) é uma excelente ferramenta para comunicar ideias de modelagem, ajudando no processo de desenvolvimento de uma determinada aplicação. Entretanto, ela não ajudará na construção do design da solução. Em outras palavras, sem a atitude mental correta, servirá  apenas para modelar perfeitamente uma aplicação ruim. O interessante da UML é o fato de ser uma forma de notação conhecida por inúmeros desenvolvedores ao redor do globo, possibilitando uma linguagem de modelagem comum para o time e outros stakeholders do projeto. Profissionais de OO experientes utilizam a UML para modelar soluções de forma livre em white boards e/ou ferramentas case (geralmente em conjunto com outros membros do time). Outro benefício (secundário) da UML é a possibilidade de geração de documentação.

5 - Programadores mais antigos têm dificuldades com OO.

Verdade. A última década consolidou o modelo de desenvolvimento OO, principalmente devido à popularização do Java e ao crescimento da plataforma .Net. Por que então tantos programadores ainda têm dificuldades com esse paradigma? A resposta é simples: a maioria desses programadores com dificuldades foi formada sob a ótica procedural e ao desenvolvimento orientado a banco de dados. A programação OO vira o mundo desses profissionais de cabeça pra baixo, propondo uma forma diferente de se construir software, com a promessa de gerar aplicações mais fáceis de manter (e estender) e mais resistentes a mudanças, requisitos-chave para atender às exigências do mundo moderno.

6 - A programação OO favorece a reutilização.

Verdade. A criação de várias instâncias de objetos de uma mesma classe já é um grande exemplo, por si só,  de reutilização de código. Cria-se a classe apenas uma vez. Instâncias de objetos são obtidas com base nessa "forma" que molda as características e o comportamento da entidade. Outras formas de reutilização são a componentização e o uso de patterns (Design Patterns e Architectural Patterns).

O futuro das Fábricas de Software

Há tempos venho discutindo com alunos, colegas e amigos sobre a ineficácia do modelo atual de  trabalho das "fábricas de software". O post de Fabio Akita, no BlogInfo, trouxe à tona esse debate novamente. Ok, ok. Admito que o autor foi meio radical em sua tese ao condenar - por completo - todo o modelo, mas é inegável que essas fábricas, da forma como existem hoje, estão com os dias contados.

Uma razão para seu declínio é, talvez, o fato delas estarem focadas no modelo waterfall de desenvolvimento e nas práticas Tayloristas e Fordistas de produção. Como já discuti aqui no blog, nesse post, não adianta (pelo menos não na maioria das vezes) tentar um caminho preditivo e baseado em uma rígida divisão de papéis. Nesse ambiente, há uma super-especialização do trabalho, ou seja, o analista não programa, o programador não testa, o gerente só se ferra e por aí vai...

Os problemas acontecem pois fábricas de software não estão organizadas de forma a maximizar as chances de um projeto ser bem sucedido, pois não dão a liberdade necessária para que a inovação aconteça, ingrediente fundamental para se criar efetivamente software de alta qualidade e valor agregado ao negócio. Projetos que hoje são bem sucedidos, são realizados por equipes que se envolvem em todas as fases do processo, com constante troca de papéis e colaboração entre as pessoas do time.
 

As fábricas de software irão acabar? Evidentemente, não tenho (e  acredito que ninguém tenha) essa resposta. Meu melhor palpite é que sobreviverão as que souberem reinventar o próprio negócio, incorporando elementos como requisitos ágeis, escopos negociáveis, times auto-organizados e outras práticas fundamentais.

Quem viver, verá...

Como trabalham os desenvolvedores profissionais?

Esses dias estive pensando a respeito de práticas de programação que são comuns a todos os desenvolvedores profissionais que conheço. Apesar de haver estilos e características diferentes em cada um deles, há um conjunto de atividades que eles compartilham quase sempre. Portanto, resolvi agrupar uma "lista" dessas atividades principais e divulgá-las aqui no blog.

Vamos à lista:

Desenvolvedores profissionais...

Estudam muito, sempre. 

Eles bebem de várias fontes. Fazem cursos, leêm as obras mais relevantes da área, frequentemente conhecem mais de uma linguagem (e plataforma), gostam de "fuçar" para obter mais conhecimento e estão sempre praticando e testando novas ideias. Para esses profissionais, o importante é aprender sempre e estar  em constante evolução. 

Gostam de compartilhar conhecimento. 

Desenvolvedores profissionais, geralmente, são membros ativos de blogs, grupos de discussão e comunidades. Ajudam seus colegas de trabalho a entenderem técnicas e conceitos importantes, disseminando o conhecimento por todos da equipe. São definitivamente pessoas altruístas e com grande sentimento de colaboração e cooperação. 

Escrevem seus próprios testes.

Desenvolvedores profissionais escrevem seus próprios testes. Como Phillip Calçado expôs nesse excelente post , é bobagem achar que um desenvolvedor profissional não deva produzir seus próprios testes unitários automatizados. Pior ainda é considerar que ninguém deva produzir esses testes alegando questões de prazo e/ou custo. Leia esse post do José Papo e entenda por que isso é um contra-senso  econômico.

Escrevem código para pessoas e não para máquinas.

Qualquer um pode escrever alguma coisa que compile e funcione. Entretanto, somente os profissionais escrevem código limpo, claro e organizado que pessoas conseguem entender e manter. O design é feito pensando nos outros programadores - os que irão passar a maior parte do ciclo de vida do sofware mantendo o produto.

Refatoram de forma disciplinada e habitualmente. 

Na vida real todos nós sempre temos um prazo e um budget. Desenvolvedores sérios sabem disso e são comprometidos com as necessidades de seus clientes. Para respeitar esse prazo, muitas vezes entregam uma solução que ainda não consideram como "excelente" e, para resolver esse problema, assumem e se responsabilizam pelo "débito técnico" gerado, refatorando o código de forma habitual e controlada (obviamente, sempre possuem uma suíte de testes automatizados para tornar a tarefa possível).

Evoluem com o design tendo o business em mente.

Desenvolvedores profissionais criam soluções, de forma incremental, que reflitam o negócio da empresa (e do cliente) em primeiro lugar. Desenvolvedores sérios trabalham com técnicas que facilitem a criação de uma aplicação que contenha elementos comuns a todos os stakeholders do projeto da organização. Geralmente indicam o livro do Eric Evans, "Domain Driven Design", como leitura  obrigatória (e realmente considero um excelente livro).

Enfim, essas são as atividades que considero comuns aos desenvolvedores profissionais. Servem como uma "luz" para o nosso próprio desenvolvimento profissional.

E você? Acredita que há mais atividades importantes?

Comente...