Um personagem recorrente de nossas histórias é Jarbas de Hutt. Ele foi o grande mentor do nosso herói Tupinamba. Quando Jarbas participou do projeto SAP na serraria lá do catumbí ele aliciou o jovem Tupinambá para ser programador abap. Na época o jovem Tupinambá dava acabamento nas peças de madeira e se encantou com a possibilidade e com os desafios de um trabalho onde se usa menos as mãos e mais a cabeça, mas isso é outra história. Voltando ao protagonista desta história, Jarbas é um programador veterano, um cara a moda antiga. Sua ascensão a programador abap sênior foi rápida. Corretor de imóveis por formação Jarbas deixou o sonho de ser um rico negociador de imóveis após a grande crise imobiliária de 1970. Depois da derrocada de seu sonho original Jarbas viveu alguns anos de biscates e serviços temporários até ser recrutado por um grande programa de caça talentos de uma grande consultoria. Concluiu os treinamentos iniciais com louvou e foi imediatamente contratado como abap Junior e em menos e 3 anos já figurava como um dos grandes, um mata leão, um desempata foda, um desempata jogo ou qualquer outro jargão que esses reconhecidos profissionais recebem.
Entre idas e vindas essas duas protuberantes figuras se encontraram em vários projetos e em várias empresas. A cada encontro era uma aula para Tupinambá que analisava atentamente o código a postura de seu tutor. Mais de uma década se passou e agora eles estão compartilhando o mesmo ambiente de trabalho novamente só que em uma situação diferente Tupinambá estava crescido e tinha acumulado mais experiências de que qualquer outro abap brasileiro. A célula abap, nisso incluo o próprio ECC, não suporta duas estrelas de magnitude tão grande fora da Alemanha. Após o go-live do projeto Tupinambá naturalmente superou o seu mestre e acendeu a líder da equipe de abap. Para Jarbas as glorias foram maiores. Ele se tornou Lider de TR, pós uma atuação brilhante que colocou o modulo para rodas após duras penas.
Agora Jarbas era funcional. Estava fora da programação, entretanto você pode tirar o homem da programação, mas não pode tirar a programação de um homem. Jarbas fazia questão de projetar cada detalhe dos programas que iriam rodar embaixo do guarda-chuva de seu módulo. Para isso implantou um rigoroso método de code-review. O método era tão primoroso que 90% das requests eram barradas por não atender o workbook ou o sap best pratices e algumas vezes até por briguinhas de egos entre o Jarbas e seu discípulo. Por mais que Tupinambá fosse aluno de Jarbas ele desenvolveu um estilo de programação totalmente diferente. Enquanto Jarbas era um programador metódico e disciplinado Tupinambá fazia uma programação mais efetiva abrindo mão de certos rigores técnicos para alçar seus objetivos. Essa diferença com o tempo trouxe certas rusgas à relação dos dois, mas isso é assunto para outra hora.
Certo dia Charles basis da companhia soa o alarme. O ambiente produtivo estava instável, filas de processamento paradas, chamados de lentidão chegando de todos os lados, e usuários invadindo a sala de T.I. cobrando providencias. No meio desse clima desolador ações começaram a ser tomadas. Enquanto Charles vasculhava o ambiente em busca da grande chave que estava travando as engrenagens do SAP, fui solicitando pela gerencia a integrar essa investigação. Ajudei analisando o cache de processamento do SQL server. Prontamente gerei uma lista com alguns problemas e encaminhei para Charles. Os dois primeiros itens dessa lista eram acessos a base feito por programas de TR. Mal entreguei a lista para Charles veio Jarbas me esclarecer e me explicar que a lentidão era causada por uma quantidades exacerbante de JOINS que tinham os selects. Segue a transcrição resumida do dialogo:
- Olá Haff.
- Olá Jarbas. Tudo bem?
- Tudo. Você analisou uns selects de TR?
- Sim, sim. Já passei a análise para o Charles ele falou contigo?
-Falou sim, mas está tudo certo lá. O problema é que os selects tem 4 joins cada e você sabe né?
Nessa altura já um pouco confuso.
-Sei o que Jarbas?
- O Oracle suporta 4 joins, mas o SQL é no máximo 2.
- Jarbas, o número de Joins não é o problema dos selects. Outra coisa o SQL não possui limite de joins e se bem feito não causam lentidão.
-Éhh Haff. Mas minha experiência diz que é isso. Isso acontecia direto na Bunge.
Eu posso muito bem contrapor argumentos técnicos, mas não pude fazer nada contra essa falácia lógica e só tive a opção de encerar o diálogo.
- OK Jarbas.
Algumas horas se passaram até que Charles localizou o JOB responsável pelos selects e notou algo muito interessante o programa 2 segundos após ser executado consumia 10Gb de memória do application server. De posse de dados e fatos Charles confronta Jarbas. Charles chama Jarbas até seu gabinete onde embate técnico de alto nível acontece. Segue a transcrição:
-Jarbas que porra de job é esse que consome 10 GB de memória.
-Tá tudo certo já falei com o Haff deve ser alguma coisa do ambiente.
-Coisa do ambiente o caralho
Jarbas tenta interromenper Charles que sobe em 2 pontos o tom da voz.
-Jarbas eu estou te explicando fica quieto e escuta. Isso não tem relação com o ambiente. Pega o caralho desses programas e revisa.
-Eu não fiz esses programas
-Não quero saber quem fez eu quero que a porra desse JOB pare de foder com o meu ambiente.
-Charles você não sabe conversar eu venho aqui para agente resolver o problema e você vem com essa falta de respeito.
-Falta de respeito é um programa que com some 10 Gb para processar um arquivo de retorno.
Nesse ponto a discussão estava demasiadamente acalorada e Jarbas usa de sua senioridade para terminar com a discussão. Ele sai do gabinete de Charles emburrado e pisando duro e vai para a sala da alta gerencia de T.I. O que foi conversado entre Jarbas e Hammilton, gerente do departamento não foi revelado. Jarbas deixar a sala da gerencia. Instantes depois Tupinambá é convocado para revisar os programas de TR que estavam deteriorando a performance do ambiente.
Quando Jarbas soube que o Tupinambá estava analisando o código foi falar com ele:
-Oi Tupi, quanto ao programa. Ele está bem feito, bem documentado. Deve ser o sql que se perde nos joins.
-Fiii estou analisando aqui. Está uma bosta esse seu programa
-Esse programa não é meu.
-Como não Fiiii, um perform para cada select, select asterisco em todo lugar?
-Não é meu não Tupi.
-Deu para mentir agora Jarbas. Olha aqui no log de modificação. “Criador por JHUTT”. Quem é JHUTT. Mas fica tranquilo fiii. Achei o problema os for all entries estão usando tudo internal table vazias estão vindo todos os documentos para memória.
Então Jarbas termina com a discussão em uma frase.
-Computing in memory. Esse programa já está em hanna-style.
