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.
Não há coisa pior do que ver gente a abusar das variáveis. São tão delicadas e no entanto tão mal tratadas, coitadas. Ora aqui está uma forma de lhes mostrar algum amor.
Toda a gente usa linhas em branco para melhor organizar o código. Mas onde usar e quantas usar? Falemos disso.
Às vezes é preciso pegar em dados da base de dados e replicá-los declarativamente em ABAP utilizando o comando VALUE. Para, por exemplo, construir testes unitários ABAP Unit.
Historicamente foi sempre impossível saltar de um sistema SAP para o outro sem perder o contexto. Agora já dá.
As ferramentas que o SAP disponibiliza para ver o conteúdo de tabelas da base de dados sempre foram muito ranhosas.
Quando tens um método muito grande, deves subdividi-lo em vários mais pequenos.
Diz-se: Não voltes onde foste feliz. Mas a verdade é que, em muitos casos, se pudesses voltar atrás, voltavas.
Gosto de atalhos de teclado. Se eu conseguisse fazer o meu trabalho sem tirar as mãos do meu teclado seria um programador ainda mais feliz.
Quem ainda programa de forma monolítica não sente tanta necessidade disto. Mas, quem usa múltiplas classes com múltiplos métodos sabe que é normal (e até desejável) mudar de ideias em relação ao nome destas coisas. As ideias não nascem já acabadas na nossa cabeça. Idealmente, o código é moldável e dá para ir moldando até encontrarmos a forma desejada.
