Comment arrêter de faire la même chose

Vous aimez répéter des opérations routinières encore et encore ? Moi pas. Mais à chaque fois que je travaillais avec le stockage de Rostelecom dans le client SQL, je devais écrire manuellement toutes les jointures entre les tables. Et pourtant, dans 90 % des cas, les champs et les conditions de jointure des tables étaient les mêmes d'une requête à l'autre ! On pourrait penser que tout client SQL dispose de fonctions de saisie automatique, mais pour les stockages, cela ne fonctionne pas toujours : il est rare d’y trouver des contraintes d’unicité et des clés étrangères pour améliorer les performances, et sans cela, le programme ne peut pas savoir comment les entités sont liées entre elles et ce qu'il peut vous proposer.

Après avoir traversé le déni, la colère, le marchandage, la dépression et en m’approchant de l’acceptation, j'ai décidé – pourquoi ne pas essayer de mettre en place la saisie automatique avec du blackjack et tout le reste ? J'utilise le client dbeaver, qui est écrit en java, et il a une version communautaire avec un code source ouvert. J'ai conçu un plan simple :

1. Trouver dans le code source les classes responsables de la saisie automatique
2. Réorienter leur utilisation pour travailler avec des métadonnées externes et extraire les informations sur les jointures
3. ??????
4. PROFIT

J'ai rapidement compris le premier point — j'ai trouvé dans le bug tracker une demande pour corriger la saisie automatique et dans le commit associé j'ai découvert la classe SQLCompletionAnalyzer. J'ai regardé le code — c'est exactement ce qu'il me fallait. Il ne restait plus qu’à le réécrire pour que tout fonctionne. J'ai attendu une soirée libre et commencé à planifier la mise en œuvre. J'ai décidé de conserver les règles de relations des tables (métadonnées) en json. Je n'avais pas d'expérience pratique avec ce format et la tâche actuelle me semblait être une opportunité de corriger cette lacune. Pour travailler avec json, j'ai décidé d'utiliser la bibliothèque

json-simple de Google. C'est alors que les surprises ont commencé. Comme il s'est avéré, dbeaver, en tant qu'application sérieuse, est écrit sur la plateforme Eclipse en utilisant le cadre OSGi. Pour les développeurs expérimentés, cela offre une commodité de gestion des dépendances, mais pour moi, cela ressemblait davantage à de la magie noire à laquelle je n'étais clairement pas préparé : comme d'habitude, j'ai inscrit l'importation des classes dont j'avais besoin de la bibliothèque json-simple en haut de la classe modifiée, je l'ai indiquée dans le pom.xml, après quoi le projet refuse catégoriquement de se construire correctement et s'effondre avec des erreurs. de Google. C'est là que les surprises ont commencé. Comme il s'est avéré, dbeaver, en tant qu'application sérieuse, est écrit sur la plateforme Eclipse en utilisant le framework OSGi. Pour les développeurs expérimentés, cet outil offre une gestion pratique des dépendances, mais pour moi, c'était plutôt comme de la magie noire, à laquelle je n'étais clairement pas préparé : comme d'habitude, j'importe les classes dont j'ai besoin à partir de la bibliothèque json-simple en haut de la classe modifiée, je la spécifie dans le pom.xml, après quoi le projet refuse catégoriquement de se compiler correctement et échoue avec des erreurs.

Pour résoudre les erreurs de build, j'ai en fait déclaré la bibliothèque non pas dans pom.xml, mais dans le manifeste manifest.mf, comme l'exige OSGI, en l'indiquant comme import-package. Ce n'est pas la solution la plus élégante, mais cela fonctionne. Ensuite, une autre surprise est apparue. Si vous développez dans IntelliJ IDEA, vous ne pouvez pas simplement lancer le débogage de votre projet basé sur Eclipse : un développeur novice doit souffrir autant qu'un analyste sans complétion automatique des requêtes. Les développeurs de Beaver ont aidé en indiquant dans la wiki tous les rituels nécessaires. Ce qui est particulièrement frustrant, c'est qu'après toutes ces démarches, le projet ne voulait toujours pas se lancer en mode débogage avec une bibliothèque JSON connectée via import-package (bien qu'il se soit toujours bien construit dans le produit final).

À ce moment-là, j'avais déjà ressenti l'inconvénient d'utiliser JSON pour ma tâche - après tout, les métadonnées devaient être modifiées manuellement, et pour cela, le format XML est mieux adapté. Un deuxième argument en faveur de XML était la présence dans JDK de toutes les classes nécessaires, ce qui a permis d'arrêter de lutter contre une bibliothèque externe. J'ai transféré avec plaisir toutes les métadonnées de JSON à XML et j'ai commencé à revoir la logique de l'autocomplétion.

Exemple de métadonnées

dim_account
        dim_partner
        
        
    
    
        dim_account
        dim_branch

En conséquence, j'ai apporté des modifications aux classes SQLUtils et SQLCompletionAnalyzer. L'idée est la suivante : si le programme n'a pas réussi à proposer des suggestions d'autocomplétion par la logique de base, il vérifie la disponibilité de joints possibles via un fichier XML externe. Dans ce fichier sont stockées des paires de tables avec indication des champs par lesquels ces tables doivent être reliées. Les restrictions sur les dates techniques d'entrée en vigueur des enregistrements eff_dttm et exp_dttm ainsi que le drapeau de suppression logique deleted_ind sont définis par défaut.

Une fois les modifications apportées au code, une question s'est posée : qui va remplir le fichier de métadonnées ? Il y a de nombreuses entités dans le référentiel, il serait trop lourd de définir toutes les relations soi-même. Au final, j'ai décidé de confier cette tâche à mes collègues analystes. J'ai mis le fichier de métadonnées dans svn, à partir duquel se fait le checkout dans le répertoire local avec le programme. Le principe est le suivant : une nouvelle entité apparaît dans le référentiel ? Un analyste ajoute les jointures possibles dans le fichier, valide les modifications, les autres font le checkout chez eux et profitent de l'auto-remplissage fonctionnel : communauté, accumulation de connaissances, tout ça. J'ai organisé un atelier pour mes collègues sur l'utilisation du programme et j'ai rédigé un article dans Confluence — maintenant, l'entreprise dispose d'un outil pratique supplémentaire.

Travailler sur cette fonctionnalité m'a fait comprendre qu'il ne faut pas craindre d'explorer des projets open source — en général, leur architecture est claire, et même des connaissances de base dans le langage suffisent pour expérimenter. Avec une certaine dose de persévérance, il est même possible de se débarrasser des opérations répétitives détestées, gagnant ainsi du temps pour de nouvelles expériences.

Source : habr.com