Le contenu est comme le titre l'indique, mais je n'ai pas l'intention de supprimer la personne qui a écrit le code anti-pattern. Il y a aussi le mot que vous détestez le code et non pas les gens. [^ code] [^ code]: Je l'ai vraiment trouvé quand je l'ai googlé.
Au lieu d'un tel motif négatif, j'écris avec un motif positif pour tirer autant de leçons que possible des anti-modèles et aller de l'avant.
Il y a beaucoup de vieilles histoires dans l'ensemble, donc j'espère qu'il y a moins de codes et de situations de ce genre de nos jours.
Comme beaucoup d'entre vous le savent peut-être, Struts1 était hors de support il y a de nombreuses années, donc à ce stade, je n'ai qu'un mauvais pressentiment.
Il est toujours bon d'utiliser Struts tel quel, mais comme le dit le titre, j'ai utilisé le framework Oleore qui étend Struts. Dans ce cadre, il est nécessaire de créer un grand nombre de classes pour écrire le traitement d'une requête, Struts Action et FormBean, BLogic qui décrit la logique métier, BLogicInputBean pour l'entrée dans BLogic, BLogicOutputBean pour la sortie , JSP et, dans certains cas, DAO et DAO Bean pour passer à DAO étaient également nécessaires. En outre, struts-config, validation de Struts, définition de Spring, modification de sqlMap et fichier XML d'iBATIS sont également inclus.
En particulier, c'était un mystère que je devais créer de nombreux types de beans similaires, mais je n'avais pas d'autre choix que de créer ces beans comme une convention du framework, et le contenu est presque le même, mais les types sont différents, donc les beans Il m'a fallu beaucoup de temps pour écrire les recharges manuellement. [^ bean] [^ bean]: Plus tard, j'ai appris qu'il existe une bibliothèque qui copie le contenu de beans similaires mais de types différents, ce qui a rendu cela un peu plus facile. De plus, comme ceux-ci sont créés "pour chaque demande", il était nécessaire de créer ce qui précède pour chacune des demandes d'affichage, nouvelle demande d'enregistrement / mise à jour, demande de mise à jour de certains éléments à l'écran, etc. .. Quoi qu'il en soit, le montant de la correction était important, donc la productivité était très faible.
À cette époque, il n'y avait pas beaucoup de frameworks puissants pour remplacer Struts, donc je pense qu'il n'y avait pas d'autre choix que d'adopter Struts dans une certaine mesure. Cependant, c'est un mystère que je l'ai modifié pour forcer la création d'un grand nombre de classes inutiles dans Struts simples. Je pense que j'aurais dû utiliser les Struts simples tels quels. Un rapide coup d'œil révèle qu'un tel cadre ne vise pas à augmenter la productivité, mais à faire avancer les choses même avec de faibles compétences en développement. [^ envahir] [^ invade]: Référence: Invasive Framework
Peut-être ont-ils adopté un tel cadre et attribué aux nouveaux arrivants des prix unitaires bas pour réduire les coûts. (En fait, il y avait beaucoup de nouveaux arrivants) Si le choix de ce cadre est pour cette raison politique, il ne peut plus être aidé. Je ne peux trouver qu'une solution pour m'échapper. Si vous avez un haut niveau de compétences techniques, vous pourrez peut-être faire de votre mieux techniquement comme le lien de référence, mais je ne pouvais pas y penser à ce moment-là. Je ne suis peut-être pas un programmeur décent.
Pour le moment, il n'y a aucune raison de choisir Struts pour un nouveau développement. Je me demande si Spring Boot est bon après tout.
La programmation de copie est ce que vous obtenez lorsque vous créez une fonction qui est similaire à une fonction existante. C'est que vous copiez et collez le code existant et ne corrigez que la différence. Je ne peux pas dire que c'est génial parce que je le fais parfois, et je ne veux pas dire que la programmation de copie est toujours mauvaise, mais je dois souligner que la programmation de copie a toujours ses inconvénients.
La programmation de copie vous donne un certain plaisir car vous pouvez rapidement implémenter des fonctionnalités même avec du code que vous ne comprenez pas bien, et à première vue, cela semble plus productif, mais pendant la maintenance. Voir l'enfer. Tout d'abord, s'il y a une modification, vous devez effectuer la même modification pour toutes les pièces copiées. De plus, il existe un risque de provoquer des bogues étranges en raison de l'omission de correction lors de la copie. Le code qui est assemblé à la fois sans bien comprendre le contenu par copie est très difficile à lire, il a donc tendance à être négligé à vérifier, et des omissions de correction se produisent souvent. Les correctifs de code manquants sont un problème, mais les commentaires manquants sont également un problème. Dans un sens, cela peut être pire qu'une omission de code, car une omission de commentaire n'affecte pas le comportement.
La programmation de copie est endémique dans les projets que j'ai vus, et je soupçonne que la plupart du codage a été fait par programmation de copie. Il y avait tellement d'omissions dans le projet que les commentaires n'étaient plus crédibles. C'est la même chose que pas de commentaire. Vous connaissez tous la douleur de maintenir un code sans aucun commentaire.
S'il s'agissait du même processus, il aurait dû être extrait et partagé dans une méthode, etc. au lieu d'être copié. Dans ce cas, même si une correction se produit, vous ne devez la corriger qu'à un seul endroit, et comme elle n'est pas copiée en premier lieu, aucune omission de correction ne se produira. Cependant, à l'inverse, si vous modifiez une partie, cela affectera plusieurs parties, vous devez donc considérer attentivement "Est-il vraiment acceptable de partager?" [^ partager] [^ share]: Référence: [Partagez soigneusement](https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82% A4 /% E5% 85% B1% E6% 9C% 89% E3% 81% AF% E6% 85% 8E% E9% 87% 8D% E3% 81% AB /)
C'est la racine de tout mal. C'est un gars notoire dont vous avez probablement entendu parler. C'est bien de commenter temporairement, mais ce que je dis ici, c'est de laisser toutes les corrections définitivement commentées. De plus, le projet devait insérer un commentaire indiquant le début de la modification et un commentaire indiquant la fin de la modification en règle générale au moment de la modification. C'est très ennuyeux car à chaque fois que vous faites une correction, la quantité de déchets augmente. C'est très difficile à lire et cela peut être un bruit pour votre recherche. Le code ne fait que devenir sale car tous les correctifs restent. Là où il y a beaucoup de corrections, c'est trop chaotique pour être lu. Inutile de dire que la lecture de code est une tâche très fréquente, et c'est aussi l'une des causes de la perte de productivité. C'est ce que signifie avoir beaucoup de mal et pas de profit.
Cela peut être SVN ou Git, mais vous devez utiliser un système de gestion de version. [^ version] [^ version]: Eh bien, sauf si vous avez des circonstances spéciales, vous devriez choisir Git. Avec un système de gestion de version, vous n'avez pas du tout à faire cela. À l'heure actuelle, aucun projet n'est développé sans l'utilisation d'un système de gestion de version. …Mais ce n'est pas………? Cependant, dans ce projet, bien que la version soit gérée par SVN, c'était la règle ci-dessus, donc ce n'était pas du tout clair ...
Il y avait souvent des situations où une grande quantité de logique métier était écrite dans JSP. C'était très difficile à lire car c'était un mélange de HTML et de Java. De plus, étant donné que la quantité de code décrite dans un fichier JSP était trop grande et qu'une erreur s'est produite [^ jsp_error], le JSP a été divisé sur un écran, qui était également difficile à lire. Il est normal de le diviser en unités appropriées, mais dans ce cas, c'était une méthode pour couper un énorme JSP en deux ou trois et attribuer des numéros de série aux noms de fichiers, alors qu'est-ce que la division en unités appropriées? C'était difficile à dire. [^ jsp_error]: Référence: Je veux que vous résolviez le problème qui ne peut pas être exécuté immédiatement si le résultat de la compilation dépasse 65535 octets dans une méthode qui est une limitation de java.
De plus, afin d'implémenter que l'affichage de l'écran change en fonction de la condition, j'ai honnêtement tout écrit en utilisant le branchement conditionnel. Cela a également fait gonfler la quantité de code et devenir difficile à lire.
Écrivez votre logique métier dans le modèle. Les bases de MVC. De plus, si l'affichage de l'écran change en fonction des conditions, vous devez prendre des mesures pour empêcher qu'un fichier ne devienne volumineux, comme la création d'un sous JSP et son chargement.
En passant, je ne pense pas qu'il y ait beaucoup de nouveaux développements qui utilisent JSP maintenant. Après tout, le courant dominant est maintenant Thymeleaf.
Puisqu'il n'y a aucun stigmate dans le code qui n'est pas touché, même s'il y a un problème dans le code, on a supposé qu'il ne devrait pas être touché à moins qu'il y ait un problème de fonctionnement. En conséquence, des problèmes mineurs n'ont pas été résolus et le nombre a augmenté régulièrement. Même s'il y avait un avertissement, il ne pouvait pas être corrigé, donc l'avertissement s'est accumulé dans la piscine. Ce n'est pas très bon, car un grand nombre d'avertissements enterreront les avertissements vraiment problématiques.
De plus, un grand nombre de commentaires TODO ont été laissés sans surveillance. S'il reste longtemps comme TODO, il sera difficile de savoir comment le gérer. C'est aussi un obstacle car le TODO que j'ai ajouté personnellement sera enterré.
J'aurais dû prendre un peu de temps pour refactoriser. Cela semble correct à première vue de ne pas le faire parce que vous n'avez pas le temps, mais ce n'est pas le cas. Il y a beaucoup à faire, il est donc peu probable que vous ayez le temps naturellement. Vous ne pouvez pas avoir le temps sans l'idée de coordonner d'autres tâches pour gagner du temps. Ce n'est pas la motivation, pas le temps. [^ fois] [^ time]: C'était vrai que nous n'avions pas le temps parce que tout le monde travaillait jusqu'à environ 22h00 tous les jours quelle que soit la période de l'année et il y avait des vacances occasionnelles. Cependant, c'était une méthode de développement inefficace dans son ensemble, certaines personnes se reposaient fréquemment en raison d'une mauvaise condition physique, certaines personnes ne revenaient pas pendant environ 30 minutes après avoir quitté leur siège, etc. Je pense qu'il était possible de trouver du temps si je le voulais.
Il y a aussi une histoire que je déteste parce que je dois la tester quand je touche le code. Je le sais, mais il y a des moments où vous devez tester et refactoriser. De plus, quand je corrige le code en corrigeant un bogue ou en ajoutant une fonction, je dois quand même le tester, donc je pense que je pourrais et aurais dû concevoir une refactorisation. Il semble qu'une petite modification puisse être garantie en exécutant UT, mais dans ce projet, je n'ai pas du tout écrit UT en premier lieu. Tout d'abord ...
Cependant, tant qu'il y a une règle [Commentez les corrections et laissez tout](#Commentez les corrections et laissez tout), il n'y a pas de refactoring ou de merde. Au minimum, cette règle doit être détruite à tout prix.
En général, il est bon de traiter des valeurs fixes qui apparaissent plusieurs fois comme des constantes, mais parfois des constantes inintelligibles sont créées sans en comprendre l'intention.
public static final int INT_0 = 0;
public static final int INT_1 = 1;
//La même chose continue ci-dessous
Ce n'est pas différent de l'utilisation de littéraux. C'est un mystère, mais la personne qui a écrit cela peut avoir été imprimée par une mauvaise éducation qu'il est mauvais d'utiliser directement des littéraux. J'avais l'intention de penser moi-même au terme maladie constante, mais il semble que certaines personnes y aient déjà pensé. C'est exactement comme ça. [Source] "DIV disease" est synonyme d'être dangereux si vous en faites trop
Je ne pense pas qu'il soit nécessaire d'expliquer grand chose, mais je pense que les constantes sont à l'origine utilisées pour des valeurs qui peuvent changer dans le futur. En définissant une constante et en référençant la constante où la valeur est nécessaire, même si quelque chose change, seule la partie d'initialisation de la constante doit être modifiée. De plus, en raison de la nature qu'elle peut changer à l'avenir, elle doit être nommée en fonction du type de valeur que signifie le nom de la constante et du type de valeur spécifiquement inclus. Nommer est un non-sens. Voici un exemple simple.
//Mauvais exemple
public static final String LF = "\n";
//Bon exemple
public static final String LINE_SEPARATOR = "\n";
Si c'est un mauvais exemple, vous aurez des problèmes si cela change à l'avenir. Comme le montre l'exemple ci-dessous, nommons-le pour qu'il ne semble pas étrange même si la valeur change.
De plus, s'il est peu probable que la valeur change à l'avenir, je pense que vous pouvez l'utiliser telle quelle sans utiliser de force une constante. Voici un autre exemple.
public static boolean isEven(int num) {
return num % 2 == 0;
}
Comme vous pouvez le voir, c'est le code qui détermine si le nombre est pair. J'utilise des littéraux numériques tels que "2" et "0" tels quels, mais dans cet exemple, il est peu probable que ces chiffres changent à l'avenir. Par conséquent, je ne pense pas qu'il y ait de problème particulier si vous utilisez le littéral tel quel.
J'ai souvent vu du code travailler dur avec des instructions for ordinaires où des instructions for étendues peuvent être utilisées. Si vous n'avez pas besoin d'un compteur de boucles, utilisez l'instruction for étendue. Il est plus facile à écrire, laisse moins de place aux bogues et est plus facile à lire. Je ne peux pas penser à une raison de ne pas l'utiliser quand il peut être utilisé, mais vous ne connaissez probablement pas son existence. Il y a une telle personne! ?? Vous pourriez penser, mais je pense que c'est normal. Mais comme je l'ai écrit au début, je n'ai pas l'intention de les supprimer. Si vous ne savez pas, il vous suffit de savoir à partir de maintenant. De plus, si vous utilisez Java 8 ou version ultérieure, envisagez d'utiliser l'API Stream.
Il est courant de donner aux classes un nom qui identifie leurs responsabilités, mais dans certains projets, toutes les classes étaient nommées par ID de fonctionnalité. C'est un exemple auquel j'ai pensé correctement, mais par exemple, "AP060.java", "AP060BLogic.java", "AP060Bean.java", etc. Avec cela, je n'ai aucune idée de ce qu'est chaque classe. Eh bien, si vous vous souvenez de quel ID de fonction est quelle fonction, c'est étonnamment bon, alors j'ai pensé que les êtres humains sont incroyables, mais en général, reconnaissez que c'est une règle de dénomination anormale. est nécessaire.
Vous n'avez pas besoin d'écrire ceci non plus, mais donnez-lui un nom qui vous dira ce qu'est la classe. Nom important.
J'ai aussi souvent vu du code où le nombre de lignes dans une instruction if est trop long pour comprendre ce qui est écrit où. Des centaines de lignes et de traitements sont écrits dans l'instruction if, et quand je pense que c'est fini, il semble que du code similaire continue à l'infini dans else cette fois. La plupart des conditions de branchement sont les mêmes, comme pour un nouvel enregistrement et une mise à jour, mais il existe de nombreux cas où les valeurs sont différentes. Utilisez l'instruction if uniquement pour les différences ...
J'ai écrit un peu, mais si c'est le même processus, vous devriez le mettre hors de l'instruction if et de la branche conditionnelle uniquement la différence. De plus, même s'il s'agit d'une branche conditionnelle significative, il est toujours douloureux d'être long, donc dans un tel cas, j'aimerais poursuivre la lisibilité avec un peu d'ingéniosité, par exemple en supprimant le traitement de l'instruction if d'une méthode et en lui donnant un nom facile à comprendre. .. Dans certains cas, vous voudrez peut-être déterminer si vous pouvez utiliser le polymorphisme pour éliminer la branche conditionnelle elle-même.
Je vois souvent du code qui définit une variable locale au début d'une méthode, mais qui utilise en fait cette variable autant ci-dessous. Si vous ne le faites pas dans (les anciennes versions de) C, vous obtiendrez une erreur de compilation, mais Java n'a pas cette limitation, donc cela n'a aucun sens. Il est simplement difficile de comprendre la partie définition de la variable et la partie à utiliser. De plus, certaines variables ont été volontairement définies comme des champs même si les variables locales étaient suffisantes. S'il s'agit d'un champ, il peut être lu et écrit par d'autres méthodes, il sera donc difficile de suivre la transition de la valeur.
Définissons les variables locales lorsque nous en avons besoin. Définissez également des variables qui ne sont utilisées que dans une méthode en tant que variables locales, et non des champs. Eh bien, l'IDE peut vous avertir ici.
C'est un pseudo code, mais je vois souvent du code comme celui-ci. Savez-vous ce qui ne va pas?
ResultSet rs = null;
try {
for(HogeBean bean : beanList) {
//Traitement à l'aide de haricots...
rs = stmt.executeQuery();
//Traitement avec rs...
}
} finally {
if(rs != null) {
rs.close();
}
}
Eh bien, comme vous pouvez le deviner à partir de l'en-tête, la libération des ressources n'est pas effectuée correctement. Puisque nous réutilisons la variable rs dans la boucle, close () n'est appelée correctement que dans la dernière.
Assurez-vous que close () est appelé pour tout, par exemple en mettant try-finally dans l'instruction for. De plus, utilisez try-with-resources pour Java 7 et supérieur. Eh bien, je pense que cela sera détecté par des outils d'analyse statique.
L'indentation est importante. Les sources avec une indentation correcte sont vraiment difficiles à lire. Surtout quand les instructions if et for sont imbriquées. J'ai souvent vu du code horrible, comme l'indentation dans un espace vide, ou ne pas le faire là où c'était nécessaire. C'était vraiment difficile à lire en combinaison avec ce qui précède [Le code dans l'instruction if est trop long](Le code dans l'instruction #if est trop long). Peut-être que la personne qui l'a écrit est également confuse. Des centaines de lignes de code en sont la cause ... Mais ce n'est pas tout. Il y a un problème [Commentez les corrections et laissez-les toutes](#Commentez les corrections et laissez-les toutes). La plupart des membres ont commenté en ajoutant "//" à la première ligne, mais si vous faites cela, le code commenté sera légèrement en retard. C'était aussi une source de confusion. De plus, j'aimerais le corriger autant que l'indentation, mais j'ai senti qu'il était difficile de le réparer à cause des règles laissées dans le commentaire. D'une manière ou d'une autre, plusieurs causes étaient liées et c'était terrible, et je ne pouvais que soupirer.
C'est un problème profondément enraciné, mais la première chose à faire est d'éliminer les règles de commentaire et de réduire des centaines de lignes de code. Si je peux faire cela, je pense que le retrait sera corrigé naturellement.
J'ai souvent vu du code qui utilise StringBuffer au lieu de StringBuilder pour concaténer des chaînes, où la sécurité des threads n'est pas requise. C'est également la même chose que [Ne pas utiliser l'instruction étendue pour](#Ne pas utiliser l'instruction étendue pour), et vous ne connaissez probablement pas l'existence de StringBuilder. Eh bien, cela n'a pas causé de problèmes de performances, alors peut-être que cela n'a pas d'importance.
==C'est un problème qui peut entraîner des bugs désagréables. Puisque les comparaisons de références sont faites entre les classes wrapper, des instances fondamentalement différentes renverront «false» même si elles ont la même valeur. Jusqu'à présent, c'est la même chose que de ne pas comparer des chaînes avec ==.
Cependant, le problème est que certaines valeurs peuvent renvoyer «true». Plus précisément, si les valeurs sont comprises entre -128 et 127, «true» sera renvoyé même s'il s'agit d'instances différentes si elles ont la même valeur. Cela peut faire mal de publier le code par rapport à == simplement parce que c'était bien quand il était testé avec une petite valeur. Faites attention.
Comparons en utilisant ʻequals` ainsi que String. En passant, je pense que ce problème sera détecté par des outils d'analyse statique.
Je l'ai vu. Cela semble être jeté dans la définition de la méthode, mais les exceptions qui ne peuvent jamais être levées dans la logique sont déclarées levées, de sorte que le code de gestion des exceptions se développe de manière explosive ... C'était déjà très proliférant car c'était une méthode importante appelée ici et là. L'exception n'est jamais levée. Le code pour gérer les exceptions qui ne peuvent jamais être levées peut uniquement être appelé garbage. Cela a rendu le code inutilement gonflé à nouveau. ~~ J'ai été froissé et effacé sans permission. C'était super bien. ~~
Concevez soigneusement la définition de la clause throws. Assurez-vous que l'exception peut vraiment être levée. Les exceptions vérifiées en Java ont le puissant pouvoir de forcer l'appelant à gérer les exceptions. Réfléchissez à deux fois s'il est vraiment approprié de forcer l'appelant à gérer l'exception.
iBATIS est un mappeur OR pratique, mais il n'est plus pris en charge depuis longtemps et ses spécifications sont anciennes, telles que le renvoi d'une liste de type Raw. Vous devriez passer au MyBatis suivant.
Dans Excel, vous pouvez regrouper des lignes et des colonnes spécifiques, et vous pouvez afficher ou masquer les parties groupées en un seul clic. Cette fonction est utilisée pour laisser le contenu non corrigé dans un état caché. C'est un substitut qui a beaucoup de mal et un seul profit. Tout d'abord, il laisse toutes les modifications, ce qui alourdit le fichier, prend plus de temps à afficher et réduit la productivité. De plus, bien qu'il soit généralement masqué, cela provoquera un bruit de recherche car il existe, et s'il y a un groupe au milieu lors de la création d'un numéro de série, etc. avec la fonction de remplissage automatique, le numéro de série sera également créé dans le contenu. C'est très dérangeant. C'est similaire à [Commentez les corrections et laissez-les toutes](#Commentez les corrections et laissez-les toutes). Fondamentalement, ce peut être une mauvaise idée d'avoir l'historique des modifications dans le fichier lui-même. De plus, bien que j'aie écrit qu'il y a un profit, il est pratique de pouvoir parcourir le contenu avant correction en un seul clic. Mais je ne peux penser qu'aux avantages, et il y a plus d'inconvénients.
Je pense qu'il serait préférable de gérer la version du document de conception avec SVN ou similaire. Bien sûr, les fichiers Excel sont des fichiers binaires, je ne suis donc pas très heureux de gérer la version telle quelle. Donc, je pense que vous devriez créer le document de conception avec Markdown ou AsciiDoc au lieu d'Excel. Dans ce cas, il s'agit d'un fichier texte, il est donc facile de gérer la version, et si vous aimez vraiment Excel, vous pouvez convertir Markdown et AsciiDoc en un fichier Excel. (Je ne l'ai pas vérifié correctement, mais je pense que je peux probablement le faire)
L'outil de mesure de la couverture qui a été chargé d'utiliser dans le projet était une méthode plutôt audacieuse de copie du code original entier et d'incorporation du code source pour la mesure de la couverture. (Je ne suis pas familier avec les outils de mesure de couverture, mais je pense qu'il est courant de les voir au niveau du code d'octet ...) Lors de la réalisation d'un test (test manuel au lieu d'UT), la règle était de construire le code source généré par l'outil et d'exécuter le test, mais l'outil le copiera et le placera. Comme seuls les fichiers Java sont utilisés, tous les autres fichiers XML, JSP, etc. ont dû être copiés manuellement et il a fallu beaucoup de temps avant que les tests puissent être effectués, ce qui était très gênant. En outre, il existe deux sources, la source d'origine et la source générée par l'outil, vous devez donc faire attention à garder les deux fichiers synchronisés. Après avoir un peu modifié la source, j'ai oublié de refléter la modification dans la source de mesure, et j'ai dû refaire le test plusieurs fois. De plus, la mystérieuse application Swing devait fonctionner pour mesurer la couverture, ce qui était lourd et ennuyeux. De plus, même si l'application Swing n'est pas lancée, elle fonctionne normalement (ça marche, mais la couverture n'est pas mesurée), donc je l'ai remarqué plus tard et j'ai dû refaire le test. De cette façon, nous avons été contraints d'utiliser des outils qui n'étaient pas faciles à utiliser, et nous étions moins productifs.
Pour être honnête, je ne connais pas les outils de mesure de la couverture, mais je pense que j'aurais dû utiliser JaCoCo ou un outil bien connu au lieu de l'outil oléore qui n'est utilisé qu'en interne. L'outil de mesure de la couverture que j'utilise actuellement sur mon lieu de travail est JaCoCo, mais je ne pense pas qu'il y ait eu de processus qui provoquerait un accident, comme l'incorporation du code de mesure au niveau du code source. Au contraire, il est courant de mesurer la couverture pendant l'exécution de l'UT, et non pendant les tests manuels. En premier lieu, cela peut être un problème que UT ne soit pas écrit du tout. [^ no_ut] [^ no_ut]: L'absence d'un UT est certainement un problème, mais c'est la même chose du point de vue de la mesure de la couverture.
C'est aussi un mystère, mais vous êtes venu ici, n'est-ce pas? Il est difficile de consulter l'historique des correctifs car les validations sont réparties sur plusieurs (pas deux ou trois, mais plusieurs) pour un correctif. Peut-être que la signification du système de gestion des versions n'est pas bien comprise, et c'est juste un mécanisme qui permet à tout le monde de partager la source. C'est toujours une bonne chose, et certains héros quittent leur siège même s'ils n'ont pas tout commis. Si vous vérifiez en attendant, bien sûr, vous serez à moitié cuit et vous souffrirez d'erreurs de compilation persistantes.
Je n'ai pas d'autre choix que de vous dire quel est le système de gestion de version et comment le comportement ci-dessus l'affectera. C'est un problème parce que je viens d'une autre entreprise ou un cadre supérieur de mon entreprise ... (* Pas mon lieu de travail actuel)
Bien que l'on dise qu'il s'agit d'un code, il est devenu un gâchis car il contient un contenu autre que le code, mais je serais heureux s'il y avait un élément qui était utile.
Recommended Posts