[JAVA] Derrière le système de 10 ans

Cet article est l'article du 6ème jour du Calendrier de l'Avent Recruit Lifestyle 2018.

@tunanosuke. J'ai rejoint Recruit cette année et je développe maintenant Hot Pepper Beauty. Hot Pepper Beauty est un produit en service depuis plus de 10 ans. Bien qu'elle ait été un énorme succès en tant qu'entreprise, elle est techniquement pleine de dettes. Il y a un contexte dans lequel nous avons donné la priorité à la croissance des produits alors qu'il y a peu d'ingénieurs dans l'entreprise jusqu'à présent, mais nous sommes en train de nous améliorer progressivement. Je voudrais vous présenter l’arrière-plan de l’état actuel d’un tel système de 10 ans et de son maintien.

Statut actuel

Les noms de table et de colonne sont en caractères romains

Romaji qui apparaît assez souvent. Et parfois, il est omis. Par exemple, pour le mot «réservé»

• YOYAKU
• YYK

Il existe une méthode d'expression telle que, et même l'application est renvoyée telle quelle. Est-ce acceptable parce que je peux encore comprendre Romaji? Même s'il peut être omis, c'est assez strict. Cependant, changer ici est coûteux et risqué, il est donc important de séparer ce qui peut être changé de ce qui ne peut pas l'être et de bloquer ce qui ne peut pas être changé aussi près que possible. Je fais ça maintenant.

Le nombre de colonnes dans un tableau est incroyable

Long de côté, long quand même ... Cependant, quand je pense à RDB, je pense que je pense souvent à la façon de le tenir de côté, donc je comprends mes sentiments. Vous pouvez voir les résultats de l'ajout et du développement des fonctions. Comme il existe de nombreux indicateurs et qu'une table gère de nombreux états, le code de l'application en est également compliqué. D'un autre côté, il y a aussi un dicton, "Quoi? Je normalise ici", donc je le fais en devinant diverses intentions.

Il y a beaucoup de choses qui peuvent être sauvées par cette spéculation, et même s'il y a quelque chose à dire d'un point de vue détaillé, je peux lire l'intention, par exemple pourquoi cela s'est produit ou pourquoi cela s'est produit. Bien sûr, si vous avez les concepteurs et les documents à ce moment-là, ce serait mieux, mais je ne peux pas le faire parce que je n'ai pas eu d'ingénieurs parmi mes employés jusqu'à présent. Donc, je sens que c'est toujours un soulagement d'être dans un état où j'ai envie de faire ça.

Sous-requête rejoindre rejoindre sous-requête rejoindre un syndicat

C'est long verticalement, c'est long quand même, c'est facile si tu peux l'obtenir une fois, je vais le faire Les fonctions de Hot Pepper Beauty ont été élargies avec la participation de diverses personnes. En conséquence, la conception est ad hoc et incohérente. Par conséquent, ce n'est pas une structure de données qui est mappée à l'aide d'un mappeur O / R et qui est ok, mais il est assez difficile de la prendre avec un SQL. Le résultat est une dette comme une requête lente. Il convient que le produit actuel donne à l'application une couche qui divise doucement le SQL et le mappe à la structure qui lui convient du côté de l'application, et nous préparons également chacun ici.

Grand lot

J'ai une équipe batch. En d'autres termes, il y en a beaucoup. J'adore les lots!

Il est inévitable que ce soit déjà fait, mais le plus difficile est de déterminer quel lot affecte quelles données. Bien que ce soit toujours une bonne référence, il est difficile de voir quelles données sont mises à jour pour quel déclencheur. N'est-il pas possible que le lot dans lequel le processus de mise à jour s'exécute verrouille la table Master DB pendant un certain temps?

Conception d'API

Tout d'abord, Hot Pepper Beauty se compose de deux services principaux.

--Salon de coiffure

• Vous pouvez rechercher et faire des réservations pour les salons de beauté --Beau salon ―― Vous pouvez rechercher et faire des réservations pour des salons tels que des salons de beauté, de relaxation et de sourcils.

Ces cheveux et cette beauté ont des propriétés différentes et des domaines complètement différents. Nous le développons comme un service unique. Comme traîné par lui, les points de terminaison d'API ne font souvent pas la distinction entre les cheveux et la beauté. Étant donné que les propriétés sont différentes, les données requises et les données de réponse sont également différentes pour les cheveux et la beauté, de sorte qu'il existe de nombreuses branches de beauté capillaire dans l'application. Il y a beaucoup d'attributs identiques dans le sens d'un salon de beauté, mais exprimer différents domaines avec un seul est difficile quand on regarde vers l'avenir, n'est-ce pas? Nous sommes actuellement en train de concevoir une séparation claire ici.

Méthode POST lors de la récupération des ressources

:thinking:

Afin d'éliminer les dettes passées telles que le remplacement, il est très important de comprendre l'historique du produit et comment cela s'est passé, et si vous ne le faites pas, vous ne pourrez pas vous améliorer, mais parfois il est également nécessaire de décider de ne pas poursuivre en profondeur. Ou. Tel est le cas.

Un peu de perspectives d'avenir

Nous remplaçons l'architecture monosilique traditionnelle par une configuration BFF --Backend. Backend utilise toujours Java et BFF utilise Kotlin. Il est important de conserver autant que possible la dette qui ne peut pas être convertie en Backend afin qu'elle paraisse simple pour chaque produit. Je publierai plus de détails à ce sujet sur notre blog d'ingénieur à l'avenir.

Résumé

En voici quelques-uns. Il y a beaucoup de choses comme ça. D'un autre côté, il est merveilleux qu'il ait réalisé une croissance formidable en tant que produit, et je lui en suis reconnaissant et je le changerai en une architecture tournée vers l'avenir.