Programmation Java incroyable (arrêtons-nous)

introduction

Il y a le mot «principe du minimum de surprise».

Citant un article Wikipédia http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87

Dans la conception et l'ergonomie des interfaces utilisateur et des langages de programmation, lorsque les deux éléments d'une interface sont incohérents ou peu clairs, le comportement qui semble le plus naturel (moins surprenant) à un utilisateur humain ou à un programmeur L'idée est que vous devez choisir.

Bref, il vaut mieux avoir moins de surprises lors de son utilisation [1]. [1]: Il y a pas mal de situations où je me demande laquelle est la moins surprenante ...

Dans cet article, j'oserai vous présenter comment écrire un ** nombreux ** programmes surprenant. Découvrez ce que l'on ressent en lisant un programme surprenant. Bien sûr, il vaut mieux écrire un programme moins surprenant, alors ne le copiez pas, non?

Surprise avec le codage

Cas non chameau

En Java, il est courant d'utiliser le cas camel (hors constantes). Si vous le cassez, tout le monde sera surpris.

public class db_manager {
    private String connection_url;
    
    public void Init(){
・ ・ ・
    }
・ ・ ・
}

Nom du numéro de série

Gérez minutieusement les noms de classe, les noms de méthode et même les noms de champ pour créer des numéros de série. L'impact que le contenu ne peut pas être imaginé à partir du nom est assez grand.

public class UC8010 extends CMN0101 {
    private String FLD0001;
    
    public int MTD0001() {
・ ・ ・
    }
・ ・ ・
}
publi class UC8020 extends CMN0101 {
    private String FLD0001;
    
    public int MTD0001() {
・ ・ ・
    }
・ ・ ・
}

drapeau

Tout le monde est surpris si le nom du drapeau contient une valeur autre que true, false ou 0,1.

String modeFlag = getFlag();
switch(modeFlag) {
    case "LOGIN":
・ ・ ・
    case "LOGOFF"
・ ・ ・
}

C'est également une bonne idée d'inverser le nom et le comportement des drapeaux.

if (skipFlag == true) {
    execute();
}

Faites quelque chose qui n'est pas dans le nom

Faisons des choses qui ne sont pas écrites dans le nom. L'exemple ci-dessous est une méthode qui prétend être une méthode qui vérifie la valeur, et si le résultat est OK, le traitement suivant se poursuivra. Êtes-vous surpris?

boolean checkValue(int value) {
   if (value == -1) {
      return false;
   }
   execute(value);
   return true;
}

Noms qui ne seront probablement pas pertinents

Si vous avez une interface appelée IFHoge et une classe appelée Hoge, je pense que tout le monde est Hoge implements IFHoge. C'est amusant d'imaginer le visage de l'autre personne trahie là-bas.

public interface IFHoge {
    void someMethod()
}
public class Hoge {
   //Cela n'a rien à voir avec IFHoge
}

Écrivez un commentaire que vous pouvez voir

Si vous ajoutez un commentaire au processus explicite, vous serez surpris de voir à quel point il est poli.

int time = endTime - startTime; //endTemps en temps-Remplacer startTime

Commentaire de traduction en japonais du nom

Il est trop courant d'écrire dans un commentaire ce qu'il fait, ce qu'il est censé être, les précautions à prendre, etc. Par conséquent, concentrons-nous sur la traduction japonaise du nom dans les commentaires. Je suis surpris que "je n'ai rien écrit que je veux savoir!"

/*
 *Vérification de la valeur
 */
booelan checkValue() {
・ ・ ・
}

Commentaire de mensonge

Évidemment, je suis surpris que ce que je dis dans les commentaires soit différent de ce que je fais réellement.

Il est difficile de mentir ouvertement avec un nouveau code. L'opportunité est lorsque le système est remis à neuf. Lorsque vous réécrivez le code source, laissez les commentaires de la source d'origine tels quels sans les mettre à jour. En un clin d'œil, les commentaires et le traitement seront séparés.

if (mode == STANDBY) {
   //En mode veille, ne rien faire et revenir immédiatement
   standbyService.execute();
}

Large champ

Afin de surprendre beaucoup de gens, l'histoire ne commencera que si beaucoup de gens la voient. Utilisons activement public. Plus la portée est large, mieux c'est.

public void publicMethod() {
    innerMethod();
}

public void innerMethod() {
    //Quelque chose de traitement
}

Si vous avez une chance d'hériter d'une classe, ce serait bien d'élever toute la visibilité de la méthode au public.

Utilisez ce que vous pouvez utiliser

Au contraire, si vous pouvez utiliser quelque chose que vous ne devriez pas utiliser à première vue, utilisez-le. Utilisons-le activement même avec des API privées et des classes et méthodes obsolètes. Il est un gaspillage. L'auteur est étonné de voir comment il est utilisé de manière inattendue.

 sun.misc.BASE64Encoder e = new sun.misc.BASE64Encoder();
 String encoded = e.encode(buf);

réflexion

Un code bien conçu est bien encapsulé et ne peut pas être touché seul. C'est donc la réflexion. Il n'est pas exagéré de dire que la réflexion existe pour surprendre les gens sauf pour des situations graves comme la création de cadres.

Class c = obj.getClass();
Field f = c.getField("counter");
f.setInt(obj, 0);   //Remettre le compteur à zéro

L'héritage qui n'est pas est-un

Selon la façon dont vous utilisez l'héritage, vous serez très surpris.

Par exemple, supposons que le traitement DB est abstrait en tant que DBStrategy afin de basculer le traitement en fonction du type de DB. Le traitement de chaque DB est effectué en implémentant cette interface.

interface DBStrategy {
・ ・ ・
}
class MySQLStrategy implements DBStrategy {
・ ・ ・
}
class SQLServerStrategy implements DBStrategy {
・ ・ ・
}

Après l'avoir implémenté, j'ai remarqué que MySQL Strategy et SQL Server Strategy ont de nombreux processus similaires.

Dans un tel cas, créons une stratégie SQL Server qui hérite de la stratégie MySQL comme celle-ci et ne programmons que les différences. Tout le monde pense "ça!?" C'est parce que ce n'est pas "SQL Server est MySQL".

interface DBStrategy {
・ ・ ・
}
class MySQLStrategy implements DBStrategy {
・ ・ ・
}
class SQLServerStrategy extends MySQLStrategy  {
・ ・ ・
}

Vous ne serez pas surpris si vous l'écrivez directement comme ci-dessous.

interface DBStrategy {
・ ・ ・
}
abstract class AbstractDbStrategy implements DBStrategy {
・ ・ ・
}
class MySQLStrategy extends AbstractDbStrategy {
・ ・ ・
}
class SQLServerStrategy extends AbstractDbStrategy {
・ ・ ・
}

Abattu

Si vous voulez une classe concrète, abattons-nous activement. Bien entendu, il vaut mieux ne pas effectuer autant que possible l'inspection de type. En outre, il n'est pas nécessaire de repenser. Plus tard, certaines personnes seront surprises de ne pas pouvoir changer de classe concrète.

public void execute(DBStrategy strategy) {
    MySQLStrategy mySqlStrategy = (MySQLStrategy)strategy;
・ ・ ・
}

Dépendance dense

Dépendons activement des autres classes. Plus c'est compliqué, mieux c'est. Si vous dérangez cela, il se cassera et vous ne pourrez pas le réparer en fonction de cela. Aucun test. Si vous n'insistez pas autant, vous ne serez pas surpris.

Exceptions écrasantes

Voici les bases des bases. Il n'est pas exagéré de dire que si vous voulez surprendre les gens, partez d'ici. Le système résultant se comporte étrangement et surprend l'utilisateur, et l'opérateur est également surpris car il est difficile à déboguer car le mauvais emplacement ne peut pas être identifié.

try {
    someService.execute();
} (SomeServiceException e) {
    //Je ne suis pas sûr, alors serrez-le
}

Jeter l'exception sous-jacente

Il existe un moyen légèrement plus avancé de supprimer l'exception sous-jacente. Jetons l'exception racine lors de la capture d'une exception, la convertissons en une autre exception et la lançons plus haut.

try {
    someService.execute();
} (SomeServiceException e) {
    throw new SystemException();
    // throw new SystemException(e); //← Ce n'est pas surprenant
}

Si vous faites cela, vous ne verrez pas l'exception sous-jacente dans le journal en cas de problème, vous ne pourrez donc plus la suivre. Ceux qui déboguent sont très surpris.

Attrapez les exceptions qui ne devraient pas être gérées

Il existe des exceptions qui résultent d'erreurs de codage. Un exemple typique est NullPointerException. C'est une règle de base de coder ces exceptions afin qu'elles ne se produisent pas en premier lieu, mais attrapons-les et gérons-les. Il y a beaucoup de gens qui sont surpris car la découverte de situations étranges est retardée.

try {
    someService.execute();
} catch(NullPointerException e) {
    //Laisse moi récupérer
}

Faites-le aussi bien que possible

Donnez à l'objet autant d'état que possible. N'est-il pas intéressant d'avoir un monde où le même résultat est garanti à chaque appel?

Ignorer les exigences du code de hachage

En Java, si vous remplacez la méthode Object # equals (), vous devez également remplacer correctement la méthode Object # hashCode (). C'est une condition requise pour utiliser Hashtable et HashMap. Je n'ai pas l'intention de mettre cette classe dans HashMap, donc si vous pensez que vous devriez, ignorez-la. Le jour viendra où vous serez surpris, "Hein? L'avez-vous mis dans HashMap? Ça ne marche pas!"

Surprise dans le test

Pas de test automatisé

Il est désormais courant de faire des tests automatisés avec des outils tels que JUnit et Selenium. Les membres du projet seront surpris s'ils ne font pas ces choses.

100% de couverture

Si vous voulez vraiment faire des tests automatisés, assurez-vous de viser une couverture de test à 100%. Les membres seront surpris de l'objectif lui-même, et vous serez surpris de la qualité non améliorée car vous serez obligé d'écrire des tests juste pour la couverture.

Surprise avec la direction

Cachez le moins possible le code que vous écrivez

Montrer le code aux autres signifie donner plus d'informations. Afin de maximiser la surprise de l'autre partie, il doit être émis à ce moment sans donner d'informations préalables. Pour cette raison, essayez de minimiser les chances de montrer votre code à d'autres.

Gestion de l'historique manuellement

Gérez vos anciennes sources dans le dossier de dates. Bien sûr, commentez la partie modifiée du code source et laissez-la dans la source, et ajoutez la date et le nom / nom de la société.

Lorsque vous voyez cela, vous pouvez vivre une expérience surprenante comme si vous aviez soudainement glissé dans le temps dans la période Edo.

Construire manuellement

La construction se fait manuellement. Si vous faites une erreur, ne l'automatisez pas. Il vaut mieux ne pas faire de procédure de construction si cela est autorisé. Pour finir, il est préférable de placer un pot d'origine inconnue dans le dossier lib. Le successeur sera surpris.


Les références


Enfin un petit pied de serpent

À l'origine, cet article commençait par la phrase suivante sous le nom "Amazing Java Programming".

La simple programmation est ennuyeuse. Je veux faire quelque chose qui surprend tout le monde. Une collection de conseils divers qui peuvent être utilisés dans de tels cas.

Heureusement, il a été lu par plus de gens que je ne l'avais imaginé, et beaucoup de gens ont dit que c'était intéressant.

D'un autre côté, certaines personnes ont dit: «J'ai ouvert cet article dans l'espoir d'un moyen de vraiment le surprendre, mais j'ai été déçu» et «Je suis inquiet si quelqu'un le recevra vraiment». En d'autres termes, c'était un état boomeran que l'article lui-même, qui tentait de faire appel au «principe de la surprise minimale», contenait des surprises. Tohoho ...

Je pensais que l'état était ironique et intéressant, mais je voulais clairement insister sur le "principe de la surprise minimale", alors j'en ai fait le format actuel.

Recommended Posts

Programmation Java incroyable (arrêtons-nous)
Étudions Java
bases de la programmation Java
Programmation générique java
Programmation par contraintes en Java
Bases de la programmation Java Practice-array
Programmation Java (méthode de classe)
Raclons avec Java! !!
Programmation Java (structure de classe)
Tout sur la programmation Java
mémo de programmation du concours java
Thread de programmation Java exécutable
Expérimentons l'expansion en ligne Java
Programmation Java (variables et données)
Exploitons Excel avec Java! !!
Bases du développement Java-Pratique ③ Programmation avancée-
Instruction pratique de base de la programmation Java
Instruction de base de la programmation Java Practice-Switch
[Java] Termes de base en programmation
Commençons par la programmation parallèle
Aide-mémoire privé pour la programmation compétitive (Java)
Utilisons Twilio en Java! (Introduction)
Cahier d'exercices de programmation de fonctions Java --zipWith-
Introduction à la programmation fonctionnelle (Java, Javascript)
[Programmation complète] §3 Calculons avec Ruby!
Résumé de la programmation orientée objet utilisant Java
Pensons à ce qu'est la programmation déclarative en Java et Elm (partie 1)