"
Apoiado por

ABAP, o lobotomizador

O João estuda Engenharia Informática na Universidade onde aprende Java, polimorfismo, encapsulamento e uma série de outras técnicas e boas prácticas. Quando termina o curso é contratado por uma empresa para trabalhar em SAP. No curso de introdução ao ABAP que a empresa lhe oferece, a primeira coisa que ensinam é como fazer o programa ZJOAO. Explicam assim:

“Vais à SE38, crias o programa ZJOAO e crias logo os includes ZJOAO_TOP, ZJOAO_FRM e ZJOAO_SEL. Depois metes as variáveis todas no _TOP, o ecrã de selecção no _SEL e todos os FORMs no _FRM. A partir daqui é só ires programando. Primeiro escreves START-OF-SELECTION e a seguir fazes todos os SELECTs e depois escreves END-OF-SELECTION e mostras tudo numa ALV. É simples, vês? Bem-vindo ao ABAP.”

Lá vai então o João todo contente programar para um cliente e, quando começa a ver os programas que lá encontra constata que, de facto, quase todos têm um _TOP, um _SEL, um _FRM e começam com START-OF-SELECTION. Mas fica intrigado porque só alguns têm END-OF-SELECTION.

Passado um mês a trabalhar na SE38, o João já mal se lembra de tudo o que aprendeu no curso de engenharia. Um ano mais tarde já faz coisas a sério, complexas e de responsabilidade. Os programas dele têm milhares de linhas distribuídas por vários FORMs (que ele escreve no _FRM) com centenas de linhas cada um. Os FORMS não usam parâmetros porque seria um disparate andar a passar as variáveis de um lado para o outro quando se podem meter todas no _TOP e ficam mais facilmente acessíveis. Assim, o _TOP dos programas do João acabam com dúzias de variáveis globais.

Até que alguém lhe fala em encapsulação e ele diz:

“O quê? Fazer módulos de função reutilizáveis na SE37? Sim, eu podia fazer alguns, mas sei que nunca mais ninguém vai reutilizar isto por isso não vale a pena.”

Até que alguém lhe fala em ABAP OO e na transacção SE24 e ele diz:

“Ah, as classes? É pá isso é mau porque demora imenso tempo e dá imenso trabalho e não dá jeito nenhum para fazer debug. Neste cliente os prazos são apertados e além disso não vejo vantagem nenhuma em usar classes nas coisas que eu faço.”

E lá segue a sua vida, acrescentando cada vez mais linhas aos seus muito queridos _FRM e o _TOP.

Até que alguém lhe fala em Software Design Patterns e o João diz:

“É pá, aprendi UML na Universidade e odiei. Não serve para nada. Além disso esses desenhos têm classes e no SAP eu acho que não faz sentido usar classes.”

Até que alguém lhe fala nas virtudes do SOLID e ele diz:

“Hum… isso parece interessante e se tivesse tempo até aprendia em casa mas no SAP isso não dá porque o SAP é diferente porque a maneira de programar em ABAP não tem nada a ver e não dá para aplicar isso.”

Até que alguém lhe fala no ATC (ABAP Test Cockpit) e ele diz:

“O que é isso? Experimentei num programa meu e deu tantos erros, todos inúteis, que não tive paciência”.

E lá segue a sua vida escrevendo programas tranquilamente sem ter de se preocupar com vulnerabilidades, falhas de nomenclatura, erros semânticos, excepções por apanhar, etc.

Até que alguém lhe fala em TDD (Test Driven Development) e ABAP Units e ele fica com os olhos em bico e diz:

“Test quê? Eu já vi isso do ABAP Unit algures na SE80 mas não liguei. Para fazer testes eu peço uns dados ao funcional e vejo se funciona e depois digo-lhes que já está e eles que testem o resto.”

Até que alguém lhe diz que Shared Objects é óptimo para fazer cache de instâncias em memória e ele diz:

“Cache? Eu normalmente faço uma tabela ZRESULTADOS e guardo lá os dados temporariamente e depois faço SELECT àquilo. Mas é rápido por isso está bom assim. E depois faço um programa para apagar a tabela de tempos a tempos. Funciona muito bem.”

Até que alguém lhe fala no SAP Package Concept e na utilização de Package Interfaces e ele diz:

“Pacotes? Se for de FI meto tudo no ZFI, se for de SD meto tudo no ZSD e se for de MM meto tudo no ZMM. Assim nunca me engano.”

Até que alguém lhe fala nos ADT (ABAP Development Tools) e no Eclipse e ele diz:

“Eu usei Eclipse na Universidade. Mas isso é para Java. Para o ABAP não vejo vantagem nenhuma.”

Até que alguém lhe fala no abapGit que permite usar o maravilhoso git em ABAP, e ele diz:

“Mas eu sempre pude fazer versões no ABAP! Além disso normalmente quando quero guardar versões ou copiar código entre sistemas uso o NOTEPAD.EXE que nunca falha.”

E porque no mundo do SAP os clientes raramente se preocupam com a qualidade do código, não há quaisquer padrões nem normas de indústria, é raro haver controlo de qualidade e, quando há, é quase sempre feito por alguém que pensa como o João, passados 10 anos o João lá continua, de roda da SE38, a criar os seus _TOPs, _FRMs e _SELs.

Até que alguém lhe pergunta a profissão:

“Sou Engenheiro Informático.”

Não és não.

10 comentários a “ABAP, o lobotomizador”

  1. Ruthiel Diz:

    Eh pah… Obrigado!

    Temos diversas discussões do género no nosso grupo de trabalho e, infelizmente, penso que havemos de as ter por muitos anos ainda.

    Enquanto não olharmos para o ABAP de uma forma diferente, organizada, estruturada e aplicarmos todas as ferramentas que temos ao nosso dispor para usá-la de uma forma eficiente havemos sempre de encontrar imensos “Joõezinhos”.

    Por outro lado, em defesa do João (que sou eu ainda…), apesar de estar certo que ele consegue abrir horizontes sozinho recorrendo à grande quantidade de material de a SAP disponibiliza entre outras muitas coisas (OOP pode-se aprender em muitas linguagens conhecidas), é muito difícil chegar e querer ser diferente sem nenhuma base e nenhum apoio, apoio esse que não é indispensável, mas de extrema importância na minha opinião.

    Parabéns pela análise certeira.

  2. Pedro Correia Diz:

    Acho que é consequência da aversão à aprendizagem no geral. Em qualquer área tecnológica deve—se estar disponível para aprender coisas novas. E essa mentalidade afugenta os que acham que já aprenderam tudo o que há para aprender

  3. Nuno Godinho Diz:

    Somos todos um pouco João :-) O objectivo é tentar ir sendo cada vez menos.

  4. Nuno Morais Diz:

    O Pessoal ainda não percebeu que isto não e só 0 e 1.

  5. Erick Carvalho Diz:

    Melhor parte: “Até que alguém lhe pergunta a profissão: Sou Engenheiro Informático.”

    Muito bom! kkkkkkkkk

  6. Nuno Godinho Diz:

    Eh eh eh olá Erick :-)

  7. António Portugal Diz:

    Alguém conhece uma forma standard de comparar de uma só vez, o código de uma classe entre ambientes, por exemplo entre DEV e PRD, sem ter de o fazer secção a secção, método a método, na administração de versões?
    E sabem de alguma ferramenta/programa standard para fazer o download e upload de uma classe global de uma só vez? Existem programas Z na net, mas muitas vezes não é possível disponibiliza-los em determinadas máquinas, não funcionam para todas as versões, etc.
    E colocar uma classe completa numa ordem de transporte, de uma forma simples?
    Alguém já se deparou com essa necessidade e pode partilhar a solução?
    Obrigado,

  8. Norton Senna Diz:

    Parabéns pelo Post. Tive a sorte de encontrar, durante minha vida profissional, pessoas que me fizeram pensar fora da caixa, a lutar contra a mediocridade.
    Publicações como essa mudam as mentes das pessoas.

  9. Nuno Godinho Diz:

    Obrigado Norton! É gratificante ouvir isso.

  10. Nuno Godinho Diz:

    Olá António,

    Um amigo meu desenvolveu algo que permite comparar objectos entre ambientes. Se quiseres envio-te por email.

    Em relação a ferramentas para copiar objectos completos existe a antiga SapLink de que o Abapinho falou há alguns anos atrás:
    https://abapinho.com/2012/12/saplink/

    E existe o extraordinário abapGit sobre o qual pretendo escrever em breve:
    https://github.com/larshp/abapGit

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).