Category Archives: Melhores práticas

Pair Programming e o bem estar

Depois de um pareamento eu sempre tive o sentimento de esgotamento, verdadeira exaustão, aliado com uma sensação de dever cumprido. Mesmo cansado eu me sentia bem, mas não entendia o porquê.

Tom Rath e Jim Harter, pesquisadores do Gallup, chegaram a uma conclusão depois de tabular pesquisas para o livro “Wellbeing: The Five Essential Elements” [“Bem-estar: os cincos elementos essenciais”, numa tradução livre] que em todas as situações pesquisadas as pessoas precisavam de pelo menos 6 horas por dia de socialização para se sentirem realizadas (bem), para cada hora de acréscimo seu humor fica melhor e para cada hora de decréscimo ele piora. A partir de 6 horas já não fazia diferença alguma, além de alguns pontos a mais como: socializar com mais de 3 pessoas diariamente  diminui o índice de bom humor e é o dobro do tempo que os especialistas em comportamento consideravam necessário.

Na nossa área existe uma teoria de que, por sermos Nerds, nós não nos socializamos. Pelo contrário, sessões de RPG por exemplo são mais intensivas do que horas de baladas e curtição na praia, são somente formas diferentes. O livro não indica a forma de socialização, nem se pode ser virtual (via Social Networks) ou face-a-face, apesar de que gerações diferentes tem suas preferências (óbvio).

Pois bem, nossas sessões de Pair Programming são em média por volta de 6h, temos garantido (segundo a psicologia) nosso grau de socialização diária para nos sentirmos bem. Outro benefício do PP que a psicologia agora nos dá uma explicação.

Jesus já recomendava:

E depois disto designou o Senhor ainda outros setenta, e mandou-os adiante da sua face, de dois em dois, a todas as cidades e lugares aonde ele havia de ir. Lucas 10:1

Workshop Agile

Após o post que escrevi sobre erros comuns ainda hoje de modelagem feitos principalmente na comunidade Java – mas não limitados a essa comunidade,  choveram de dúvidas de clientes e desenvolvedores próximos sobre quais as melhores práticas e como desenvolvemos.

Apesar de um tema com bastante bibliografia, muito material na internet e já uma certa maturidade no mercado nós notamos que ainda há um fosso enorme entre a realidade dos projetos atuais e a aplicação dessa teoria, principalmente um treinamento com um sentido mais prático.

Ainda não há uma base consistente e sólida de treinamentos e materiais sobre experiências reais e projetos que deram ou não certo.

Frente a isso nós formatamos um Workshop para responder todas essas indagações com um treinamento voltado ao “como fazer”, direto ao ponto, demonstrando a teoria “by the book” em um projeto de verdade com todas as situações que nos fazem relegar boas práticas e tornam o desenvolvimento tão caro e muitas vezes ineficaz.

Juntei o material de cursos passados, demos uma repaginada com a experiência dos últimos anos, o que funcionou e principalmente não funcionou para responder a todas as perguntas possíveis em um espaço relativamente curto de tempo, mas precisamente focado.

Se tiver interesse de participar, vá lá e se inscreva, faremos de tudo para deixá-lo apto a entender todo o ciclo de desenvolvimento moderno. Um curso para todos os níveis. Uma imersão no Ágil.

Desenvolver em Java em pleno 2012, mesmos erros de 2005

Post já nasce datado, mas só faz sentido para agora mesmo. Passei uns 10 anos da minha vida programando na linguagem Java e nos últimos 3 anos eu peguei poucos projetos, mas o que me impressiona nesses poucos projetos é que as coisas não mudam, inclusive a tara por patterns desnecessários e antipatterns.

Comecemos por Nomenclatura

Se voce chama sua classes de WhateverController, WhateverService e ou WhateverDAO, voce está usando notação hungara desnecessária e complicando a modelagem do seu negócio. Se o seu framework te obriga a nomear as classes com sufixos ou prefixos, ele está errado e é melhor procurar uma solução.

Se voce chama classes como WhateverModel ou WhateverEntity aí voce está estragando a amizade, se mate.

Se voce tem uma classe chamada Whatever e tem propriedades como nameWhatever, leia urgente Clean Code.

 

BOLOVO

As pessoas criavam entidades chamadas WhateverManager por não saberem orientação a objetos, se existe isso no seu projeto na maioria das vezes não tem muito o que fazer, mude de emprego ou de projeto. Mas… se for corajoso comece a refatorar isso guiado por testes, o livro “Growing Object-Oriented Software, Guided by Tests” vai te ajudar bastante. O Paulo Silveira e o Phillip Calçado nomearam esse anti-pattern de BOLOVO.

DAO

DAO é o pattern inútil quando falamos de negócios, principalmente CRUD. A não ser que você esteja codando Framework ou comittando em projetos como o Hibernate, voce não precisa escrever DAO. Voce usa Hibernate, a Session é seu DAO.

Se voce precisa de uma entidade para agrupar alguma lógica de ORM mais complexa no seu negócio – como algumas transações com rollback lógicos, uma alternativa é Repository. Mas por favor, leia o artigo do Phillip primeiro e não faça WhateverRepository. Não há problema nenhum voce ter Criteria dentro de um controller por exemplo, afinal isso é um pattern bem estabelecido e o mapeamento um-pra-um com outra entidade só vai complicar e não traz ganho algum.

Só uma dica aproveitando o tema ORM, o Hibernate trabalha e sempre trabalhou com convenções usando anotações, então não precisa mapear tudo. Basta um @Entity na maioria das vezes. Nos relacionamentos observe se ele já não mapeia tranquilo apenas com o @ManyToOne e diminua o ruído.

Em termos de Patterns, por mais caduco que já esteja, o PoEAA do Fowler ainda reina.

 

Interface e Implementação

Existe uma boa prática como guia que é desenvolver orientado a interface, só que isso não é lei e deve ser usado o bom senso como sempre. A maioria dos desenvolvedores criam a Interface Whatever e uma – e apenas uma – implementação WhateverImpl. Isso é desnecessário e muita gente nem sabe que o Spring sempre funcionou injetar em classes concretas e não apenas em Interface. Deixe a Interface gritar na sua cara para refatorar.

Service e Domain Driven Design

Aqui que mora o perigo, sempre quando eu vejo WhateverService a implementação dessa classe é o mesmo código do antigo WhateverManager. Depois que Domain Driven Design fez sucesso todo mundo finje que modela o domínio.

As classes do seu domínio devem e podem ter métodos de negócios, se ela apenas tem propriedades é sinal do BOLOVO e representa uma tabela do banco de dados vitaminada. Um Service não é a parte de negócios do seu domain, a grosso modo de explicar o código dele explodiu na sua cara por manipular duas ou mais entidades e não ser responsabilidade de nenhuma delas.

ANUNCIO EM LETRAS GARRAFAIS

Cuidado com os livros que eu indiquei, quando foram escritos o Hibernate e o Spring estavam nascendo ou ainda não tinham nascidos, portanto leia com moderação. Várias coisas já forma implementadas pelos Frameworks e não vá fazer uma roda por cima de outra roda.

TL;DR

Cuidado com o código que voce escreve, faça-o guiado por testes, leia bons livros de Orientação a objetos e Patterns. Não escreva código igual aos outros porque é assim que todo mundo faz.