Pourquoi MongoDB pilote Java utiliser un générateur de nombre aléatoire dans une condition?

Après l'inspection de l'histoire de cette ligne, ma principale conclusion est qu'il y a eu une certaine incompétence de la programmation au travail.

1. Que la ligne est inutilement compliquée. La forme générale

   a? true : b

   pour boolean a, b est l'équivalent de la simple

   a || b

2. Les environs de la négation et de l'excès de parenthèses spire encore plus les choses. En gardant à l'esprit Les lois De De Morgan c'est une simple observation que ce morceau de code s'élève à

   if (!_ok && Math.random() <= 0.1)
     return res;

3. Le commit que lancé à l'origine de cette logique avait

   if (_ok == true) {
     _logger.log( Level.WARNING , "Server seen down: " + _addr, e );
   } else if (Math.random() < 0.1) {
     _logger.log( Level.WARNING , "Server seen down: " + _addr );
   }

   —un autre exemple de l'incompétence de codage, mais l'avis de l' logique inverse: ici, l'événement est enregistré, si _ok ou dans 10% des cas, tandis que le code en 2. retourne 10% du temps, et les journaux de 90% du temps. De sorte que le plus tard commettre ruiné pas seulement de la clarté, mais la justesse de lui-même.

   Je pense que dans le code que vous avez posté, nous pouvons voir comment l'auteur a l'intention de transformer l'original if-then en quelque sorte littéralement dans sa négation nécessaires pour les premiers return condition. Mais ensuite, il a foiré et inséré un "double négatif" en inversant le signe de l'inégalité.

4. Style de codage, en dehors du stochastique de journalisation est assez douteux en pratique par elle-même, surtout depuis l'entrée de journal ne renseigne pas sur son propre comportement. L'intention est, de toute évidence, la réduction des retraitements du même fait: le fait que le serveur est actuellement en panne. La solution appropriée est d'enregistrer uniquement les changements de l'état du serveur, et non pas chacun de son observation, en plus d'une sélection aléatoire de 10% de ces observations. Oui, ça prend juste un peu plus d'effort, donc nous allons voir quelques.

Je ne peux qu'espérer que tous ces éléments de preuve de l'incompétence, le cumul de l'inspection seulement trois lignes de code, ne parlent pas assez de l'ensemble du projet, et que ce morceau de travail seront nettoyés dès que possible.

Ajouter un membre de la classe initialisé à négative 1:

  private int logit = -1;

Dans le bloc try, faites le test:

 if( !ok && (logit = (logit + 1 ) % 10)  == 0 ) { //log error

Ce sont toujours les journaux de la première erreur, puis tous les dix ultérieure d'erreur. Opérateurs logiques "court-circuit", donc logit seulement est incrémenté sur une erreur réelle.

Si vous souhaitez que le premier et le dixième de tous erreurs, indépendamment de la connexion, faire logit classe statique au lieu d'un membre.

Comme l'avait noté ce doit être thread-safe:

private synchronized int getLogit() {
   return (logit = (logit + 1 ) % 10);
}

Dans le bloc try, faites le test:

 if( !ok && getLogit() == 0 ) { //log error

Remarque: je ne pense pas que jeter de 90% des erreurs est une bonne idée.