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.
Pediram-te para criar uma nova funcionalidade. Estás pronto para a construir. Mas aguenta os cavalos. Antes de começares sugiro que encontres resposta a algumas perguntas. Encontrares uma boa resposta para cada uma delas é fundamental para garantir que o que vais construir fica sólido e elegante.
O meu projecto tem constantes espalhadas por todo o lado, com nomes confusos ou errados. Uma salgalhada. Encontrei uma forma de reorganizar e rearrumar as constantes para que o código novo possa usar constantes bonitas sem espatifar o código antigo que pode continuar a usar as confusas.
