As IDE's de Desenvolvimento ajudam ou atrapalham?
Era uma vez que um computador com 8bits, 16KB de memória. Clock de 1MHz era o que tinha de melhor na informática. Ligava-se e já saia no prompt para escrever um programa ou carregar um da fita cassete um já feito previamente.
Passávamos tardes lúdicas digitando códigos por horas que vinham nas revistas de informática da época: Micro Sistemas, Input, MSX Micro entre outras que vinham exemplos de programas errados de propósito com a famosa “errata” da edição seguinte.
Chegávamos ao ponto de economizar bytes de código para que o programa coubesse na memória do computador. Quem usou um TK85 da Microdigital com 16KB de memória, sabe o que eu estou falando. Saber uma linguagem mais rápida e econômica como C e Assembler era o que tinha de melhor para que o computador funcionasse rápido.
Com o tempo a memória foi aumentando, o processador melhorando. Ficamos boquiabertos vendo a maravilha da informática de 1989: um Commodore Amiga 500, rodando o Blood Money. Que maravilha a computação poderia fazer pela gente!!!
Mas sempre havia a “tela preta” para se digitar os códigos. Quem dominasse o “lado negro” do computador conseguia espremer os bits e tirar tudo que dava de alguns Kbytes de memória e de processadores que hoje não equipam nem calculadoras baratinhas da China. Os desenvolvedores na época, também conhecidos como “escovadores-de-bits”, versão Neandertal do que seriam os Hackers de hoje que no sentido real da palavra são os “fuçadores” que futricavam em tudo para descobrir como funcionavam as coisas.
Nisso descobrimos que além de se divertir desbravando os bits e bytes de uma máquina, podíamos ganhar um troco para comprarmos mais livros e revistas. E nisso fomos crescendo, alguns seguiram na lida e outros foram fazer coisas melhores.
Na evolução da programação, todo mundo tinha seu “kit de ferramentas” para escrever programas. Sabendo disso uma das maiores empresas de tecnologia da época, a Borland lançou o Turbo Pascal, que foi considerada a melhor IDE já projetada para facilitar a vida do desenvolvedor de programas, compilador, debugger, tudo integrado. Muitas outras vieram, da própria Borland inclusive.
Novamente a Borland inovou as IDE’s de desenvolvimento com o Delphi 1.0 (versão melhorada do Turbo Pascal) e nesse momento a complexidade de se digitar linhas e linhas de código era escondida, encapsulada para que se tivesse produtividade na criação de novos sistemas. Modelagem gráfica de um sistema, melhor ainda.
De 486’s a Pentium’s as coisas foram ficando rápidas e sistemas mais complexos sendo construídos. De Megas para Gigas, as coisas foram se transformando. Não foi diferente com o desenvolvimento de sistemas. As novas IDE’s são consoles de milhares de assistentes para gerar códigos simplesmente se arrastando componentes de uma janela para outra. Netbeans, Eclipse, JDeveloper. Cada um puxando brasa para o seu assado para se intitular o melhor ambiente de desenvolvimento.
Conheço muitas pessoas que não vivem sem a sua IDE. Ficam de mãos atadas se não tem aquela IDE funcionando nesse ou naquele sistema operacional. Realmente elas ajudam e muito nossa produtividade em muitas vezes. Mas um dia que precisarmos resolver algo e elas não estiverem ali à mão. Como seria?
Como vim da “tela preta” o "lado negro" do CRT, não me sinto em pânico ao digitar um programa em Java ou C no “notepad” ou no “vi” e depois compilar como o javac ou cc na linha de comando. Mas isso é o fim do mundo para muita gente. Nada contra, mas deveríamos saber como funcionam as coisas por trás dos cliques e “Drag & Drops” da programação.
Muito tem se falado em refatoração de código, melhoria continua dos sistemas e processos de desenvolvimento. Novos cargos são criados a cada dia para que o código saia impecável, rápido, funcional e sem bugs. Engenheiros, arquitetos, milhares de diagramas necessários, é fato. Mas a casa sempre acaba caindo. Por quê?
No meu ver acho que falta aquele senso de saber como as coisas realmente funcionam. De como podemos tirar o máximo de uma tecnologia usando padrões sem reinventar a roda toda vez que vamos construir um novo sistema. Sabermos exatamente como interligar todos os componentes como um todo. Como um maestro regendo uma orquestra de códigos e frameworks para que tudo funcione perfeitamente. Criando sinergia nos processos tanto de desenvolvimento quanto execução dos sistemas.
Mas as coisas estão mudando, ainda bem.
Passávamos tardes lúdicas digitando códigos por horas que vinham nas revistas de informática da época: Micro Sistemas, Input, MSX Micro entre outras que vinham exemplos de programas errados de propósito com a famosa “errata” da edição seguinte.
Chegávamos ao ponto de economizar bytes de código para que o programa coubesse na memória do computador. Quem usou um TK85 da Microdigital com 16KB de memória, sabe o que eu estou falando. Saber uma linguagem mais rápida e econômica como C e Assembler era o que tinha de melhor para que o computador funcionasse rápido.
Com o tempo a memória foi aumentando, o processador melhorando. Ficamos boquiabertos vendo a maravilha da informática de 1989: um Commodore Amiga 500, rodando o Blood Money. Que maravilha a computação poderia fazer pela gente!!!
Mas sempre havia a “tela preta” para se digitar os códigos. Quem dominasse o “lado negro” do computador conseguia espremer os bits e tirar tudo que dava de alguns Kbytes de memória e de processadores que hoje não equipam nem calculadoras baratinhas da China. Os desenvolvedores na época, também conhecidos como “escovadores-de-bits”, versão Neandertal do que seriam os Hackers de hoje que no sentido real da palavra são os “fuçadores” que futricavam em tudo para descobrir como funcionavam as coisas.
Nisso descobrimos que além de se divertir desbravando os bits e bytes de uma máquina, podíamos ganhar um troco para comprarmos mais livros e revistas. E nisso fomos crescendo, alguns seguiram na lida e outros foram fazer coisas melhores.
Na evolução da programação, todo mundo tinha seu “kit de ferramentas” para escrever programas. Sabendo disso uma das maiores empresas de tecnologia da época, a Borland lançou o Turbo Pascal, que foi considerada a melhor IDE já projetada para facilitar a vida do desenvolvedor de programas, compilador, debugger, tudo integrado. Muitas outras vieram, da própria Borland inclusive.
Novamente a Borland inovou as IDE’s de desenvolvimento com o Delphi 1.0 (versão melhorada do Turbo Pascal) e nesse momento a complexidade de se digitar linhas e linhas de código era escondida, encapsulada para que se tivesse produtividade na criação de novos sistemas. Modelagem gráfica de um sistema, melhor ainda.
De 486’s a Pentium’s as coisas foram ficando rápidas e sistemas mais complexos sendo construídos. De Megas para Gigas, as coisas foram se transformando. Não foi diferente com o desenvolvimento de sistemas. As novas IDE’s são consoles de milhares de assistentes para gerar códigos simplesmente se arrastando componentes de uma janela para outra. Netbeans, Eclipse, JDeveloper. Cada um puxando brasa para o seu assado para se intitular o melhor ambiente de desenvolvimento.
Conheço muitas pessoas que não vivem sem a sua IDE. Ficam de mãos atadas se não tem aquela IDE funcionando nesse ou naquele sistema operacional. Realmente elas ajudam e muito nossa produtividade em muitas vezes. Mas um dia que precisarmos resolver algo e elas não estiverem ali à mão. Como seria?
Como vim da “tela preta” o "lado negro" do CRT, não me sinto em pânico ao digitar um programa em Java ou C no “notepad” ou no “vi” e depois compilar como o javac ou cc na linha de comando. Mas isso é o fim do mundo para muita gente. Nada contra, mas deveríamos saber como funcionam as coisas por trás dos cliques e “Drag & Drops” da programação.
Muito tem se falado em refatoração de código, melhoria continua dos sistemas e processos de desenvolvimento. Novos cargos são criados a cada dia para que o código saia impecável, rápido, funcional e sem bugs. Engenheiros, arquitetos, milhares de diagramas necessários, é fato. Mas a casa sempre acaba caindo. Por quê?
No meu ver acho que falta aquele senso de saber como as coisas realmente funcionam. De como podemos tirar o máximo de uma tecnologia usando padrões sem reinventar a roda toda vez que vamos construir um novo sistema. Sabermos exatamente como interligar todos os componentes como um todo. Como um maestro regendo uma orquestra de códigos e frameworks para que tudo funcione perfeitamente. Criando sinergia nos processos tanto de desenvolvimento quanto execução dos sistemas.
Mas as coisas estão mudando, ainda bem.
Comentários
Postar um comentário