Categorias
Clube dos 10 Engenharia de Software

você trabalha no Jurassic Park?

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.

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

Fernando Boaglio, para a comunidade. =)