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?
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(){
・ ・ ・
}
・ ・ ・
}
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() {
・ ・ ・
}
・ ・ ・
}
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();
}
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;
}
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
}
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
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() {
・ ・ ・
}
É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();
}
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.
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);
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
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 {
・ ・ ・
}
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é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.
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
}
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.
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
}
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?
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!"
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.
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.
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.
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.
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.
À 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