Como parar de fazer sempre a mesma coisa

Você gosta de repetir operações rotineiras vez após vez? Eu não. Mas sempre que trabalhava com o repositório da Rostelecom no cliente SQL, precisava escrever manualmente todos os joins entre as tabelas. E isso considerando que, em 90% dos casos, os campos e as condições de junção das tabelas eram os mesmos de uma consulta para outra! Parece que qualquer cliente SQL tem funções de autocompletar, mas para repositórios isso nem sempre funciona: eles raramente têm constraints únicas e chaves estrangeiras para aumentar o desempenho, e sem isso o programa não consegue saber como as entidades estão relacionadas e o que pode lhe oferecer.

Depois de passar por negação, raiva, negociação, depressão e me aproximar da aceitação, decidi - por que não tentar implementar o autocompletar eu mesmo, com blackjack e tudo mais? Estou usando o cliente dbeaver, escrito em Java, que tem uma versão comunitária de código aberto. Elaborei um plano simples:

1. Encontrar nas classes de código-fonte que lidam com o autocompletar
2. Reorientá-las para trabalhar com metadados externos e extrair informações sobre os joins de lá
3. ??????
4. PROFIT

Resolvi rapidamente o primeiro ponto — encontrei na base de bugs um pedido para corrigir o autocompletar e, no commit relacionado encontrou a classe SQLCompletionAnalyzer. Olhei o código — era exatamente o que precisava. Apenas restava reescrevê-lo para que tudo funcionasse. Esperei por uma noite livre e comecei a planejar a implementação. Decidi guardar as regras de relações entre tabelas (metadados) em JSON. Eu não tinha experiência prática com esse formato e a tarefa atual parecia uma oportunidade de corrigir essa lacuna. Para trabalhar com JSON, decidi usar a biblioteca

json-simple do Google. Aqui começaram as surpresas. Como descobri, o dbeaver, como um verdadeiro aplicativo, foi escrito na plataforma Eclipse usando o framework OSGi. Para desenvolvedores experientes, isso oferece comodidade na gestão de dependências; para mim, parecia mais uma magia negra para a qual eu claramente não estava preparado: como de costume, escrevi a importação das classes necessárias da biblioteca json-simple no cabeçalho da classe editada, indiquei-a no pom.xml e, em seguida, o projeto se recusou categoricamente a compilar corretamente e apresentou erros. do Google. Aqui começaram as surpresas. Como foi descoberto, o dbeaver, como um verdadeiro aplicativo, foi escrito na plataforma Eclipse usando o framework OSGi. Para desenvolvedores experientes, essa coisa oferece facilidade no gerenciamento de dependências, mas para mim parecia mais como mágica negra, para a qual eu definitivamente não estava preparado: como de costume, eu escrevo a importação das classes que preciso da biblioteca json-simple no cabeçalho da classe que estou editando, indico-a no pom.xml, após o que o projeto se recusa categoricamente a compilar corretamente e quebra com erros.

Corrigi os erros de construção, acabando por registrar a biblioteca não no pom.xml, mas no manifesto manifest.mf, como exige o OSGI, especificando-a como import-package. Não é a solução mais bonita, mas funciona. Aqui surgiu a próxima surpresa. Se você está desenvolvendo no IntelliJ IDEA, não pode simplesmente iniciar o depurador do seu projeto, que se baseia na plataforma Eclipse: um desenvolvedor inexperiente deve sofrer tanto quanto um analista sem autocompletar consultas. Os próprios desenvolvedores do Beaver vieram em auxílio, detalhando na wiki todas as etapas necessárias. O mais frustrante é que, mesmo após todos esses procedimentos, o projeto não queria iniciar no depurador com a biblioteca JSON conectada via import-package (mesmo que no produto final ele ainda fosse compilado com sucesso).

Até aquele momento, eu já havia sentido a inconveniência de usar JSON para a minha tarefa — afinal, as metadados foram projetados para serem editados manualmente, e para isso o formato XML é mais adequado. Um segundo argumento a favor do XML foi a disponibilidade de todas as classes necessárias no JDK, o que me permitiu parar de lutar contra uma biblioteca externa. Com grande prazer, transferi todos os metadados de JSON para XML e comecei a ajustar a lógica de autocompletar.

Exemplo de metadados

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

Como resultado, eu fiz alterações nas classes SQLUtils e SQLCompletionAnalyzer. A ideia é a seguinte: se o programa não conseguiu encontrar sugestões adequadas de autocompletar pela lógica básica, ele verifica a existência de possíveis joins com base em um arquivo XML externo. No próprio arquivo estão armazenados pares de tabelas com a indicação dos campos pelos quais essas tabelas devem ser vinculadas. Restrições sobre as datas técnicas de validade dos registros eff_dttm e exp_dttm, bem como a flag de exclusão lógica deleted_ind, são configuradas por padrão.

Quando as alterações no código foram feitas, surgiu a questão — quem irá preencher o arquivo de metadados? Há muitas entidades no repositório, e escrever todas as relações manualmente é complicado. No final, decidi passar essa tarefa para meus colegas analistas. O arquivo de metadados foi colocado no svn, de onde é feito o checkout para o diretório local com o programa. O princípio é o seguinte: surgiu uma nova entidade no repositório? Um analista insere possíveis joins no arquivo, faz o commit das alterações, os outros fazem checkout para si e desfrutam do preenchimento automático funcionando: comunidade, acúmulo de conhecimento e tudo mais. Realizei um workshop para os colegas sobre o uso do programa, escrevi um artigo no Confluence — agora a empresa tem uma ferramenta mais conveniente.

O trabalho nesta funcionalidade me deu a compreensão de que não devemos ter medo de mexer em projetos open source — em geral, eles têm uma arquitetura clara, e até mesmo um conhecimento básico da linguagem é suficiente para experiências. E com uma certa dose de persistência, é possível até se livrar de operações rotineiras indesejadas, economizando tempo para novas experiências.

Fonte: habr.com