A nova formação da Caelum tem o objetivo de aprofundar os conhecimentos numa área em constante crescimento. A formação tem a parceria da Locaweb e é composta dos cursos WD-41 | Design de Interação, Experiência do Usuário e Usabilidade e WD-43 | Desenvolvimento Web com HTML, CSS e JavaScript.

User Experience

Ao navegar na web, sacar dinheiro de um caixa eletrônico ou mesmo usar um celular, nos deparamos com sistemas diferentes, escritos em Java, Ruby ou C#, porém nossa satisfação não é definida pela linguagem utilizada, e sim pela qualidade e facilidade em interagir com o produto: nossa experiência como usuário.

Ao estudo dessa interação usuário-produto dá-se o nome User Experience, muito conhecido como UX, e em português traduzido como Experiência do Usuário.

Pode-se definir User Experience como a satisfação e qualidade em interagir com a interface de um serviço, produto ou sistema. Muitos consideram a Experiência do Usuário como um dos principais fatores no sucesso ou fracasso de um software. O quanto seu software é focado na necessidade do usuário? Com que velocidade ele atende aos clientes? Quais as dificuldades para finalizar uma compra? Quanto mais simples de usar, menor é a necessidade de suporte e maior a viabilidade financeira do projeto. Podemos citar exemplos clássicos, como o GMail, que revolucionou a forma de utilizar email online, além do iPod com sua interface simples e objetiva.

Design de Interação

Um dos papéis que existem no processo de desenvolvimento da Experiência do Usuário é o de Designer de Interação. Existem diversas funcionalidades implementadas em um sistema que muitas vezes os usuários finais desconhecem ou tem pouco interesse, sendo que elas poderiam facilitar tarefas e otimizar tempo. O Designer de Interação se preocupa com as relações humanas de um software.

Autores e profissionais se referem ao Design de Interação como iD ou IxD (Interaction Design), existindo já uma associação oficial, a IxDA. No Brasil há um conhecido blog da Locaweb focado em Experiência do Usuário.

Designer de Interação x Arquiteto de Informação

Nos projetos web os dois papéis são parecidos, porém com diferentes focos. O Arquiteto de Informação se preocupa mais com o armazenamento e distribuição da informação, enquanto o Designer de Interação tem a responsabilidade de definir como essa informação será manipulada e transformada.

É comum em equipes grandes o Designer de Interação ser responsável por criar wireframes enquanto o Arquiteto de Informação cria a estrutura e faz o planejamento geral.

Existe um instituto sobre Arquitetura de Informação e no ano passado o Brasil sediou o Interaction South-America 09.

Programador de Interfaces

E quem realmente escreve o código das interfaces web depois de planejadas? Nessa etapa entra o profissional com conhecimentos aprofundados de HTML, CSS, Javascript, que têm ganhado muita atenção nos últimos anos, em especial o Javascript, sendo reconhecido como uma linguagem extremamente poderosa e divertida. Esse profissional é focado em transformar o trabalho planejado pelos profissionais acima em realidade. Ter o domínio dos melhores padrões, layouts e conhecimento dos diversos navegadores existentes para converter o projeto em realidade são algumas das funções do Programador de Interface, também chamado de Web Designer.

O sucesso de um projeto dependente muito de atender e se possível superar as expectativas dos usuários, fazer com que a interação deles com o sistema seja tão satisfatória a ponto de atingir completamente os objetivos do sistema.

Confira o conteúdo dos treinamentos WD-41 | Design de Interação, Experiência do Usuário e Usabilidade e WD-43 | Desenvolvimento Web com HTML, CSS e JavaScript.

Há três meses anunciamos o livro Arquitetura e Design Java, um livro que está em seu processo de finalização, fortemente baseado na experiência da Caelum com debates no curso de Arquitetura e Design, a adminstração do GUJ.com.br e esses anos de consultoria.

Os 4 tópicos liberados agora são “Java como plataforma não como linguagem”, “Favoreça imutabilidade e simplicidade”, “Cuidado com o modelo anêmico” e “Considere uma ferramenta de mapeamento objeto relacional”. Eles se juntam aos outros 4 tópicos liberados anteriormente (“Gerenciar memória não é simples”, “Programe voltado a interface, não a implementação”, “Entendendo o NoSuchMethodError e o ClassLoader hell” e “Inversão de Controle: Cadê a minha chave de fenda?”). Confira no site!

Além disso, atualizamos os tópicos do livro com novos temas que estamos finalizando, como REST, Cloud computing, bancos de dados não relacionais, modelos anêmicos e outros.

Este é um livro que aborda desde código até a arquitetura numa visão mais ampla. Como Craig Larman já afirmou: Você deve enfrentar suas batalhas, sejam elas no nível macro-arquitetural ou no humilde campo das instâncias“. Essa distinção, sobre o que é design e o que é arquitetura, não fica muito clara dentro do livro, pois muitas vezes é até difícil separar nessa classificação. Martin Fowler fala o mesmo no âmbito de patterns logo na segunda página de seu livro Patterns of Enterprise Application Architecture: “Alguns dos padrões nesse livro podem ser chamados arquiteturais, já que representam decisões importantes sobre essas partes; outros são mais sobre design e te ajudam a implementar essa arquitetura. Eu não faço nenhuma tentativa forte de separar esses dois, já que é o que é arquitetural ou não é subjetivo.”.

Estamos em processo de finalização do livro e gostaríamos muito de receber feedbacks e opiniões!

Uma das grandes preocupações que temos quando estamos desenvolvendo aqui na Caelum e nas nossas consultorias é como manter o código o mais expressivo possível. Expressividade está muito ligada a uma manutenabilidade maior do código, porque código mais fácil de entender costuma ter menos bugs. Uma das técnicas que usamos pra atingir esse objetivo são os Tiny Types.

Dêem uma olhada no código do seguinte método:

public Projeto criaProjeto(String nomeProjeto,
                           String descricaoProjeto) {
       // Executa a lógica de criação do projeto
}

Digamos que esse seja um factory method para criação de Projeto. Ele seria usado da seguinte forma:

new FabricaDeProjeto().criaProjeto("nome", "descrição");

Mas nada impede que esse método seja chamado dessa forma:

new FabricaDeProjeto().criaProjeto("descrição", "nome");

Notaram a diferença sutil na ordem dos parâmetros? Isso vai acontecer? Provável. Imaginem o tempo gasto com debug para corrigir esse problema? Não seria melhor aproveitarmos a tipagem explícita do Java para pegarmos esse problema em tempo de compilação? Ficaria assim:

public Projeto criaProjeto(Nome nomeProjeto,
                           Descricao descricaoProjeto) {
       // executa a lógica de criação do projeto
}

Ganhamos checagem em tempo de compilação. Mas apenas isso? Vamos olhar como esse método seria usado:

new FabricaDeProjeto()
     .criaProjeto(new Nome("nome"), new Descricao("descrição"));

O código ficou mais expressivo. Fica bem claro que estamos passando o Nome do projeto e não algo genérico. Com isso, fica muito mais difícil confundir o que passar em cada parâmetro. Estamos fazendo uso do sistema de tipos explicitos do java para evitar problemas. Além disso existem mais vantagens, embora um pouco mais sutis.

Com esse novo design do código, temos uma melhor divisão de responsabilidade. Por exemplo, não queremos permitir que o nome do projeto possua números. Como faríamos isso na primeira forma? Colocaríamos a lógica de validação dentro do método criaProjeto. Agora não precisamos fazer isso. Podemos colocar a lógica de validação dentro do objeto Nome, que é o objeto responsável por tudo relativo à Nome. Colocamos a funcionalidade no lugar onde ela deve ficar. Dividimos melhor a responsabilidade porque podemos adicionar métodos em Nome.

Mas temos um pouco mais de trabalho pra fazer isso, correto? Será que o código não vai ficar lento porque estamos criando vários objetos apenas para encapsular Strings? Não. A forma como o Garbage Colector trabalha, coletando os objetos que devem ser mantidos em memória (e não o contrário) simplesmente não vai ser afetada pela criação dos novos objetos, que possuem vida bem curta.

Podemos ir ainda mais longe. Podemos fazer com que esses pequenos objetos sejam imutáveis. Se eles forem imutáveis, teremos diversos ganhos. Por exemplo, quem estiver manipulando esses pequenos objetos não precisará se preocupar com concorrência. Para objetos imutáveis,
não faz diferença se eles estão em um ambiente concorrente ou não: são thread safe por natureza. Esse ganho é tão importante, que existem linguagens de programação onde você não pode criar “objetos” mutáveis, como Erlang. Além da thread safety, a outra principal vantagem é não termos de nos preocupar com que código de outras pessoas modifiquem nossos objetos, sofrendo efeitos colaterais por causa da invocação de um método e passagem deste objeto como parâmetro. Também não há como nossos objetos ficarem fora de um estado consistente.

Esses pequenos objetos imutáveis podem facilitar muito o desenvolvimento, prevenindo problemas e evitando que por preguiça separemos de forma errada as responsabilidades dos objetos. No começo pode parecer que estamos criando um monte de objetos a mais, mas na verdade não é bem assim. Como esses objetos pequenos possuem responsabilidades bem definidas, fica muito fácil reaproveitar. Imaginem quantos lugares precisam ter descrição? Usaremos o mesmo pequeno tipo. O gasto inicial que temos é bem recompensante conforme o tempo passa.

Já vi e ouvi de muitas pessoas e em muitos lugares que Domain Specific Languages são uma ótima ferramenta para deixar o código tão simples de escrever, tão legível e tão parecido com uma linguagem natural (português, inglês), que serve para que não programadores possam escrever parte do código.

A idéia é que o próprio gerente, cliente, analista-não-programador, ou alguém com este tipo de perfil não técnico escreva as regras de negócio em uma linguagem muito parecida com a linguagem natural, eliminando a necessidade de programadores e reduzindo os custos.

Este pode até ser um uso possível e interessante para DSLs, mas infelizmente, DSLs não tem a mínima pretenção de serem linguagens naturais. Isso seria muito ambicioso para o escopo de uma línguagem específica para um domínio. DSLs não foram criadas para ensinar inglês ou português aos computadores.

Existe uma outra forma interessante de usar DSLs, pela qual tenho preferência declarada e felizmente, parece haver uma convergência para esse meio de aplicá-las. O objetivo é fazer com que o código fonte do programa fique mais próximo do problema sendo resolvido. DSLs como forma de aumentar a expressividade do código. Dave Thomas e Andy Hunt tratam desse assunto no famoso livro The Pragmatic Programmer, sob o nome de Program Close to the Problem Domain.

Em seu livro Domain Driven Design, Eric Evans fala muito sobre a importância de todos os envolvidos no desenvolvimento do sistema usarem a mesma linguagem, que ele chama de linguagem ubíqua (Ubiquitous Language). Desta forma, conseguimos diminuir o abismo que existe entre programadores e especialistas no negócio, facilitando comunicação e diminuindo os clássicos problemas do “telefone sem fio”.

problemas de comunicação

DSLs são uma ferramenta para o desenvolvedor. Uma das formas de inserir os termos da linguagem ubíqua no código fonte, de fazer o código refletir o problema que está sendo resolvido. Desta forma, programadores podem fazer com que o código fique auto explicativo e auto documentado. O próprio código se explica; é a documentação de si próprio.

Ando tão “viciado” nessa forma de escrever código, perseguindo expressividade, fazendo com que o próprio código se explique, que em muitos casos a DSL surge naturalmente depois de algumas refatorações. Aqui, Behavior Driven Development (e principalmente o ciclo red-green-refactor) tem ajudado muito, mas esse assunto fica para um próximo post.

Uma técnica simples para aumentar a expressividade é evitar escrever comentários no meio do código. O tradicional “comentário é mal cheiro no código” (code smell).

Ao invés de escrever o comentário, simplesmente extraia o código que estaria sendo comentado em um novo método. O nome deste novo método deve ser exatamente o mesmo que iria ser escrito no comentário.

“You’ve written the code, now you have to write about the code. In a perfect world, you’d never have to write comments for this purpose: the code will be expressive enough that someone who reads it will understand it. Two things help achieve this result: expressive, readable languages and the composed method pattern.” — Neal Ford

Neal Ford diz que linguagens expressivas e legíveis ajudam a eliminar a necessidade de explicar o código. Geralmente, linguagens mais modernas são mais expressivas do que as mais antigas como Assembly. Mesmo usando linguagens mais modernas, ainda podemos usar nossa ferramenta de programadores preferida: DSLs para criar a linguagem com a expressividade adequada para resolver o problema!

Essa técnica tem o seu preço, claro. É sempre uma troca, uma questão de vantagens e desvantagens; clássico trade-off. Projetar uma DSL pode dar mais trabalho no início, já que precisamos pensar em como desejamos escrever o código (Language Oriented Programming) e pode exigir alguns ciclos extras de refatoração até o código chegar num nível bom de expressividade.

O que tenho percebido é que esse possível esforço extra no desenvolvimento (nem está comprovado cientificamente que ele existe ^[1]), costuma compensar mais para a frente, dada a facilidade de ler e entender o código, associado ao fato dos programadores estarem naturalmente o tempo todo usando a linguagem ubíqua.

Além disso, diminui bastante a necessidade da famosa pilha de documentação extra que precisa ser escrita em muitos projetos. Na maior parte deles isso tudo é até escrito quando o software já está pronto! Não estou querendo dizer que manuais não devam ser escritos, mas boa parte desse esforço extra de documentação pode ser reduzido. Principalmente o esforço relacionado a documentação que tem como alvo outros desenvolvedores e pessoas que possivelmente darão manutenção no código.

Assim como os testes durante o desenvolvimento, podemos encarar o uso de DSLs como um investimento, e não tempo extra no desenvolvimento.

Feliz ano novo a todos!

1. eu até acho que fico mais produtivo escrevendo código desse jeito.