A preguiça, o medo e o otimismo.

Somos seres humanos, logo somos cheios de "defeitos de fabricação". Disso quase ninguém duvida. Está programado no nosso DNA, fruto de anos e anos de evolução e seleção natural. Por isso, somos capazes de fazer coisas boas e ruins ao mesmo tempo. Ironicamente, é esse mix de defeitos e qualidades que nos torna únicos e molda a nossa humanidade, fazendo com que  sejamos, por exemplo, mesquinhos e solidários, egoístas e amorosos, medrosos e companheiros,  invejosos e prestativos, e por aí vai...

É óbvio gostamos de nossos amigos e familiares exatamente da forma como são, com todo o conjunto de imperfeições e qualidades que possuem e é por isso que perdoamos os seus pequenos  "desvios de comportamento" (ok, ok, sei que às vezes não são tão pequenos assim). Entretanto, quando o assunto é trabalho, as coisas precisam ser diferentes. Acredito que para alcançar a excelência, um profissional (e não apenas de software) precisa monitorar 3 vícios de comportamento; são eles: a preguiça, o medo e o otimismo.

A Preguiça

Qual ferramenta devemos usar sempre? Java ou .Net? Linux ou Windows? Que padrão podemos utilizar em todos os projetos? Vamos trabalhar de forma ágil ou tradicional? A equipe irá trabalhar com SCRUM ou com o guia PMBOK embaixo do braço? Essas (e outras) questões são corriqueiras nas rodas de profissionais. Na verdade, é a manifestação da já famosa "preguiça mental". Nosso cérebro (preguiçoso) insiste na procura da "bala de prata", ou seja, uma maneira única e universal capaz de solucionar todos os problemas.

A explicação é simples: se encontramos uma maneira única para tratar todas as situações liberamos tempo e energia para outras tarefas mais interessantes, seja no trabalho ou fora dele. É por causa desse vício de comportamento que muitas soluções são descartadas de imediato, simplesmente por estarem "fora do padrão" ou por não respeitarem uma regra qualquer que deveria ser seguida à risca, não importando o contexto da situação no momento.

Monitore esse mau hábito constantemente. Saiba que geralmente há mais de uma solução para solucionar um mesmo problema. Estude diversos padrões, tecnologias e métodos. Posso ser fã de DDD mas isso não significa que irei utilizar a técnica em todos os projetos que terei que tocar ao longo da carreira. O mesmo acontece com o universo das metodologias: podemos trabalhar com métodos ágeis e aplicar outras metodologias ao mesmo tempo, obtendo assim resultados muito melhores e adaptados à realidade do negócio em que estamos inseridos. Preste atenção ao contexto, isso é o mais importante. Explore a diversidade.

O Medo

"Agile não presta, é só um modismo da garotada". "PMBOK só serve para aumentar a burocracia no projeto". "Vai usar .Net? Tá maluco!" Essas e outras pérolas são ouvidas diretamente no trabalho, na faculdade, nos fóruns e em outros eventos comuns de TI. É simplesmente o medo falando mais alto. A ciência já sabe: nós dominamos (e populamos) nosso planeta porque somos uma espécie medrosa. Por exemplo, se um antepassado das cavernas visse uma sombra remotamente parecida com um tigre ele não pensaria duas vezes: "daria no pé", mesmo que fosse apenas um coelho inofensivo. Qualquer eclipsezinho solar e todo mundo já se reunia chorando para pedir perdão pelo "fim do mundo" próximo.

Não se engane: esse instinto do "lute ou fuja" está em você, somos descendentes diretos desses medrosos que se multiplicaram aos montes porque são avessos a riscos já de berço.

Esse medo pode ser resumido em uma única palavra: ignorância. Temos medo daquilo que não conhecemos; achamos mais fácil repudiar qualquer fato novo potencialmente ameaçador (lembra do tigre?) do que analisar e estudar com calma a novidade que se apresenta. Lute contra isso! Não diga que métodos ágeis são ruins sem estudar sobre o assunto. Não critique o PMBOK sem entender o contexto e a proposta do PMI. Não acredite que ferramentas e tecnologias possam mandar nas pessoas, a ponto de determinar a qualidade de um design de software. O antídoto para enfrentar o medo é o conhecimento. Acostume-se a pensar "fora da caixa".

O Otimismo

Procuro levar a vida com leveza, otimismo e bom humor. Quem me conhece sabe. Porém, ser otimista demais em projetos de desenvolvimento é arriscado. Sistemas são complexos e imprevisíveis, pequenas mudanças geralmente ocasionam consequências impossíveis de serem previstas em plenitude. Prazos se perdem facilmente se a equipe não olhar de perto problemas e obstáculos.  Programas se tornam incompiláveis se não houver preocupação constante com merges e commits. A "lei de Murphy" é a regra, não a exceção em projetos. Por isso, uma atitude mais defensiva é sempre desejável.

Acredite, o seu componente de software não irá funcionar só porque você deseja que funcione. Os riscos não irão deixá-lo em paz só porque você está fazendo "pensamento positivo" ou pensando que "o universo conspira a seu favor". O Cosmos não se interessa pelo seu projeto; é melhor deixar essas coisas de lado e se preparar para evitar que coisas ruins aconteçam de forma racional e isenta. É preciso ter um plano para se preparar para os obstáculos que invariavelmente invadem todos os projetos de sistemas.



Conclusão: vigie sua preguiça, controle seu medo e não seja demasiadamente otimista. Assim, irá se tornar um profissional muito mais produtivo, inteligente, flexível, inovador e responsável.

Tenho certeza que você irá se surpreender com os resultados.

Até a próxima!

Arquitetura para o DDD

Continuando a série sobre o Domain Driven Design iniciada aqui, vamos agora comentar sobre como arquitetar as camadas da aplicação de modo a utilizar um Domain Model rico como a "base" do desenvolvimento.

Antes de mais nada, convém salientar que essa não deve ser vista como a única arquitetura que existe e que irá atender a todos os sistemas e situações do mercado. Trata-se apenas da arquitetura mais adequada a um projeto que trabalhe sob as premissas do DDD.

As camadas são representadas como abaixo:

Explicação sobre as camadas:

É importante dizer que não considero a camada Application como mandatória; ela é criada apenas se realmente adicionar valor à aplicação. Como a camada Domain é bastante rica em funcionalidades, muitas vezes não é necessário implementar mais essa divisão.

A criação de um Domain Model  traz uma série de vantagens para aplicações de larga escala e/ou complexas. Como bem disse Martin Fowler em PoEAA: "se você utilizar DDD para um projeto, você provavelmente irá cogitar utilizar a mesma técnica para outros (mesmo para os pequenos)."

Um design focado na criação de um Domain Model tem melhor manutenção no longo prazo devido à clareza da relação entre o negócio e a implementação. Além disso, é uma importante ferramenta para evitar a duplicação de código. Também aumenta a testabilidade do sistema.

Pesquisa Agile.

Laurie Williams, uma professora da North Carolina State University, vem conduzindo uma pesquisa para descobrir quais as práticas e os princípios que são mais utilizados pelas equipes ágeis.

A pesquisadora também convida os participantes a repensarem os princípios e práticas, propondo sugestões de melhoria (quando aplicável). 

Vejam os cinco princípios considerados mais importantes até o momento:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Working software is the primary measure of progress.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

E as cinco práticas mais importantes:

1. Short iterations (30 days or less)
2. Continuous integration
3. “Done” criteria
4. Automated tests are run with each build
5. Automated unit testing

Você pode conferir as atualizações da pesquisa aqui.

Caso queira participar da pesquisa é só vir aqui.

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.

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...

It`s Only Rock `n Roll (But I Like It)

Simplicidade é uma ideia poderosa. Capaz de transformar o ruído em comunicação, o desarrumado em elegante, o complicado no fácil. O Rock, gênero musical de maior sucesso e impacto cultural da atualidade, ergueu suas bases nessa ideia genial, como definido pela Wikipedia: "sua forma pura tem alguns poucos acordes, um forte e insistente contratempo e uma melodia cativante."

Essa economia é misteriosamente cativante e sedutora. A relação criada entre a música e o ouvinte é direta e íntima. Visceral. Ela acontece, por exemplo, quando cantamos a melodia de uma peça que gostamos ou quando colocamos a nossa trilha sonora predileta para tocar no celular.

Porém, atingir tamanho grau de simplicidade não é nada fácil. É necessário trabalho duro. Suor.

Veja uma das mais famosas fórmulas da Física:




Espantosamente simples, não? A fórmula relacionando massa com energia parece que esteve sempre ali, apenas esperando para ser descoberta... Entretanto, para chegar a essa elegância, foi preciso muito trabalho para "polir" as arestas e jogar fora tudo o que estava atrapalhando (obviamente, com um "empurrãozinho" da mente brilhante de um dos maiores cientistas do século XX).

Seguindo esse raciocínio, para desenvolvermos software que seja fácil manter, atualizar e compreender, é preciso prestar atenção aos mestres da simplicidade, como Albert Einstein e Keith Richards. Para esses monstros sagrados, o que é deixado de fora é tão (ou mais) importante do que aquilo que será utilizado.

Atualmente, devido ao vasto arsenal de patterns e frameworks disponíveis no mercado, é muito comum o desenvolvedor pecar pelo excesso na codificação, seja para tornar o código mais "elegante" ou simplesmente numa tentativa de impressionar os seus pares e mostrar "serviço".

Por exemplo, veja aqui o famoso "Hello World", totalmente redesenhado utilizando vários padrões de projeto [GoF] como AbstractFactory, Strategy e State. É uma caricatura interessante de como a "sobre-engenharia" do código pode resultar, paradoxalmente, em código ruim e de difícil manutenção.

É claro que não sou contra a utilização de padrões, na verdade é exatamente o oposto:  encorajo e apoio a sua adoção. Porém, assim como um guitarrista não faz música apenas subindo e descendo escalas, um desenvolvedor de software não irá criar peças de qualidade apenas copiando e entupindo o código com padrões sem sentido.

É preciso um equilíbrio entre técnica, arte, sensibilidade, experiência e talento.

Uma dica de como começar?

Dê uma espiada aqui.