Não há coisa pior do que ver código a abusar das variáveis. São tão delicadas e no entanto tão mal tratadas, coitadas. E a quem as tem de ler. A pior forma de tratar uma variável é fazê-la global. Parece mentira mas em 2025 este crime continua a flagelar os nossos sistemas. Ora aqui está uma forma de lhes mostrar amor.
Quem trabalha em SAP acha normal que tudo seja representado por números e códigos obscuros que não significam nada. Mas não tem de ser assim. Pára com isso! Cria códigos que os seres humanos entendam por favor.
Uma vez queria testar uma classe cujo construtor recebia vários parâmetros em que cada um pedia uma instância de um interface diferente. Essas instâncias não eram fáceis de criar e não eram relevantes para o teste. Depois de alguma experimentação descobri uma forma de contornar o problema.
Lembrete singelo. Pensei que já fosse óbvio mas continuo a ver muitos IFs que testam explicitamente o resultado de um método booleano contra ABAP_TRUE ou INITIAL. Não é preciso! O ABAP neste caso é esperto.
É bom encontrar pares igualmente interessados em melhorar e evoluir, não só como programador mas também como ser humano. Recentemente encontrei um.
Lembras-te como o CALL FUNCTION IN UPDATE TASK permitia adiar algumas acções até ao momento do COMMIT?
A função FILTER é nova e ainda pouco conhecida. Vou dar-te um exemplo de como pode ser usada.
Sabes que podes definir um ponto de partida para o ATC e que isso te permite correr o ATC em código legacy?
Quando no Japão se quebra um objecto de porcelana, às vezes, em vez de o deitarem fora, remendam-no. Mas não remendam de qualquer maneira; É com ouro. Esta técnica chama-se Kintsugi.
É hábito em ABAP usar o MODIFY em vez de INSERT e UPDATE. Costumas fazê-lo? Explica-me porquê. É preguiça? É medo? É na base do “já agora”? Ou é mais na base do “caga nisso”?
A teoria das janelas partidas diz que, se uma janela de um prédio for partida e não for reparada rapidamente, as pessoas ficam tentadas a atirar pedras e partir as outras janelas.
Por vezes dá jeito poder olhar para duas zonas do código em simultâneo. Se as zonas forem em classes diferentes é só abrir as duas. Mas, e se forem na mesma classe? Por exemplo, se quiseres fazer um método inspirado ou relacionado com outro.
No SAP é normal ter tabelas na base de dados com um campo NAME e outro NAME_SEARCH que é preenchido com exactamente a mesma coisa que o NAME mas em maiúsculas.
Depois quando queres fazer pesquisas sem ligar a maiúsculas e minúsculas usas o NAME_SEARCH. Já não é preciso fazer isso.
No mundo do ABAP é costume fazer-se uma vez e nunca mais mexer. Como ficou, ficará para sempre. Que grande disparate.
