Cet article décrit les dix principaux commandements que les développeurs Java doivent connaître. Partagez-le avec tout le monde pour votre référence, les détails sont les suivants :
En tant que développeur Java, l'amélioration de la qualité et de la maintenabilité de votre propre code est un sujet constant. J'ai vu cet article en ligne et je l'ai utilisé pour m'encourager.
Il existe de nombreuses normes et bonnes pratiques pour les développeurs Java. Cet article répertorie les dix règles de base que tout développeur doit suivre ; s'il existe des règles qui peuvent être suivies mais non suivies, cela conduira à une fin très tragique.
1. Ajoutez des commentaires à votre code
Tout le monde le sait mais oublie de le suivre. Comptez combien de fois avez-vous « oublié » d’ajouter une annotation ? C'est vrai : les commentaires n'apportent aucune contribution substantielle à la fonctionnalité du programme. Cependant, vous devez revenir encore et encore au code que vous avez écrit il y a deux semaines, peut-être toute votre vie, et vous ne devez pas vous rappeler pourquoi le code se comporte ainsi. Si ces codes sont les vôtres, vous êtes relativement chanceux. Parce que ça pourrait rappeler des souvenirs. Mais malheureusement, la plupart du temps, le code appartient à quelqu'un d'autre, et il y a de fortes chances qu'il ait quitté l'entreprise.
2. Ne compliquez pas les choses
Je l'ai déjà fait et je suis sûr que tout le monde l'a fait. Les développeurs proposent souvent une solution à un problème simple. Nous avons introduit les EJB pour une application avec seulement 5 utilisateurs. Nous utilisons un framework pour une application qui n'en a même pas besoin. Nous avons ajouté des fichiers de propriétés, des solutions orientées objet et des threads à l'application, mais elle n'en avait pas du tout besoin. Pourquoi faisons-nous cela ? Certains d'entre nous le font parce que nous ne savons pas comment mieux le faire, mais certains d'entre nous le font pour acquérir de nouvelles connaissances et rendre l'application plus intéressante pour nous-mêmes.
3. N'oubliez pas que « moins c'est plus » n'est pas toujours bon
L'efficacité du code est une bonne chose, mais dans de nombreux cas, écrire moins de lignes de code ne rend pas ce code plus efficace. S'il vous plaît laissez-moi vous montrer un exemple simple.
if(newStatusCode.equals("SD") && (sellOffDate == null || TodayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && TodayDate.compareTo(lastUsedDate)>0)) || (newStatusCode.equals ("OBS") && (OBSDate == null || TodayDate.compareTo(OBSDate)<0))){ newStatusCode = "NYP";} Je veux demander : est-il facile de dire ce que la condition if du code ci-dessus veut faire ? Supposons maintenant que celui qui a écrit ce code n'a pas suivi la règle numéro un : ajoutez des commentaires à votre code.
Ne serait-il pas plus simple de diviser cette condition en deux instructions if distinctes ? Considérons maintenant le code corrigé suivant :
if(newStatusCode.equals("SD") && (sellOffDate == null || TodayDate.compareTo(sellOffDate)<0 || (lastUsedDate != null && TodayDate.compareTo(lastUsedDate)>0))){ newStatusCode = "NYP ";}sinon if(newStatusCode.equals("OBS") && (OBSDate == null || TodayDate.compareTo(OBSDate)<0)){ newStatusCode = "NYP";}Ne serait-ce pas plus lisible ? Oui, nous avons répété la condition de déclaration. Oui, nous avons un « IF » supplémentaire et deux paires de parenthèses supplémentaires. Mais le code est mieux lisible et compréhensible.
4. S'il vous plaît, pas de code en dur
Les développeurs oublient ou ignorent souvent consciemment cette règle parce que, comme d'habitude, nous sommes pressés. Si nous suivons cette règle, nous risquons de prendre du retard. Nous ne pourrons peut-être pas mettre fin à notre état actuel. Mais combien de temps cela nous coûterait-il pour écrire une ligne supplémentaire de code définissant des constantes statiques ?
Voici un exemple.
public class A { public static final String S_CONSTANT_ABC = "ABC"; public boolean methodA(String sParam1){ if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){ return true } return false ;Désormais, chaque fois que nous devons comparer la chaîne « ABC » à une variable, il nous suffit de référencer S_CONSTANT_ABC au lieu de nous rappeler quel est le code réel. Il présente également l’avantage de faciliter la modification d’une constante à un seul endroit, plutôt que de la rechercher dans tout votre code.
5. N'inventez pas vos propres frameworks
Des milliers de frameworks ont été lancés, et la plupart d'entre eux sont open source. Beaucoup de ces frameworks sont d’excellentes solutions et sont utilisés dans des milliers d’applications. Vous devez suivre ces nouveaux cadres, au moins superficiellement. Parmi ces frameworks excellents et largement utilisés, l’un des exemples les meilleurs et les plus directs est Struts. Parmi tous les frameworks que vous pouvez imaginer, ce framework Web open source est un candidat idéal pour les applications Web. Mais vous devez vous rappeler la deuxième règle : ne compliquez pas les choses. Si vous développez une application avec seulement trois pages, n'utilisez pas Struts. Pour une telle application, il n'y a rien pour "contrôler" les requêtes.
6. N'imprimez pas de lignes et n'ajoutez pas de chaînes
Je sais qu'à des fins de débogage, les développeurs aiment ajouter System.out.println partout où bon leur semble, et on se dit qu'on supprimera ce code plus tard. Mais on oublie souvent de supprimer ces lignes de code, ou on ne veut tout simplement pas les supprimer. Nous utilisons System.out.println pour tester. Une fois le test terminé, pourquoi pouvons-nous toujours y accéder ? Nous pouvons supprimer une ligne de code dont nous avons réellement besoin simplement parce que vous avez sous-estimé les dommages causés par System.out.println. Considérez le code suivant :
public class BadCode { public static void calculatorWithPrint(){ double someValue = 0D; for (int i = 0; i < 10000; i++) { System.out.println(someValue = someValue + i } } public static void calculatorWithOutPrint( ){ double someValue = 0D; pour (int i = 0; i < 10000; i++) { someValue = someValue + i; } } public static void main(String [] n) { BadCode.calculationWithPrint();Dans le tableau ci-dessous, vous pouvez voir que l’exécution de la méthode calculatorWithOutPrint() a pris 0,001204 secondes. En comparaison, l’exécution de la méthode calculatorWithPrint() a pris 10,52 secondes.
(Si vous ne savez pas comment obtenir un tableau comme celui-ci, veuillez consulter mon article "Profilage Java avec WSAD" Profilage Java avec WSAD)
La meilleure façon d'éviter un tel gaspillage de CPU est d'introduire une méthode wrapper, comme la suivante
public class BadCode { public static final int DEBUG_MODE = 1; public static final int PRODUCTION_MODE = 2; public static void calculatorWithPrint(int logMode){ double someValue = 0D; someValue + i; myPrintMethod(logMode, someValue); } } public static void myPrintMethod(int logMode, double valeur) { if (logMode > BadCode.DEBUG_MODE) { return; } System.out.println(value); } public static void main(String [] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE) ; }}Dans la figure ci-dessous, vous verrez que la méthode utilisant StringBuffer n'a pris que 0,01 seconde à s'exécuter, tandis que la méthode utilisant l'ajout de chaîne a pris 0,08 seconde à s'exécuter. Le choix est évident.
7． Suivez l'interface graphique
Aussi ridicule que cela puisse paraître, je le répète encore et encore : l’interface graphique est aussi importante pour les clients professionnels que la fonctionnalité et les performances. L'interface graphique est un élément essentiel d'un système performant. (Cependant), les magazines informatiques ont souvent tendance à ignorer l'importance des interfaces graphiques. De nombreuses organisations économisent de l'argent en n'embauchant pas de concepteurs possédant une vaste expérience dans la conception d'interfaces graphiques « conviviales ». Les développeurs Java doivent s'appuyer sur leurs propres connaissances en HTML, mais leurs connaissances dans ce domaine sont très limitées. J'ai vu beaucoup d'applications comme celle-ci : elles sont "conviviales pour l'ordinateur", et non "conviviales". Je vois rarement un développeur compétent à la fois en développement de logiciels et en développement d'interface graphique. Si vous êtes le développeur malchanceux chargé de développer une interface utilisateur, vous devez suivre ces trois principes :
1. Ne réinventez pas la roue. Recherchez les systèmes existants avec des exigences d’interface utilisateur similaires.
2. Créez d’abord un prototype. C'est une étape très importante. Les clients aiment voir ce qu’ils vont obtenir. C'est également très bien pour vous, car vous obtenez leurs commentaires avant de tout mettre en œuvre et de créer une interface utilisateur qui va les mettre en colère.
3. Portez le chapeau de l’utilisateur. En d’autres termes, examinez les exigences de l’application du point de vue de l’utilisateur. Par exemple, si une page de résumé doit être paginée. En tant que développeur de logiciels, vous avez tendance à ignorer la pagination dans un système car elle vous laisse moins de complexité de développement. Cependant, ce n'est pas la meilleure solution du point de vue de l'utilisateur, car les données résumées comporteront des centaines, voire des milliers de lignes.
8. Préparez toujours des exigences documentées
Chaque exigence commerciale doit être documentée. Cela peut être vrai dans certains contes de fées, mais ce n’est pas possible dans le monde réel. Peu importe le délai de développement ou si la date de livraison approche, vous devez toujours savoir que chaque exigence commerciale est documentée.
9. Tests unitaires, tests unitaires, tests unitaires
Je n'entrerai pas dans les détails de la meilleure façon de tester unitairement votre code. Ce que je vais dire, c'est que des tests unitaires doivent être effectués. C'est la règle la plus fondamentale de la programmation. C’est la plus importante de toutes les lois ci-dessus qui ne peut être ignorée. Il est préférable que vous ayez des collègues capables de créer et de tester des tests unitaires pour votre code. Mais si personne ne le fait à votre place, vous devez le faire vous-même. Lors de la création de votre plan de tests unitaires, suivez ces règles :
1. Écrivez des tests unitaires avant d’écrire du code.
2. Écrivez des commentaires dans les tests unitaires.
3. Testez toutes les méthodes publiques qui exécutent des fonctions « intéressantes » (« intéressantes » signifie des méthodes qui ne sont pas des setters ou des getters à moins qu'elles n'exécutent des méthodes set et get d'une manière spéciale).
10. N'oubliez pas : la qualité, pas la quantité.
Ne restez pas trop tard au bureau (quand vous n'êtes pas obligé). Je comprends que parfois, des problèmes de produits, des délais serrés et des événements inattendus peuvent nous empêcher de quitter le travail à temps. Cependant, dans des circonstances normales, le manager n'appréciera pas et ne récompensera pas les employés qui quittent le travail trop tard. Il les apprécie en raison de la qualité des produits qu'ils fabriquent. Si vous suivez les règles que j'ai données ci-dessus, vous constaterez que votre code contient moins de bugs et est plus maintenable. Et c'est la partie la plus importante de votre travail.
Résumer
Dans cet article, je donne dix règles importantes pour les développeurs Java. Il est important non seulement de connaître ces règles, mais également de les suivre lors du processus de codage. Espérons que ces règles nous aideront à devenir de meilleurs programmeurs et professionnels.
J'espère que cet article sera utile à tout le monde dans la programmation Java.