Le codage du système dont j'étais en charge était fou. Cependant, les projets de rénovation à grande échelle n'ont pas abouti. Ensuite, le flux est de fixer les petits projets petit à petit.
Par exemple, la classe métier de recherche a la structure suivante.
En regardant cela seul, il s'agit (probablement) d'une configuration normale, mais le codage réel ressemble à ce qui suit.
//Validation
//contrôle nul
if(joken1 == null ||
joken2 == null ||
joken3 == null ||
... ) {
error.add("Erreur");
return false;
}
//Vérification des caractères vides
if(joken1 != null &&
joken2 != null &&
joken3 != null &&
... ) {
if(joken1 == "" ||
joken2 == "" ||
... ) {
error.add("Erreur");
return false;
}
}
//Création d'objets
ObInfo obInfo = new ObInfo();
ObResult obResult = new ObResult();
int kensakuResult = 0;
//Jugement des conditions de recherche
if (joken == CONST.JOKEN1 ||
joken == CONST.JOKEN2 ||
joken == CONST.JOKEN3 ||
... ){
//Exécution de la recherche
kensakuResult = obInfo.getKensakuResult(joken1, joken2, ... , obResult);
if(kensakuResult == 0) {
error.add("Erreur");
return false;
}
}
//Modification des éléments d'affichage de l'écran
ObKensakuInfoBean obKensakuInfoBean = new ObKensakuInfoBean();
editKensakuInfo(obKensakuInfoBean, kensakuResult);
//avertissement
if (kensakuResult == 2){
error.add("avertissement");
} else if (kensakuResult == 3){
error.add("avertissement");
} else if (kensakuResult == 4){
...
}
return true;
Ce qui précède est un aperçu de la logique métier qui est d'abord appelée lors de l'exécution d'une recherche. Il y a en fait plus de validations, de modifications d'éléments et de commentaires de modification. Ce commentaire éditorial est gênant et rend le code déjà difficile à voir plus difficile à voir.
/*20XX ○○ Projet START*/
// ObInfo obInfo = new ObInfo();
/*20XX ○○ Fin du projet*/
/*Début du projet 20XX XX*/
// ObInfo obInfo
/*Fin du projet 20XX XX*/
obInfo
/*20XX △△ Projet START*/
// = obGetInfo.getInfo(obInfo, obAuthInfo, obCode);
/*20XX △△ Fin du projet*/
/*20XX □□ Projet START*/
= obGetInfo.getInfo(obINfo);
/*20XX □□ Fin du projet*/
C'est comme ça. Vous pouvez le dire d'un seul endroit ici, mais comme c'est dans tout le code, il est difficile de comprendre tout le code. Actuellement, SVN est utilisé pour le contrôle de code source, donc les commentaires ne sont pas obligatoires, mais il est habituel de laisser des commentaires.
Ce code fonctionne également. Peut-être que les conditions simples étaient suffisantes au début. Cependant, des conditions progressivement compliquées étaient nécessaires. Et ce code ne prend pas (pour une raison quelconque) en compte l'ajout de conditions. Les entrées, les conditions if et la validation sont toutes décrites dans la logique métier. Par conséquent, il était nécessaire de modifier les conditions et la validation dans la logique métier à chaque fois qu'une réparation était effectuée. Naturellement, c'est le plein écran de la pièce réparée. De plus, les spécifications étaient différentes, telles que les conditions étant décrites dans une autre classe en fonction de la logique métier, étant écrites directement dans la logique métier, et étant décrites dans la méthode. En d'autres termes, les classes qui peuvent être modifiées pour chaque emplacement de réparation sont différentes.
Normalement, je pense qu'il est préférable de créer une classe de validation et d'y implémenter la validation. Cependant, il est difficile d'apporter une correction fondamentale car le nombre d'étapes est déterminé par le nombre d'étapes de correction et la création d'un projet à petite échelle. Donc, cette fois, j'ai principalement modifié les conditions de recherche.
En ce qui concerne les conditions de recherche, puisque nous avons défini des constantes prédéterminées comme conditions, nous les avons ajoutées en tant que nouvelle condition pour voir si elles correspondent aux conditions du tableau.
if(CONST.JOKENS.contain(joken)){
kensakuResult = ...
}
C'est comme ça. À l'origine, je voulais tout mettre ensemble, mais cela nécessiterait une énorme quantité de tests de régression. (Il est nécessaire de tester qu'il fonctionne normalement dans les conditions jusqu'à présent) S'il s'agit d'un problème simple, le test d'intégration est difficile, mais s'il ne s'agit que d'un test unitaire, cela peut être fait avec JUnit, etc. (S'il existe un cas de test JUnit qui correspond aux conditions existantes)
Malheureusement, je n'avais même pas d'environnement local sans JUnit, j'ai donc abandonné le test de régression. Donc, cette fois, seules les conditions nouvellement ajoutées sont répertoriées et prises en charge.
if(joken == CONST.JOKEN ||
...
CONST.JOKENS.contain(joken)){
...
}
C'est comme ça.
En premier lieu, je pense que la cause est que j'ai négligé la conception détaillée au moment du démarrage. Seule la conception de base était clairement documentée et chaque personne l'a mise en œuvre pour que l'affichage à l'écran réponde aux spécifications. En conséquence, le comportement de la classe n'était pas spécifié et les spécifications de chaque classe devenaient différentes. Je pense qu'il est possible de créer une conception détaillée basée sur la mise en œuvre pour le moment de la rénovation, mais ce travail n'est pas réduit. C'est pourquoi je n'ai pas eu d'autre choix que de faire face à ces petites corrections.
Définissons correctement les normes de conception et de codage. Il n'y a pas besoin de travaux de réparation pour ajouter des classes à la phase d'exploitation / maintenance.
Recommended Posts