você trabalha no Jurassic Park?

  • 10

você trabalha no Jurassic Park?

0 Flares Twitter 0 Facebook 0 Filament.io 0 Flares ×

O mundo da informática evolui a cada dia.
Acompanhando as notícias pelos blogs por aí descobrimos novas tecnologias, linguagens , padrões e muito mais coisas.

Entretanto no nosso ganha pão precisamos respeitar o que fazemos lá, afinal é o resultado do nosso esforço que gera a remuneração que coloca comida na mesa de casa.

Muito bem, trabalhar com uma coisa não impede que você tenha interesse em outra. Mas quando começamos a pesquisar mais sobre diversos assuntos novos descobrimos que aquela tecnologia que considerávamos nova, já é usada por empresas há dois ou três anos e já discutem em trocar por outra mais nova ainda.

Verifique se essas 10 perguntas descrevem o ambiente onde você trabalha:

1 – Sua ferramenta de controle de versão é o CVS ou Source Safe?

Pois é, já vi diversas discussões sobre qual o melhor sistema de controle de versão, isso é algo um tanto subjetivo, mas uma coisa é certa: o CVS é ultrapassado.

Quase todos os projetos open source mais importantes que conheço moveram há anos os seus repositórios para SubVersion, que faz tudo o que o CVS faz com muitas melhorias. Hoje se discute ainda o uso do Git, que atualmente é quem tem a árdua tarefa de gerenciar a gigantesca equipe de desenvolvedores do kernel do Linux.

2 – A linguagem mais nova que você desenvolve tem mais de 10 anos?

Não quero dizer a sua principal linguagem de desenvolvimento, apenas a linguagem mais nova que você desenvolve, nem que seja de vez em quando.

Se você trabalha em algum banco provavelmente mexe com Cobol, que é de 1959 e tem 48 anos.

Você trabalha com C? é de 1972 tem 35 anos! C++? Esse tem 24!

Você pode pensar: “há não, eu sou moderno, eu mexo com Java!”.
Pois é, esse também tem 12 anos já!

E PHP não fica muito atrás, já tem seus 13 aninhos, seguido do ASP com 11.

3 – O processo de deployment da sua empresa não é automatizado?

Se você trabalha numa empresa média ou grande, deve ter pelo menos um ambiente de desenvolvimento, um de homologação e testes, e outro de produção.

Normalmente o pacote que você fez e colocou em desenvolvimento precisa ser reproduzido nos outros ambientes.

Se isso é feito manualmente, além da perda de tempo existe também o problema do erro humano, onde por exemplo pode acontecer de um pacote errado subir para o ambiente de homologação ou produção.

Algumas empresas tem isso automatizado tudo em ambiente UNIX, onde você simplesmente commita as coisas e o servidor faz todo o resto. As soluções mais modernas apostam em outras soluções como o Apache Continuum e o Cruise Control.

4 – Sua empresa não oferece acesso remoto?

É preciso fazer uma execução de uma rotina agora, 4 da manhã de um sábado e você não tem escolha a não ser ir pessoalmente até a empresa para fazer isso?

Se isso para você não é só normal, mas óbvio, saiba que muitas empresas usam soluções proprietárias ou open source para fazer tudo sem sair de casa.

5 – Ferramentas open source são consideradas a mesma coisa que ferramentas gratuitas?

Esse conceito de “free software” vem de uma interpretação errada do inglês, onde além de gratuito em alguns contextos pode significar livre, sem impedimentos. O exemplo clássico de uso como gratuito é “free beer” e como livre é “free speech“.

E por que você deve tratar as ferramentas open source e gratuitas de maneira diferente? Não é tudo de graça mesmo?
Bom, o motivo é muito simples. Uma ferramenta gratuita não tem o seu código fonte aberto, o que pode ser perigoso.
Imagine que sua empresa adote um software proprietário gratuito em algum processo, e em poucos meses essa ferramenta se tornou essencial para o seu trabalho. De repente, numa atualização de software você descobre que a ferramenta agora é proprietária e não pode usar mais! E agora? E todo o seu esforço foi em vão? Como convencer o seu chefe agora a desembolsar uma grana em licença ?

Com projeto open source isso não acontece, mas também tem suas desvantagens, normalmente ele não tem suporte técnico e sem mais nem menos o projeto pode ser abandonado se ninguém quiser assumir a coisa.

6 – Linux é considerado coisa de estudante?

Tem empresas que ainda tem a imagem que Linux é aquela tela preta com o cursor de login piscando e que só um estudante consegue mexer para “brincar de rede”.

Só a IBM tem 15 mil clientes já com Linux e a Oracle também investe muito nesse mercado.
Se fosse algo de estudante, teria tanta “gente grande” ganhando dinheiro com isso?

E tem mais, não comente com alguém que Linux não tem ambiente gráfico, isso pode ser motivo de piada…

O Linux tem diversos tipos de ambientes gráficos, desde os mais completos como KDE e Gnome, como os mais leves como Fluxbox e WindowMaker. Além disso, tem excelentes efeitos visuais, alguns até serviram de inspiração e foram incluídos no Windows Vista.
O Beryl é um dos projeto que cuida dessas melhorias visuais.

7 – Utiliza versões antigas de softwares proprietários?

Usar versão antiga de softwares proprietários normalmente é um problema grave, pois hoje a tecnologia ela não trabalha isolada, ela sempre se integra com outra, talvez open source, que provavelmente é mais atual e contempla mais opções.

O pior de tudo é quando você tem um problema e a solução que o fornecedor te dá é simplesmente a frase: “atualize o seu software”. E convenhamos, ele tem até motivos para pedir isso. Imagine que você tenha um fornecedor para aplicações Windows, seria viável manter versões para Windows 3.1 ?

8 – “Isso é padrão” é a desculpa usada para justificar a ignorância?

Numa discussão de alto nível, normalmente as pessoas que recém contratadas questionam alguns comportamentos diante de determinados problemas. Se a solução adotada pela empresa for viável, ela terá argumentos para sustentar a atitude, senão ela pode simplesmente se acomodar no mar de ignorância e te jogar na cara: “olha, isso aqui é padrão, alguém decidiu isso antes e não tem o que discutir”. O que temos como resultado?

Normalmente, além do desperdício de dinheiro temos espalhados por alguns blogs algumas pérolas da informática.

9 – Testes de software são perda de tempo?

E corrigir um bug é ganho de tempo por acaso?

Não, pelo contrário, você procurar e corrigir um bug gasta muito mais tempo do que criar um teste.

Isso sem falar no refactoring, com testes você pode fazer refactoring sem medo de ser feliz. =)

Ter uma equipe de qualidade garante um software mais maduro para os usuários. Com certeza é melhor um relatório de bugs do pessoal de qualidade do que o usuário reclamando com o seu chefe.

10 – Metodologia ágil é desenvolver e corrigir bugs ao mesmo tempo?

Não, não, o manifesto ágil descreve bem o que a metodologia ágil propõe, que se resumem a quatro tópicos:

  • indivíduos e interações ao invés de processos e ferramentas
  • software funcionando ao invés de vasta documentação
  • colaboração do cliente ao invés de negociação de contrato
  • responder às mudanças ao invés de seguir um plano

Hoje muito se fala em XP e SCRUM, além de ler sobre o assunto , vale a pena escutar as experiências reais nos podcasts do site da Improve It.


Jurassic Park

Se você se identificou metade desses tópicos, parabéns , você pertence ao Jurassic Park!

Fernando Boaglio, para a comunidade. =)


About Author

Fernando Boaglio

???

10 Comments

Aldrin Leal

16/outubro/2007 at 11:35 am

Excelente Post!

Me lembra um pouco o “Joel Test”. Obviamente, mais atual.

Parabéns!

Bruno

16/outubro/2007 at 1:22 pm

Ruby? 14 anos…

Bom post.

Rubem Azenha

25/outubro/2007 at 7:45 am

Qual o preconceito com o CVS? 😛

Misael Santos

17/janeiro/2008 at 8:02 am

A analogia é tosca, os dinossauros não sobreviveram até hoje dominando a maior parte do mundo como o pessoal que trabalha com as tecnologias que você citou.

Rafael Barra

17/janeiro/2008 at 10:45 am

Excelente o seu post, muitíssimo bem humorado.

Infelizmente, eu retiraria o item 2. Julgar uma linguagem pela sua idade, perdoe-me a crítica, é uma atitude um pouco cega e extremista.

Uma empresa ser jurássica ou não ao julgar pela linguagem que ela usa é determinado, basicamente, por uma análise no seguinte sentido: ela usa a linguagem que melhor atende ao seu problema? Você usa a linguagem mais eficiente para a solução do problema? Não adianta utilizar a linguagem mais “nova” possível se uma linguagem mais “antiga” atende à solução com maior eficiência.

Enfim, uma empresa que só desenvolve em C++, a não ser que desenvolva aplicações específicamente industriais, não tem chance em um mercado para a Web. Mas uma empresa que só desenvolve em Java, nunca teria espaço na indústria microeletrônica. Uma empresa que possui analistas que sabem programar em ambas as linguagens, com certeza se dá bem em um mercado mais diversificado, pois sabe escolher a melhor solução em software para o problema. É isto que diferencia, inclusive, o engenheiro de software de um programador.

Um abraço!

Rafael.

antonio henrique

17/janeiro/2008 at 12:50 pm

Concordo com o Rafael a respeito da idade das linguagens de programação.
Mas, no geral, gostei muito do post, principalmente nas perguntas sobre testes de software, porque infelizmente ainda hoje poucas empresas e profissionais de TI dão importância para isso em um mundo tão competitivo.

Abraços.

Antônio Henrique

Handerson Frota

17/janeiro/2008 at 10:06 pm

Ótimo post, parabêns, mas deve discordar em alguns pontos, como o uso do CVS, tudo bem é uma melhoria, mas fora o tortoise não existem plugins 100%, por enquanto eu tento evitar o uso do SVN pois os plugins para ele ainda não estão 100% estáveis, isso tanto para o eclipse quanto para o netbeans.

Sobre as linguagens não achei uma analogia muito boa, existem excelentes programas em cobol que ainda hoje rodam, e já vi várias empresas se darem mau tentando migrar, para java ou qualquer outra linguagem. Eu trabalho com java principalmente e acho que em alguns pontos a linguagem tem evoluído muito, principalmente a sua JVM.

Bem no mas, ótimo post, parabéns mais uma vez.

Stan

18/janeiro/2008 at 3:51 pm

Também concordo que a idade da linguagem nada tem a ver. Smalltalk é antiga pra caramba, mas ainda é muito mais moderna que muita linguagem novinha que tem por ai 🙂 C também é outro exemplo… indispensável para muitas tarefas.

Alexandre Drummond

20/novembro/2009 at 3:13 pm

@antonio henrique
Concordo. Um exemplo disso é a linguagem Ruby: criada em 1993, desde 1995/1996 é utilizada em ambientes de produção. Mas a linguagem se moderniza e no início deste ano deu um novo salto evolutivo com a versão 1.9.1. Portanto, apesar de seus 16 anos, é cada vez mais uma boa linguagem de se programar. É um suplício programar em Cobol não por sua idade, mas porque foi mal projetada, e já era ruim desde seu primeiro dia…

A importância dos testes de software | A Regua Relativa

4/fevereiro/2011 at 3:55 pm

[…] Leia Mais Desenvolvedores odeiam testar Você trabalha no Jurassic Park? […]

Leave a Reply

Quero saber mais sobre…

Inscreva-se para receber as novidades!

Arquivos

0 Flares Twitter 0 Facebook 0 Filament.io 0 Flares ×