Houve um tempo em que simplesmente não haviam opções quanto a manipulação do banco de dados, tinhamos necessariamente que incluir código SQL manualmente dentro do código das aplicações. Mas, felizmente, com o passar do tempo, surgiram soluções alternativas, incluindo os famosos frameworks ORM(Object-Relational Mapping), e graças a eles passamos a ter uma excelente opção para esta questão. No entanto, conforme adianta o título deste post, essa é a melhor solução possível?

Eu sempre acreditei que sim, e em parte ainda acredito. Inserir instruções SQL dentro de uma aplicação torna, ao meu ver, o código pouco elegante como um todo, uma vez que o SQL por si só não é exatamente uma linguagem bonita. Sendo assim, acabamos tendo parte do código com um nível de abstração satisfatório e a outra parte… bem, a outra parte é SQL. E mesmo se isolarmos o código SQL apropriadamente, o que, convenhamos, é o mínimo que temos a fazer, ainda assim fica feio.

Além do fato do SQL não ser mesmo uma linguagem bonita, a raiz deste problema repousa na mistura do modelo relacional com o paradigma orientado a objetos, supondo que está sendo utilizado estes dois modelos, que são, respectivamente, os mais populares para SGBDs e para linguagens de programação.

A propósito, ao contrário do que muitos pensam, o maior benefício dos frameworks ORM é justamente abstrair o modelo relacional, permitindo assim que nós trabalhemos unicamente com objetos. É um erro comum pensar que eles foram criados primariamente para possibilitar trocas de SGBDs, já que esse tipo de coisa está longe de ser comum.

Mas, apesar do SQL inegavelmente piorar estaticamente o código de um sistema, temos que considerar que estamos falando do melhor dos cenários. Há casos em que simplesmente não é possível usar um framework como Hibernate ou ActiveRecord ou qualquer outra solução que abstraia o modelo relacional, seja por problemas relacionados a performance ou por limitações da estrutura organizacional, dentre outros fatores limitantes.

Um exemplo de um cenário com tal limitação foi apresentado no Rio on Rails. Lá, o Eduardo Rocha, criador do site O Curioso, revelou que devido a problemas que afetavam consideravelmente a performance do site, teve que incluir algumas instruções SQL diretamente, ao invés de usar o excelente suporte oferecido pelo ActiveRecord. Portanto, neste caso, foi preciso abdicar da conveniente e amigável interface oferecida pelo framework ORM, no caso o ActiveRecord, em prol de uma melhor performance no site, uma vez que isso sim afeta diretamente os usuários.

Sendo assim, respondendo a minha própria pergunta, eu acredito sim que quanto menos código SQL uma aplicação tiver, melhor. Melhor para ela e para os desenvolvedores que a manterão. E se essa quantidade signigicar nenhum código SQL, melhor ainda.

Entretanto, no mundo real, como vimos acima, nem sempre isso é possível, e como desenvolvedores de software nós temos que identificar estes cenários que constituem uma exceções. Até porque, no fim das contas, o nosso foco é criar software que resolva problemas, e para isso as vezes temos que criar software feio do ponto de vista do código fonte. Até porque, o problema mais importante a ser resolvido não é o nosso, e sim aquele que originou o desenvolvimento do software em questão.

Após duas versões beta e dois Release Candidates, foi lançada hoje a versão final do Netbeans 6.0.

Para quem não sabe, o Netbeans é uma IDE bastante conhecida no mundo Java, uma vez que ela é desenvolvida nesta linguagem e é mantida pela Sun, mesma empresa que mantém o Java. No entanto, se engana quem acha que o Netbeans suporta apenas desevolvimento Java, uma vez que há um bom tempo a IDE também suporta outras linguagens, como C/C++, por exemplo.

Além disso, de uns tempos pra cá, a Sun passou a investir pesado no Ruby, o que resultou na contratação dos desenvolvedores do JRuby e no fato do Netbeans agora dar suporte ao desenvolvimento Ruby/JRuby.

Como resultado desse investimento no Ruby, o Netbeans é hoje, na minha opinião, uma ótima opção para desenvolvimento Ruby/Rails. E pelo que parece eu não estou sozinho, já que, segundo uma pesquisa realizada com desenvolvedores Ruby/Rails sobre IDE/editor preferido, ele é uma das IDEs mais utilizadas para desenvolvimento Ruby/Rails.

Sendo assim, agora só me resta testar a versão final, e ver se realmente atende as expectativas no que diz respeito ao Ruby. E caso você queira fazer o mesmo, basta baixar o instalador da distribuição do Netbeans 6.0 específica para o Ruby, sendo que ele possui apenas 19,7 MB. Em seguida, prossiga através da sua instalação no melhor estilo next->next->finish e pronto!

Na última semana, durante uma aula de Engenharia de Software 2, foi levantada uma questão interessante: quem tem culpa quando um sistema dá errado?

Durante o debate, um dos alunos, provavelmente um desenvolvedor, defendeu a idéia de que a culpa é sempre do usuário, que, em sua infinita imaginação, sempre consegue utilizar o sistema da maneira errada.

Como exemplo, foi citado uma aplicação que possuia um formulário para busca contendo datas, sendo que, por algum motivo qualquer, não se poderiam fazer buscas sobre ocorrências anteriores a 1985, pois isto resultaria em um erro. Acontece que os usuários do tal sistema frequentemente se esqueciam deste detalhe, persistindo em realizar buscas informando datas inválidas. E por mais que os desenvolvedores os lembrassem desta limitação, o problema permanecia, levando a conclusão, por parte do aluno, de que o problema está no usuário.

Já o professor, sabiamente, afirmou que se o usuário erra, é porque o desenvolvedor permitiu que tal erro ocorresse. Por exemplo, no caso mencionado acima, o mais apropriado seria que fosse impossível entrar com uma data inválida, ou simplesmente verificar a entrada e não processá-la se for o caso, gerando assim uma mensagem para o usuário. Portanto, neste caso, se o usuário errou, é porque o desenvolvedor errou antes.

Mas, apesar de concordar com o professor neste exemplo, devemos considerar que é apenas uma situação isolada. No geral, embora seja uma das funções do desenvolvedor evitar erros do usuário no uso do sistema, é evidente que ele não é o único culpado quando as coisas dão errado.

Responsabilizar apenas uma das partes é sempre uma atitude extrema e preguiçosa. A responsabilidade pelo sucesso ou fracasso de qualquer sistema depende tanto de quem o desenvolve como de quem o utiliza. No entanto, o relacionamento entre os usuários de uma aplicação e os seus desenvolvedores é bastante complicado por “culpa” de ambas as partes.

Do lado dos desenvolvedores, a noção de que o usuário é sempre o culpado é bastante comum. A verdade é que é sempre mais fácil delegar a culpa a outra pessoa, e como nesta situação há basicamente apenas dois papeis envolvidos, só sobrou mesmo o usuário para culpar. Portanto, não espero ouvir de um desenvolvedor algo do tipo “O sistema saiu do ar devido a um erro que eu cometi”. As pessoas, em geral, são orgulhosas e não têm muita auto-crítica, e não seria diferente com quem desenvolve software.

Já da parte do usuário, por estar muitas vezes consciente desta posição dos desenvolvedores, eles acabam se sentindo acuados e constantemente vigiados, de forma a serem responsabilizados pele erro mais recente do sistema. Isto, somado ao fato de sempre haver a suspeita, nem sempre infundada, de que um novo sistema pode significar demissões, acaba fazendo com que ele veja o desenvolvedor como uma ameaça ao seu emprego, ou pelo menos à sua posição na empresa, o que obviamente prejudica bastante a relação entre eles.

A verdade é que existem sim usuários menos capazes, e é natural que eles utilizem o sistema de forma menos produtiva, no entanto, se este tipo de usuário causar de fato um erro no sistema, é porque este erro não foi evitado antes pelos desenvolvedores. Até porque, inaptidão não é uma característica presente unicamente nos usuários. Ou, em português claro, também existem desenvolvedores ruins.

O que nós temos que entender é que mesmo que não sejamos desenvolvedores ruins, qualquer aplicação que formos desenvolver em uma empresa irá falhar se não contarmos com a colaboração daqueles que a usarão. Ninguém entende melhor do que o usuário o que o sistema deve realmente fazer, incluindo algumas sutilezas que jamais seriam imaginadas por nós. E são justamente estas sutilezas que resultarão em erros no futuro, caso nós não soubermos como vencer a barreira invisível que existe entre nós e os usários. Afinal, seja lá o que estivermos desenvolvendo, muito provavelmente será utilizado para informatizar o trabalho que este usuário desenpenha na empresa, e ninguém melhor do que ele mesmo para nos dizer como funciona este trabalho.

No fim das contas, para fazermos bem o nosso trabalho precisamos da cooperação do usuário. Portanto, é necessário darmos o primeiro passo e mudarmos de atitude, para que assim o mesmo aconteça do outro lado, possibilitando a ambos um melhor desempenho nas tarefas que somos pagos para fazer.