Contenu

Il y a 4 ans, à partir du 4 mai 2020, écris une histoire sur la refactorisation d'un outil GUI que j'ai créé comme passe-temps lorsque j'étais étudiant à cette époque.
Cliquez ici pour le référentiel refactoré
- https://github.com/jiro4989/TKoolFacetileMaker2

Contexte

Un outil appelé TKoolFacetileMaker2 a été publié sur le forum non officiel de RPG Tsukuru en juillet 2016
https://github.com/jiro4989/TKoolFacetileMaker2
Je me souviens quand Java 8 était encore nouveau lorsque je l'ai créé.
Quatre ans plus tard, Java a maintenant 14 ans.
J'ai arrêté d'écrire Java au travail et je suis devenu plus intéressé par Nim and Go
La maintenance des résultats a été pratiquement négligée
Je sais par e-mail que certaines personnes l'utilisent encore après 4 ans.
Il n'y a aucune obligation d'effectuer la maintenance, mais en tant que technicien, je suis de plus en plus réticent à laisser les vieilles choses telles qu'elles sont.
Ce n'est plus une bonne idée que les utilisateurs installent Java 8
Il est peu probable que j'utilise cet outil, mais j'ai décidé de soulever mon poids et de le maintenir

Problèmes que j'ai eu

J'étais encore étudiant lorsque j'ai créé cet outil, j'ai donc eu beaucoup de problèmes à le faire.
Par exemple
Je construis avec un ancien outil de construction appelé fourmi
Les conventions de dénomination des packages et des classes ne sont pas définies et ne sont pas courantes dans les projets Java
Le domaine inverse de nom de package est courant en Java
C'est étrange que cela n'arrive pas
Pas dans le style MVC, la logique est dispersée partout
La logique peut ou non être bloquée dans la classe de contrôleur
Putain, c'est le moins qu'on puisse dire
La structure du projet n'est pas la structure générale d'un projet Java et ne peut pas être importée dans IntelliJ.
Il n'y a pas de src / main / java
resources existe avec le code source
Pas de code de test
** Certains codes de bibliothèques dépendantes ne sont pas laissés et ne peuvent pas être construits en premier lieu **
Cela dépend de ma propre bibliothèque oleore, mais le code source de la bibliothèque oleore ne reste pas
Je ne sais pas comment construire car il ne reste plus d'étapes de build
Je ne sais pas comment construire car la bibliothèque dépendante est manquante et je ne sais pas comment l'obtenir.
J'étais frustré d'essayer de refactoriser une fois en 2018
J'ai essayé de le porter sur kotlin tout en le déplaçant vers gradle et c'était difficile
Lors de la mise à niveau d'Oracle Java 8 vers Open JDK 11, la méthode de construction change car Java FX est séparé du JDK.
Frustré pour diverses raisons
Deux ans plus tard, à la suite de diverses études, il a été décidé de refactoriser et de poursuivre la maintenance avec Java.

Décomposition du problème

Nous avons décidé de décomposer les problèmes ci-dessus et de les écraser un par un.
Clarification du problème et de la marche à suivre dans Problèmes GitHub
Si vous essayez de tout faire en même temps, vous mourrez
Je le ferai plus tard, donc je ne le ferai pas maintenant
issues
Permettre de construire avec gradle
La construction manuelle est bien au début
Permettre de construire avec CI
Préparez-le à construire / publier
Format de code
Suivez le style de codage de Google
Mettre à niveau Java
De Java 8 à Java 14
Refactor
En supposant l'écriture du code de test
Faites-le MVC
Tester automatiquement avec CI
Maintenir le code de test
Maintenance des documents
Rédigez une documentation développeur (pour vous-même)

Ce qui était important

Quoi qu'il en soit, "maintenir un état constructible" est la priorité la plus élevée
Commencez après avoir préparé la construction automatique avec CI
Mourir si vous ne le trouvez pas cassé tôt
N'effectuez pas de version de version sur un PC local
L'environnement de développement peut changer
Si vous pouvez créer et publier dans un environnement CI, vous pouvez publier à tout moment
Tout peut être remis à une autre personne
Mis en œuvre en supposant qu'il sera automatiquement testé avec CI
Interface utilisateur et logique séparées
Autoriser uniquement la partie logique à être testée
Modélisation logique

Ce que j'ai fait / ce que j'ai pu faire

Finalement réalisé mon souhait le 11 mai 2020

Fonctionne désormais avec JRE personnalisé

Puisqu'il est distribué avec un JRE personnalisé, il n'est plus nécessaire d'installer le JRE sur le PC de l'utilisateur à l'avance.
Double-cliquez sur le script de démarrage inclus pour démarrer l'interface graphique
J'ai été impressionné lorsque je l'ai démarré dans un environnement où Java n'était pas installé ...
La taille du fichier est maintenant d'environ 50 Mo
C'est assez gros, mais c'est inévitable

Construction et publication automatiques avec CI

Les binaires seront publiés lorsque le projet de version sera publié sur GitHub Actions
https://github.com/jiro4989/TKoolFacetileMaker2/releases

Format automatique

Changement de format avant la compilation avec google-java-format-gradle-plugin

Visualisation de la couverture des tests

Activé pour obtenir une couverture de test avec le plug-in Gradle appelé Jacoco
Couverture de test visualisée avec CodeCov
Augmentation du taux de couverture des tests des pièces logiques telles que le modèle à 90% ou plus.
- https://codecov.io/gh/jiro4989/TKoolFacetileMaker2
J'ai abandonné car il semblait difficile de tester la partie UI

Régime de code

Le nombre de lignes de code a été considérablement réduit car les fonctions jugées inutiles ont été complètement supprimées.
Profitez pleinement de la fonction de liaison de propriété originale de JavaFX
Vous n'avez plus besoin de définir la valeur

Avant de refactoriser

Il n'y avait pas de code de test

$ find src/ -name '*.java' | xargs wc -l
       31 src/application/fileList/FileListHBox.java
      189 src/application/fileList/FileListHBoxController.java
       31 src/application/imageViewer/ImageViewerBorderPane.java
      288 src/application/imageViewer/ImageViewerBorderPaneController.java
       92 src/application/Main.java
      471 src/application/MainController.java
       44 src/application/options/Numberings.java
      104 src/application/options/Options.java
       40 src/application/options/OptionsStage.java
      165 src/application/options/OptionsStageController.java
       69 src/application/options/Separators.java
       36 src/application/outputViewer/MyButton.java
      122 src/application/outputViewer/MyImageView.java
       33 src/application/outputViewer/OutputViewerAnchorPane.java
      130 src/application/outputViewer/OutputViewerAnchorPaneController.java
       25 src/application/TKoolVersion.java
       29 src/application/version/VersionStage.java
       42 src/application/version/VersionStageController.java
     1941 total

Après achèvement

Le nombre de cas de test est désormais de 90

# main
$ find src/main/java/ -name '*.java' | xargs wc -l
         8 src/main/java/com/jiro4989/tkfm/data/CropSize.java
        42 src/main/java/com/jiro4989/tkfm/data/Position.java
        38 src/main/java/com/jiro4989/tkfm/data/Rectangle.java
        67 src/main/java/com/jiro4989/tkfm/Main.java
       422 src/main/java/com/jiro4989/tkfm/MainController.java
       235 src/main/java/com/jiro4989/tkfm/model/CroppingImageModel.java
        21 src/main/java/com/jiro4989/tkfm/model/ImageFileModel.java
        52 src/main/java/com/jiro4989/tkfm/model/ImageFilesModel.java
       211 src/main/java/com/jiro4989/tkfm/model/PropertiesModel.java
       133 src/main/java/com/jiro4989/tkfm/model/TileImageModel.java
        15 src/main/java/com/jiro4989/tkfm/util/ImageUtil.java
         6 src/main/java/com/jiro4989/tkfm/Version.java
      1250 total

# test
$ find src/test -name '*.java' | xargs wc -l
        13 src/test/java/com/jiro4989/tkfm/data/CropSizeTest.java
        29 src/test/java/com/jiro4989/tkfm/data/PositionTest.java
        26 src/test/java/com/jiro4989/tkfm/data/RectangleTest.java
       212 src/test/java/com/jiro4989/tkfm/model/CroppingImageModelTest.java
        28 src/test/java/com/jiro4989/tkfm/model/ImageFileModelTest.java
        64 src/test/java/com/jiro4989/tkfm/model/ImageFilesModelTest.java
       143 src/test/java/com/jiro4989/tkfm/model/PropertiesModelTest.java
       120 src/test/java/com/jiro4989/tkfm/model/TileImageModelTest.java
        43 src/test/java/com/jiro4989/tkfm/util/ImageUtilTest.java
        13 src/test/java/com/jiro4989/tkfm/VersionTest.java
       691 total

Maintenance du code de test

Comme mentionné ci-dessus, la couverture de test de la partie logique a été augmentée à 90% ou plus.
Introduction du plugin TestFX pour tester JavaFX
Dans l'environnement CI, il n'y a pas d'affichage, donc le test est de la mousse
Evitez avec la commande xvfb-run
Utilisation de JUnit 5
Go écrit un test basé sur une table, j'ai donc écrit un test similaire
Test paramétré pratique pour Junit 5

Temps pris

Cela a pris 66 heures, temps de conception compris
Je ne m'attendais pas à ce qu'un programme de 2000 lignes prenne au maximum 66 heures ...
Tout GW a disparu + je l'ai fait même après la fin de GW

Avoir du mal

Je ne suis pas stupide de souffrir des outils que j'ai fabriqués (ridicule)

gradle

Je n'avais jamais écrit de note en premier lieu
J'avais besoin de comprendre comment écrire et le concept
J'ai écrit maven, donc maven allait bien, mais j'aime le langage de script, alors j'ai choisi gradle.

Problème de séparation JavaFX (jmods)

JavaFX était inclus dans le JDK lors de l'utilisation d'Oracle Java 8.
Vous devez utiliser OpenJDK pour développer gratuitement en Java avec Java 9 ou version ultérieure
OpenJDK n'inclut pas non plus JavaFX dans le JDK
Nécessité d'utiliser un mécanisme de module avec JavaFX SDK et JavaFX JMODS
Difficile de comprendre les fonctions du module qui n'existaient pas au moment de l'écriture dans Java 8

JRE personnalisé

Le style d'installation et d'exécution de JRE sur un PC est ancien
Le style qui inclut JRE pour chaque application deviendra plus courant à l'avenir
Créez un JRE personnalisé qui ne contient que le runtime minimum requis pour fonctionner et distribuez-le avec votre application
Utilisez un outil appelé jlink
Doit être appris en conjonction avec les modules ci-dessus

Je n'ai pas le code source de ma bibliothèque

J'ai sorti le fichier de classe du JAR exécutable que j'avais distribué et je l'ai décompilé avec jad et je l'ai restauré à partir du code généré.
Le jour viendra où vous décompilerez votre distribution ...

Impressions

Je suis content de l'avoir fait

Fonctionnellement diminué plutôt que augmenté
Mais la maintenabilité s'est améliorée
Le test automatique est maintenant possible
Désormais disponible pour publication à tout moment
Libéré de la malédiction d'avoir à continuer à utiliser Java 8
Je suis content d'avoir créé Java14

Reflection il y a 4 ans

N'implémentez pas de fonctions inutilisées
Pas de bon, seulement des coûts de maintenance accrus
Évitez le couplage étroit de l'interface utilisateur et de la logique
Ce n'est pas bon que vous ne puissiez pas tester sans manipuler manuellement l'écran
Inhibe l'automatisation des tests
Ecrire le code de test
Le comportement correct reste dans le code
Remarquez un comportement qui n'a pas été pris en compte
Implémentation du principe d'écriture d'un test
Améliore la qualité
Obtenez une couverture de test
J'ai pu trouver une branche non testée en visualisant avec CodeCov
Créer un environnement de test automatisé
Cette fois, j'ai construit un environnement de construction / test automatique avec [Actions GitHub], mais la réponse était correcte.
Remarquez immédiatement que le comportement a changé
Plus tôt vous construirez un environnement de test automatisé, plus il sera efficace
Créer un environnement de publication automatique
Oubliez comment construire / publier
L'environnement qui peut être libéré change
Modifications du PC hôte au niveau du système d'exploitation
Si vous construisez uniquement sur le PC hôte, vous pouvez avoir une "dépendance inconsciente"
Cette fois, la "bibliothèque Oreore sans code source" est exactement cela.
J'ai pu construire à ce moment-là, mais maintenant je ne peux pas
Les dépendances sont toujours codées quelque part si elles peuvent être libérées dans un environnement CI
Doit être construit sur l'environnement CI afin que n'importe qui puisse construire / publier à tout moment
Ma mise en œuvre il y a quatre ans était putain
Des ordures
idiot
Ouais

à partir de maintenant

Il existe des outils créés avec JavaFX autres que cet outil, donc j'aimerais faire le même refactoring.
(Comme il y a peu d'utilisateurs, c'est juste l'auto-satisfaction)

Résumé

Concevons correctement depuis le début
Écrivons correctement le test
Automatisons
Suivez la norme de facto

Si j'avais fait ça depuis le début, je n'aurais pas eu une sensation aussi douloureuse ...

c'est tout

Outil GUI refactorisé réalisé avec Java8 + JavaFX en 2016