Tens a certeza de que o teu SQL é à prova de bala?

Quando os programas estão mal feitos por terem código duplicado, se os reescrevemos ficam mais curtos. Mas se, pelo contrário, estiverem mal feitos por não estarem devidamente estruturados em várias classes com vários métodos, podem ficar bem mais longos se os reescrervemos de acordo com as boas prácticas.

A maior parte dos programadores ABAP são como os cisnes. Quando casam com o ABAP é para sempre e são-lhe eternamente fiéis.

Depois de mais de 10 anos a usar Wordpress, o mundo evoluiu e o Abapinho decidiu evoluir com ele.

Demasiadas regressões acontecem porque alguém se esquece de fazer CLEAR ou de não fazer CLEAR a uma variável.

Os RANGEs têm propriedades interessantes.

Vamos por partes. Imagina um cenário em que tens uma tabela de parametrização com vários níveis de detalhe que podem ou não estar definidos: BUKRS (empresa) WERKS (plant) LGORT (depósito) Quando um dos campos está vazio, é um wildcard, ou seja, é válido para todos os valores.

Depois de 10 anos a usar o Evernote, este ano comecei a procurar alternativas. No início o Evernote era fantástico. Mas parou no tempo e deixou-se ultrapassar. Entretanto apareceram tantos conceitos novos: jardins digitais, backlinks , Zettelkasten , Evergreen notes , MOCs, etc. E o Evernote lá continua, igual ao que sempre foi, condicionando-nos a tirar notas em vez de criar notas.

Um dos primeiros artigos do Abapinho foi sobre o Evernote. Ou melhor, foi sobre a importância de tomar notas. Mas nele eu explicava como uso o Evernote para tirar essas notas. Parece mentira mas passaram 10 anos. 10 anos a tirar notas no Evernote. Infelizmente parece que quem faz o Evernote deve ter parado de tirar notas há muitos anos porque o Evernote pouco evoluiu desde que o adoptei. Aliás, na versão iOS, piorou. Já lá vão 10 anos e ainda não conseguiram sequer (tentar?) implementar uma forma decente para editar tabelas. Burros.

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

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.

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>

É 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.

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.

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?