Patrocinado por
Patrocinado por Inetum

abapBlame - O meu novo projecto open source

images/thumbnail.jpg - Thumbnail
O gestor de versões do ABAP é muito mau. Para além de todos os seus defeitos, ele não permite de forma fácil saber quem fez o quê e quando. O git, que é um gestor de versões a sério, permite obter essa informação facilmente através da sua ferramenta git-blame. Devido a isto, muitos ABAPers habituaram-se a acrescentar o seu nome e data a todas as linhas de código que acrescentam, que apagam e que alteram. Assim, à medida que um programa ABAP vai sendo mais modificado, mais ilegível se vai tornando e mais difícil é navegar entre versões para saber quem fez o quê.

O caminho mais curto para ir de SELECT a RANGE

images/thumbnail.jpg - Thumbnail
Hoje debruçamo-nos sobre como tentar optimizar o código para transformar um SELECT num RANGE.

É tão simples converter uma MESSAGE numa EXCEPTION

images/thumbnail.jpg - Thumbnail
Há alguns anos atrás mostrei como se podia converter uma MESSAGE normal numa excepção tipificada. Entretanto o ABAP evoluiu um bocadinho e agora, na versão 7.40, aquela solução complexa já não é necessária.

A árvore dos pacotes Z - Uma proposta modesta

images/thumbnail.jpg - Thumbnail
Quem lê o Abapinho sabe que eu defendo o uso e abuso do ABAP Package Concept. Hoje em dia a primeira coisa que eu faço quando começo um desenvolvimento novo é criar-lhe um pacote encapsulado que guardará todos os seus objectos que, nos casos mais complexos, será um pacote “Main” ainda subdividido em vários sub-pacotes. Fica aqui a minha modesta proposta para criar uma árvore de pacotes Z que ajude a organizar aquilo que é normalmente uma confusão danada.

Conteúdo de tabela interna numa ALV

images/thumbnail.jpg - Thumbnail
Não sei há quanto tempo é que isto está disponível mas só agora descobri que é muito fácil ver numa ALV o conteúdo de uma tabela interna durante debug.

Atalhos mágicos para menus

images/thumbnail.jpg - Thumbnail
Se tu que estás a ler isto achares que tudo o que está escrito no Abapinho é literalmente verdade, o que te vou dizer a seguir vai desiludir: quando disse mágico não quis dizer que era sobrenatural. É só uma forma mais abrilhantada de dizer que é surpreendente e inesperado. Tomei esta liberdade um bocado como quando dizes “estou morto de sede” e no entanto ainda estás vivo. Tendo clarificado isto, podemos continuar.

Atalho para gravar lista em ficheiro local

images/thumbnail.jpg - Thumbnail
O SAP está replecto de recantos refundidos e rebuscados raramente reconhecidos que o Abapinho se regozija por revelar. O comando %pc é equivalente à opção de menu Sistema/Lista/Gravar/File local:

IF sem IS INITIAL em métodos booleanos

images/thumbnail.jpg - Thumbnail
O sistema do cliente onde trabalho actualmente foi finalmente actualizado para o 7.50 e, depois de tantos anos preso ao ABAP convencional, posso desfrutar as maravilhas introduzidas no 7.40. São às dúzias essas maravilhas, e não vou começar aqui a fazer artigos sobre cada uma porque já existem artigos espalhados pela net sobre quase todas elas o Abapinho faz sempre o possível por ensinar algo novo ou, pelo menos, pouco conhecido. Mas há uma singela funcionalidade que, não sendo nada de extraordinário, me agrada: já não é preciso fazer IS INITIAL no comando IF quando a condição é um método que retorna um booleano.

Variantes de activação da SAAB

images/thumbnail.jpg - Thumbnail
Em tempos falámos na SAAB e nas vantagens de a utilizar para melhor conseguir analisar e descobrir problemas no nosso código. Nesse artigo não expliquei uma coisa que é realmente importante: variantes de activação.

Enhancements implícitos em estruturas de dados

images/thumbnail.jpg - Thumbnail
Já todos usámos enhancements implícitos para adicionar código ao início ou final de funções, forms ou métodos standard. Mas é menos conhecido o facto de que também podemos adicionar campos a estruturas de dados, estejam elas declaradas como TYPES ou ou directamente como DATA.

Guarda dados XML numa ST (Simple Transformation)

images/thumbnail.jpg - Thumbnail
No outro dia estava a aprender sobre ST (Simple Transformations) e lembrei-me que, ainda que tenha sido desenvolvida para transformar dados, é uma forma práctica de guardar dados XML. Temos o seguinte XML: <cocktails> <cocktail id="gt" nome="Gin Tonic"/> <cocktail id="ws" nome="Whiskey Sour"/> <cocktail id="cl" nome="Campari Laranja"/> </cocktails>

Quando o código cheira mal

images/thumbnail.jpg - Thumbnail
É frequente ao programar começar a sentir um cheiro desagradável. Normalmente não consigo logo identificar o que é. Sinto apenas uma leve mas incómoda fragrância. À medida que vou cheirando com mais propósito vou conseguindo perceber de onde vem. Mas mesmo nessa altura, muitas vezes ainda não me é perfeitamente claro porque é que aquele cheiro dali vem.

Não é para reutilizar que se encapsula

images/thumbnail.jpg - Thumbnail
Desde 1998 que oiço colegas ABAPers dizerem que não vale a pena meter determinado código numa função ou método porque não lhes parece que este vá tornar a ser reutilizado. E lá vão continuando na SE38 a fazer os seus reports cheios de includes. A ideia de que a principal razão para encapsular código é poder reutilizá-lo é um dos maiores mal entendidos da história do nosso planeta.

Refactorizarás: Extrair método

images/thumbnail.jpg - Thumbnail
No mundo do SAP, o código ABAP onde cai é onde fica. Num dia o Manel faz uma coisa mal porque está com pressa ou não sabe fazer melhor. Um ano depois pedem ao António para fazer uma pequena alteração. O António vê a asneira do Manel mas não a melhora porque, por alguma razão, no mundo do SAP, alterar código que está a funcionar, por muito mau que seja, é tabu. Em vez disso, acrescenta o seu código ao já existente de forma geralmente acrítica. Esta atitude, quando adoptada por todos, contribui para uma inevitável erosão do código de um sistema que, após alguns anos, se tornará ingerível. No meu entender, isso está errado e vai contra os interesses do cliente. Aliás, mesmo se o cliente não quiser que se mexa no código antigo… eu mexo. Quem é ele para me dizer como é que se programa?

Comentário sobre comentários

images/thumbnail.jpg - Thumbnail
Na escola aprende-se que o código deve ter sempre comentários. Depois, na vida real, descobrimos que nem toda a gente prestou atenção na escola. Sempre tive o cuidado de comentar os vários passos do meu código, especialmente as partes mais obscuras ou que não são auto-explicativas. Mas depois de ler o livro Clean Code do Uncle Bob, a minha opinião mudou. Hoje acredito que quanto menos comentários melhor. E no entanto não acho que esta mudança seja contraditória.