rvf, software e mitos

Archive for setembro 2008

Quando você é responsável por um novo projeto em sua empresa, a primeira coisa que deve pensar é nas pessoas que estarão dando manutenção nos próximos anos.

Um sistema deve ser projetado com simplicidade e organização, adianta dizer que, em desenvolvimento de software, um bom programador pode não ser um bom arquiteto e ao contrário do que alguns pensam, arquitetos são as pessoas que devem fazer isso! Se você não tem experiência, não crie um sistema corporativo, por favor! Você poderá estar queimando o seu filme (e o de todos os outros que pegarão esta encrenca). Não se aventure! O conhecimento para isso você só vai adquirir com muito estudo e dedicação, e saberá quando estiver preparado o suficiente para não fazer besteira.

Infelizmente a vida não é um morango (como diria o Leandro, lá da empresa), e acaba que, pessoas com alguma influência recebem carta branca para criar o “sistema protótipo” e, acredite, este sistema protótipo vira o principal, pois o gerente olha e diz “pronto, agora só falta isso e aquilo, vamos utilizar este mesmo”. Não sei quem é mais culpado neste caso, se é a pessoa que faz estas porcarias ou o gerente que aprova. Já com o sistema protótipo liberado (e em produção), começa a ser usado por 10 pessoas, após um ano 100, e por aí vai. Mas uma coisa o pseudo-arquiteto não conseguiu ver: a bagaça dele funcionava bem com 100 pessoas, porém, com 500 a coisa começa a demonstrar deficiência, mas aí já é tarde, pois ele já está integrado com todo o legado da empresa e re-fazer já está fora de cogitação, o sistema cresceu, remendou e foi remendado diversas vezes.

Qual é a situação? Você está com um legado novo (de 3 a 5 anos), mal projetado (já disse que o aprendiz de arquiteto utilizou-se das tecnologias mais legais e complicadas da época, e ainda amarrou o sistema a limitações tecnológicas entre SO/Browsers/JDKs/VMs ?), que não consegue escalar, e está explodindo em produção (e com a clientela na pressão!). Isso pode piorar, sim, quando a pessoa que está dando manutenção faz como todos os outros que passaram pelo tal sistema, pede as contas ou consegue ir para outro projeto e você, assume a bronca.

Gerentes corporativos, vocês conseguem estimar o preço de aceitar protótipos de pessoas sem o nível de conhecimento adequado para criar algo duradouro e que sobreviva a deterioração? Quantos profissionais já entraram (e tiveram que aprender a gambiarra toda), saíram, remendaram um código mal feito que está em produção gerando despesas para os clientes e um mau filme para a empresa?

Arquitetos são raros, bons arquitetos então… Nem se fala (eu mesmo conheço só um pessoalmente, que senta do meu lado esquerdo atualmente), então até entendo que nem sempre há gente capacitada para atender as demandas, mas se você vai querer mesmo fazer algo sem ter o conhecimento necessário, ao menos tente pesquisar, estudar, procurar ajuda com pessoas experientes, perguntar em fóruns como ficaria isso e aquilo, ser humilde para aceitar críticas, ver que testes são necessários, agilidade no build ainda mais, não fazer nada pelas coxas, senão, você vai acabar lendo este post e ficando bravo comigo!

Anúncios

Depois de ler os artigos do Joel, não sei por que, mas, acredito que todo mundo deveria fazer o mesmo, inclusive há uma versão em português de alguns deles. É um cara antigo no mundo de desenvolvimento de software, porém, muito atualizado. Muito mais atualizado que o gerente da sua, nossa, vossa empresa. É uma boa leitura para os desenvolvedores, testadores e gerentes, sem dúvidas.

E a sua empresa, fez quantos pontos no teste do Joel? 😉

Simples. Quer se dar bem nesta área que eu e você escolhemos? Você deve ser proativo, caso contrário, não continue em TI! Não perda o seu tempo. Não, você não vai aprender com experiência, pois ela exige proatividade. Mas afinal, o que fazer? O que NÃO fazer, eu diria!

Como?

– Pare de depender das pessoas para coisas que o Google pode lhe ajudar! Está tudo lá. Basta pesquisar e saber fazer pesquisas.

– Não deixe para o amanhã o que você pode fazer hoje, você vai se agradecer no dia seguinte.

– Não espere lhe pedirem algo que você sabe que vão lhe pedir. Pegue e faça. Não sabe como? Corre atrás, te vira! Não enrola.

– Se você não sabe, PROCURE SABER. Pesquise, compre livros, estude. Não deixe a ignorância ser mais forte.

– Não fique calado quando deveria falar! Você está ali pra isso, para opinar. E se alguém lhe dizer que esse não é o seu trabalho, ele está certo! Procure outro emprego com urgência.

– Têm algo errado? ARRUME. Vai deixar errado por quê? Por que não foi você quem fez? Azar! É seu dever zelar por onde você passa com um pingo de responsabilidade. Afinal, você é ou não é profissional?

Comece hoje mesmo.

Assim, quando dizemos “Especificação” significa uma documentação do referido. Digamos que ele está especificado –no papel-, nada concreto, apenas dito que a API deve ter ‘tal assinatura’, ao receber ‘isso’ espera-se ‘aquilo’, quando for ‘assim’ reaja ‘assim’, etc. Por exemplo: Vou criar uma especificação para controlar os meus leitores. Então eu tenho:

public interface RobsonFariasBlog {
   void aoLeitorEntrar();
   void aoLeitorSair();
   void aoLeitorPostarAlgo(String postagem);
}

Beleza. Minha API está especificada em uma interface Java. Quem implementar ela deve seguir o seguinte contrato:

– no método aoLeitorEntrar, quero que envie uma mensagem a ele, dizendo que ele é um cara bacana, etc.

– no método aoLeitorSair, quero que envie uma mensagem a ele, agradecendo a visita e bla.

– no método aoLeitorPostarAlgo, quero que verifique se o que ele está postando não contenha nenhum conteúdo referente a spam, como por exemplo “sex”, se conter não aceitar a postagem.

Ok, agora as regras também estão especificadas… Viu algum código concreto aí? Não.

Vou criar então uma implementação de referência para minha especificação:

public class RobsonFariasBlogImpl implements RobsonFariasBlog {

   public void aoLeitorEntrar() {
      System.out.println("Bem vindo! Você é um cara bacana!");
   }

   public void  aoLeitorSair() {
      System.out.println("Valeu, volte sempre!");
   }

   public void aoLeitorPostarAlgo(String postagem) {
      if (postagem.contains("sex")) {
         System.out.println("Desculpe, mas sua postagem contem conteúdo ilegal.");
      } else {
         System.out.println("Você postou: "+postagem);
      }
   }

}

 

Pronto, agora eu possuo uma implementação concreta para a minha especificação, e ao que me parece, está aceitável, pois cumpriu com as regras impostas.

Qual a vantagem de possuir uma especificação?

R: Possibilitar as pessoas que não gostaram (ou por qualquer outro motivo) da implementação default, criar suas próprias implementações e continuar compatível com o que os usuários esperam daquela API.

Uma das famosas comunidades de especificadores é a JCP, onde a comunidade ajuda a definir as especificações e o futuro da linguagem Java, através das diversas JSRs.

Exemplos de especificações:

Java Persistence API – implementações concretas: Hibernate, TopLink, OpenJPA, …

Java Server Faces – Apache MyFaces, Mojarra, BEA, BeckBase …

Enterprise JavaBeans – GlassFish, JBoss, BEA, …

 

Entre outras. Ficou claro ?

Sempre quando converso com plenos ou seniors lá da empresa da pra notar que muitos deles se acomodaram e pararam no tempo. Alguns viraram especialistas em suas tecnologias e outros vão empurrando com a barriga. O fato é que as pessoas tendem a se acomodar quando acham que, tudo que eles aprenderam é suficiente para o resto da vida. Isso se torna engraçado quando rumores de que algum sistema legado poderá ser re-escrito utilizando-se alguma tecnologia nova. Da pra ver cabeças batendo em tentar aprender o mais rápido possível alguma coisa que está na moda, normalmente Java. Logo eles, os dinossauros do Natural, Clipper, Cobol… Deveriam saber que, não vão aprender tudo em um mês, nem dois, nem dez. O processo de aprendizado na área de TI é contínuo, significando que, ou você estuda constantemente (não estou falando de faculdade, necessariamente) ou você está obsoleto. E isso vale pra você também, que sabe algo “novo”.


Anúncios