Síndrome da IDE

Frequentemente no Grails Brasil me deparo com a seguinte reclamação: “não há grande suporte das IDEs ao Grails ainda”. Sabe: na realidade não vejo isto como um problema, mas sim como uma solução a um problema muito comum, que costumo chamar de “Síndrome da IDE“.

Se você sente um ou mais dos síntomas abaixo, abra o olho: provávelmente você está com este problema e talvez não saiba:

Sintomas

• Dificuldade em se adaptar a IDEs diferentes da que você está acostumado a trabalhar
  (exemplo clássico: aqueles que amam Netbeans e não conseguem trabalhar com Eclipse ou vice-versa)
  Este síntoma fica evidente pelo ódio que usuários de uma IDE costumam apresentar em relação a outras.
• Consegue criar aplicações usando os assistentes/ferramentas da IDE, porém não sabe como os recursos do framework utilizado de fato funcionam
  (Exemplos: você cria aplicações JSF usando os editores visuais do Netbeans, porém não conhece as tags do JSF usadas na geração de suas páginas.
  Outro exemplo clássico: desconhecimento do arquivo web.xml da sua aplicação, que é automáticamente gerado pela IDE)
• A maior parte do seu trabalho no desenvolvimento de uma aplicação é executada usando o mouse e/ou assistentes fornecidos pela IDE (uma generalização do sintoma acima citado)

  (Aviso: este sintoma normalmente é a CONFIRMAÇÃO da síndrome)

IDEs facilitam o trabalho, mas não O executam

Acredito que a maior parte das pessoas acaba por cair nesta armadilha por uma razão muito simples: confundem o fato de uma IDE surgir para facilitar o trabalho do desenvolvedor, mas não executá-lo. É inegável que uma IDE facilita o nosso trabalho, porém é importante lembrar que elas FACILITAM, e não EXECUTAM.

Quem aqui nunca pegou para dar manutenção em um sistema 100% feito com assistentes de IDE e o famigerado “arrastar e soltar” que atire a primeira pedra. No caso, o único trabalho do “desenvolvedor” consistiu em executar em uma ordem pré determinada alguns dos recursos oferecidos pela sua IDE. Há trabalho do profisisonal neste caso? Sim, claro: porém incompleto, pois ele provávelmente responderá “não” (se for honesto) às duas perguntas abaixo:

Você possui conhecimento sobre como DE FATO funcionam os frameworks/linguagem/ambiente de desenvolvimento usados pela sua IDE?

Sem a sua IDE, você consegue dar manutenção no código gerado?

A IDE apresenta uma metodologia de trabalho que não é a única (e nem necessáriamente a melhor)

Este ponto normalmente é ignorado pelos viciados em IDEs. Uma IDE ao ser desenvolvida, o é baseado em um conjunto de princípios tidos como verdadeiros POR AQUELES QUE A DESENVOLVERAM. Porém, estes mesmos princípios não são universais ou mesmo os melhores possíveis.

Sim, há grande possibilidade de que seja um modo de trabalho extremamente eficiente, porém nada impede a possibilidade de existência de outros modos de trabalhos mais eficientes. Ao se fixar no modo de trabalho de uma única IDE, o usuário acaba por ignorar TODAS AS OUTRAS possibilidades de trabalho existentes e, pior ainda, acaba por ignorar a possibilidade de criar a sua própria.

Um bom exemplo seria o Netbeans. Como ferramenta de build, é usado o Ant. Se você só trabalhar com o Netbeans, irá ignorar completamente outras ferramentas como Maven, GANT, etc. Neste caso, há inclusive plugins para outras ferramentas, porém é interessante lembrar que o viciado em IDE normalmente a utiliza exatamente da maneira como foi instalada.

A IDE é uma abstração em cima de um conjunto de conhecimentos

A IDE na realidade é uma abstração de um conjunto gigantesco de conhecimentos (processo de build, conhecimento dos frameworks subjacentes, ferramentas, etc). Como consequência, aquele que utiliza apenas a IDE corre o risco de conhecer APENAS esta abstração, e não o que realmente ocorre por trás dos panos.

E aqui entra como consequência um fenômeno muito bem descrito por Joel Spolsky: a lei do vazamento da abstração (sim, fiz uma tradução tosca) (vale a pena ler o artigo: The Law of Leaky Abstractions). Toda abstração possui limitações. Como consequência, invariávelmente ocorrerão situações nas quais a abstração não prevê determinado comportamento das tecnologias abstraidas. Como consequência, as coisas não funcionarão como o esperado (pelo usuário).

Teste: se você é viciado em Netbeans, configure-o para fazer o deploy da sua aplicação usando Java Webstart. Será que as ferramentas oferecidas pela IDE REALMENTE resolverão o seu problema (me conte depois sua experiência).

Então devo fugir da IDE completamente?

Claro que não criatura! É estupidez evitar o que facilita a sua vida. É como alguém que compra um carro. Óbviamente você não precisa saber o funcionamento interno com detalhes. Porém, se um dia se encontrar no meio do deserto com seu carro estragado, é bom saber pelo menos o suficiente para que não morra abandonado no deserto (fui exagerado no exemplo? Bom, vocês entenderam aonde eu quero chegar pelo menos).