Rafael Noronha

Este texto está disponível apenas em Inglês.

Já faz algum tempo que comentei com o pessoal do .Net Architects sobre um cenário onde enxergo um problema na utilização de abstrações.

Este cenário especificamente é a definição de uma interface sobre o uso de um framework ORM.

O problema de definir uma interface sobre o seu ORM é o fato de que você está tentando isolar algo que em situações normais não precisa ser isolado.

Um bom ORM por si só já é um componente de abstração.
Ele esconde de um software orientado a objetos a natureza relacional da comunicação com um banco de dados.

O motivo justo para se definir a interface seria a possibilidade de trocar de ORM alterando apenas um arquivo de configuração.

Mas deixo aqui dois argumentos que confrontam esta idéia:

1 – Na maior parte dos cenários, a flexibilidade de não depender de uma implementação de ORM é meramente um ornamento sobre o seu software.
Eu fico imaginando se realmente pode vir a fazer sentido que você deixe de utilizar o NHibernate e passe a utilizar o Entity Framework, ou algo do tipo, durante o decorrer de um projeto.

Diante disto, a recomendação é obviamente a de que devemos nos ater à solução mais simples possível.
A mudança de implementação do contrato jamais viria a tona.

2 – Digamos que para o seu contexto em específico, a troca de implementação realmente faça sentido.

No entanto, um fato que não deve ser ignorado é o de que o problema de persistência de dados é complexo, e o que está em jogo não é apenas a troca de mensagens entre o seu software e o componente de persistência, mas também o modo como este componente trata o ciclo de vida dos objetos mapeados, entre outras coisas.

Além disto, a API de um bom ORM é bastante extensa, e cobrí-la com uma interface genérica realmente não me parece a melhor das idéias.
Principalmente ao considerarmos os problemas de mapeamento ou construção de queries, e como estes variam dentre diferentes soluções.

Contratos são extremamente poderosos na construção de software.
No entanto, diferentes cenários podem tirar maior ou menor proveito da utilização destes com o objetivo de plugar diferentes implementações de um componente.

Antes de definir um contrato sobre uma dependência de seu software, é interessante que se faça uma análise do custo-benefício trazido pela abstração.

Não tome decisões em função da suposição de que em um belo e distante dia elas lhe trarão benefícios.
Trata-se de um dos erros mais cometidos por arquitetos de software.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Você conseguiu seu primeiro emprego como desenvolvedor de software.
Caso se trate de software corporativo, você provavelmente atuará com Java, .NET, ou alguma coisa do tipo.

A primeira coisa que vem a sua cabeça é que você precisa ficar fluente na tecnologia que você terá em mãos.
De fato, esta preocupação é completamente válida.

No entanto, tenho visto programadores iniciantes cometendo um erro, diante desta situação.

Por um lado, adquirir conhecimentos técnicos sobre a plataforma e os frameworks que você utilizará é essencial.
Por outro lado, existem outros assuntos que também merecem atenção durante esta etapa.

Frameworks não te ensinarão os fundamentos.
E sem estes, nenhum conhecimento técnico será suficiente para fazer de você um profissional completo.

O recomendado é que você não deixe de estudar a tecnologia que você atuará.
Mas dedique-se também ao estudo de fundamentos.

São diversos os assuntos que merecem atenção.
Entre eles:

• Algoritmos e Estruturas de Dados – antes de sair por aí escrevendo código, certifique-se de saber o que você está fazendo.
• Orientação a Objetos – um assunto extremamente extenso e relevante caso você programe em uma linguagem que implemente este paradigma.
• Protocolo HTTP – entender o funcionamento da comunicação entre um browser e um servidor web é o mínimo que se espera de desenvolvedores web.
• Não menos importante, aprenda a arte de escrever código expressivo.

Escrever código expressivo é, infelizmente, algo negligenciado por muitos profissionais experientes.
Para este assunto em específico deixo a indicação de uma leitura.

Quanto aos outros assuntos, uma pesquisa te conduzirá a diversos materiais que podem ser utilizados.

Minhas recomendações estão abertas a críticas e sugestões.

Bom estudo!

Terminou 2009.
Que tal uma rápida retrospectiva?

Vamos aos números!

1 blog fundado.
40+ posts escritos.
200+ mensagens enviadas em listas de discussão.
1 conta no Twitter fundada.
50+ seguidores no Twitter.
300+ updates no Twitter.
0 participações em eventos técnicos.
0 apresentações.
3 projetos full-time.
2 projetos full-time cuja arquitetura (ou falta de uma) trouxe problemas.
0 projetos part-time.
3 empregadores – um deles sendo eu mesmo.
1 projeto open source fundado.
1 projeto open source abandonado.
0 contribuições para projetos open source de terceiros.
2 certificações.
10+ livros técnicos lidos.
10+ frameworks aprendidos.
3 novas linguagens de programação – Ruby, Java e T-SQL.
2 novas plataformas de desenvolvimento – Ruby on Rails e JEE.

Alguns números que eu adoraria ter conhecimento:

Quantidade de linhas de código escritas.
Quantidade de linhas de código removidas.
Quantidade de bugs esperando pelo momento certo.
Quantidade de bugs corrigidos.
Quantidade de depurações feitas, já que eu não trabalhei com TDD.
Quantidade de cafezinhos durante reinicializações de um servidor de aplicação.
Quantidade de WTF por dia ao entrar em contato com o código de outros programadores.
Quantidade de WTF por dia ao trabalhar com famigerados Business Delegate, Service Locator e Data Transfer Object.
Quantidade de WTF por minuto ao testar funcionalidades supostamente prontas.
Quantidade de problemas encontrados em documentos de requisitos.
Quantidade de código escrito em função de uma arquitetura ruim.

Entre outros.

Este texto está disponível apenas em Inglês.

A escrita deste texto foi inspirada pelo seguinte post, encontrado no blog do Rodrigo Yoshima, figura carimbada na comunidade Java.

Nem faz tanto tempo assim que trabalho com software, mas o meu grande interesse pela indústria me traz diversos tipos de reflexões e conclusões a seu respeito.

Uma das conclusões é a de que pessoas têm preguiça de pensar e inovar.

É onde entra o fácil.
Fácil é desenvolver software do mesmo jeito, sempre.
Tornando-se imperceptível o quão ineficiente e falho são os métodos de trabalho empregados.

Há aqueles que enaltecem o difícil.
Desenhando arquiteturas engenhosas, mas incrivelmente improdutivas e mal empregadas.

A pegadinha acontece quando se fala no simples.
Chegar a uma solução simples é mais difícil do que chegar a uma solução fácil, e também mais difícil do que fazer algo complexo.

A solução simples é aquela que viabilizará maior produtividade, resultando em entregas mais frequentes.
É também aquela que exigirá maior know-how técnico durante sua concepção.

Você já parou para pensar que tipo de pessoa arquitetou o software em que você está trabalhando?

Ou em quão produtivo tem sido o seu trabalho?

Que tal começar analisando a quantidade de código que você precisa escrever para entregar software.

É incrivelmente grande a quantidade de trabalho repetitivo e desnecessário sendo realizado por aqueles que não estão em contato com uma solução simples.

E caso você se encontre neste cenário, considere-se acima da média simplesmente por ter reconhecido o fato.

Este texto está disponível apenas em Inglês.

Alguns blogueiros da comunidade de software brasileira, pelos quais tenho bastante respeito, vez ou outra fazem (ainda que inconscientemente) um desfavor àqueles que os seguem.

Este desfavor é a tradução de materiais escritos em inglês, para o idioma português.

Num primeiro momento esta atitude é bastante nobre.
Afinal de contas, existe um grande número de profissionais no mercado brasileiro que não possuem fluência em inglês.

Mas essa atitude também traz consigo o mesmo tipo de problema que a doação de esmola: você está entregando para as pessoas o peixe, ao invés de ensiná-las a pescar com as próprias mãos.

Acredito que o melhor a se fazer é guardar a capa de super-herói no guarda-roupas e deixar de fazer este (des)favor à comunidade.

Quem sabe ao deixar de receber bom conteúdo de bandeija, nossos pobres amigos procurem aprender a encontrá-lo.

Será melhor para eles.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Há alguns dias atrás Joel Spolsky blogou a respeito de um perfil de desenvolvedor de software que ele vê com bons olhos.
Na minha interpretação, este perfil representa “o cara que entrega”.

Ainda sob a minha ótica, o cara que entrega é aquele que:

1. Está mais preocupado com o projeto do que com a tecnologias empregadas.
2. Não deixa de cumprir um prazo porque o código não está tão bom quanto poderia estar.
3. Faz um trabalho simples.
4. Não está preocupado em aplicar em seu código Strategy, Facade, ou qualquer coisa do tipo.
5. Não considera prática criminosa deixar de escrever testes.

Existem problemas com o perfil deste desenvolvedor?
Talvez.

Você não precisa fazer parte do 8 ou do 80.
Você pode ficar entre eles.

Do lado do 8 está  o cara que entrega.

E do lado do 80, aqueles que abominam a figura do cara que entrega.

O que estes esquecem é que:

1. Preocupar-se mais com a tecnologia e menos com o projeto é ruim.
2. Entregar um código que poderia estar melhor não significa entregar um código necessariamente ruim.
3. Fazer um trabalho simples não significa fazer um trabalho ruim.
4. Preocupar-se com o design pattern que você utilizou ou vai utilizar para resolver um problema pode ser extremamente irrelevante.
5. A não escrita de testes nem sempre deve ser julgada como crime hediondo.

O melhor a se fazer é reconhecer os méritos existentes no cara que entrega.

Porque construir o melhor código do mundo mas entregá-lo tarde demais é ruim.
Porque gastar tempo demais escrevendo testes pode ser ruim.
Porque você não precisa conhecer design patterns para ser um bom desenvolvedor.

Extremos  são ruins

Neglicenciar a importância de se escrever código expressivo é ruim.
Superestimar esta importância também é ruim.

Desconhecer os benefícios de escrever testes de software é ruim.
Escrevê-los sem dominar a prática, ou sem levar em consideração o custo da prática também é ruim.

É este tipo de armadilha que requer de um desenvolvedor de software pragmatismo.
Não existem verdades absolutas.

Existem dezenas de técnicas que quando utilizadas oportunamente podem ser extremamente valiosas.

No entanto, grande parte destas técnicas traz algum tipo de custo.
Utilizar a técnica XYZ mas deixar de considerar o seu custo pode ser pior do que deixar de utilizá-la.

Isto para não falar em utilizar a técnica XYZ sem entender o que de fato ganha-se com esta utilização.

Para quem criticou o texto do Spolsky, talvez o seguinte parágrafo tenha passado desapercebido:

Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.

Portanto o “cara que entrega”, agora na visão do Spolsky, é um desenvolvedor inteligente o suficiente para se dar o luxo de não escrever testes, sem necessariamente colocar tudo a perder.

Se você é o cara que entrega nestas condições, é uma honra estar escrevendo para você.

Mas se você é o cara que entrega, mas não sabe do que está abrindo mão, é provável que você seja o cara que entrega lixo.

Aquele, que a turma do lado do 80 tanto ama.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Este texto está disponível apenas em Inglês.

Após alguma reflexão me dei conta de que as coisas andam um pouco “waterfall” por aqui.

Chegou a hora de fechar a primeira iteração, 7 meses depois.
Sendo este post uma retrospectiva desta primeira etapa e também o planejamento daquilo que vem por aí.

Nestes 7 primeiros meses de blog deixei por aqui 34 posts.
O que resulta em uma média de 5 posts por mês. Um número razoável, que só tentarei melhorar tendo certeza de não reduzir a qualidade dos textos.

No formato atual da nuvem de tags, 7 posts abordam Agile (5 deles abordando Scrum), 7 posts expõem algumas Reflexões, e 6 são Reviews de livros. Destancando-se ainda 5 posts sobre Testes, 4 sobre Asp Net MVC e outros 4 sobre Ruby on Rails.

A quantidade de visitas ao blog vem crescendo e o público começa a ganhar forma.
O ritmo do crescimento de visitas é modesto, mas constante.

Nesta retrospectiva ”presto contas” comigo e com os leitores, colocando em evidência os assuntos até então abordados e outros assuntos que passarei a abordar por aqui.

Já mencionei a minha jornada para uma nova tecnologia web, Ruby on Rails.
Um mês depois, tenho trabalhado diariamente com esta tecnologia, devo dizer que estou bastante satisfeito com a minha escolha.

Também já escrevi sobre  o porquê Ruby on Rails ter me interessado em outras oportunidades.
O que é importante colocar é que nos próximos meses passarei a escrever menos sobre a plataforma .net (as dicas de asp net mvc ficarão para trás), e mais sobre Ruby on Rails.

O que não significa que estarei me fechando dentro da toca de Ruby on Rails.
Fechar-se a uma comunidade ou plataforma em específico é um erro cometido por muitos desenvolvedores de software.
E já que toquei no assunto, fica aqui a dica para um podcast gravado por uma comunidade de .net (da qual participo) que está de olhos atentos a aquilo que acontece ao redor dela.

Gosto bastante de escrever sobre modelagem e boas práticas no desenvolvimento de software.
Estes  textos provavelmente passarão a ter como pano de fundo Ruby on Rails.

Mas boa parte do conteúdo do blog vem sendo agnóstico à tecnologia de minha escolha (vide os textos abordando processos ágeis e também as reflexões sobre desenvolvimento de software em geral).

É provável também que eu passe a escrever mais sobre o meu trabalho diário, o que deve agregar bastante valor ao conteúdo do blog.

Menciono ainda a possibilidade de escrever mais textos em inglês e menos em português, o que espero não ser um problema para você.

Concluindo a retrospectiva, volto a trabalhar duro objetivando aumentar a qualidade deste material e atingir um número cada vez maior de leitores.

Manter um blog sério exige uma grande dedicação.
No entanto, fato é que este trabalho já teria ficado para trás se desempenhá-lo não fosse algo prazeiroso para mim.

Tão importante quanto escrever um texto, é ler o que os outros andam escrevendo.
Além da necessidade de acompanhar outros tipos de materiais, o que aos poucos vou aprendendo a fazer.
E o resultado de tudo isso é imensurável.

Aproveito a oportunidade para convidá-lo a me seguir no Twitter, onde costumo escrever coisas aleatórias quase diariamente. Vez ou outra eu também divulgo por lá algum material de leitura interessante.

Caso você não seja um leitor assíduo de meu blog, conheça mais sobre mim aqui.

Esta é também uma boa oportunidade para você comentar sobre a qualidade daquilo que escrevi nestes primeiros meses.

Até o próximo post!

Bloguei menos do que gostaria de ter blogado nas últimas semanas.
Tenho pelo menos meia dúzia de tópicos separados para dissertar sobre, e passarei a me policiar para não deixar de publicar ao menos um texto por semana.

Para não deixar o mês fechar em branco escrevi um review, sobre este excelente livro que li há algumas semanas.

Restful Web Services é um livro de referência não apenas para aqueles que desejam expor web services baseados no conceito REST.

Podemos encará-lo também como um importante material para qualquer desenvolvedor de software que atua com a plataforma web.
Isto porque aquilo que está em questão é o correto aproveitamento da infra-estrutura da web, sobretudo do protocolo http.
Portanto é também da correta utilização da infra-estrutura da web que este material trata.

Além disto, há quem diga que ao aplicar conceitos REST, estamos trabalhando também na modelagem do sistema em desenvolvimento.
Uma idéia que vem fazendo total sentido para mim.

O texto possui um alto enfoque prático, o que facilita bastante o entendimento das idéias apresentadas.
É apresentado ao leitor o conceito de ROA, resource-oriented architecture, envolvendo um conjunto de boas práticas no design de uma arquitetura web.

Aprenda e aplique importantes convenções.

Entenda o que temos a ganhar com e de que maneira implementar este conjunto de práticas.

Saiba como contar com a infra-estrutura da web ao seu favor.

Construa sites e web services mais intuitivos, ajudando aqueles que utilizarão ou trabalharão em cima de seu produto.

Faça da web um lugar melhor!