Pourquoi le pilote Java MongoDB utilise-t-il un générateur de nombres aléatoires au conditionnel?

J'ai vu le code suivant dans cette validation pour le pilote de connexion Java de MongoDB , et il semble d'abord être une blague en quelque sorte. Que fait le code suivant?

if (!((_ok) ? true : (Math.random() > 0.1))) {
    return res;
}

(EDIT: le code a été mis à jour depuis la publication de cette question)

Après avoir inspecté l'historique de cette ligne, ma principale conclusion est qu'il y a eu une programmation incompétente au travail.

1. Cette ligne est alambiquée gratuitement. La forme générale

   a? true : b

   car boolean a, best équivalent au simple

   a || b

2. La négation environnante et les parenthèses excessives compliquent encore les choses. En gardant à l'esprit les lois de De Morgan, c'est une observation banale que ce morceau de code équivaut à

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

3. Le commit qui a initialement introduit 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 codage incompétent, mais notez la logique inversée : ici l'événement est enregistré si soit _okou dans 10% des autres cas, alors que le code en 2. renvoie 10% des fois et enregistre 90% des fois. Ainsi, le dernier engagement a ruiné non seulement la clarté, mais l'exactitude elle-même.

   Je pense que dans le code que vous avez publié, nous pouvons réellement voir comment l'auteur avait l'intention de transformer l'original en if-thenquelque sorte littéralement en sa négation requise pour la première returncondition. Mais ensuite il a gâché et inséré un "double négatif" efficace en inversant le signe de l'inégalité.

4. Mis à part les problèmes de style de codage, la journalisation stochastique est une pratique assez douteuse en soi, d'autant plus que l'entrée de journal ne documente pas son propre comportement particulier. L'intention est évidemment de réduire les retraitements du même fait: que le serveur est actuellement en panne. La solution appropriée consiste à consigner uniquement les modifications de l'état du serveur, et non chacune son observation, sans parler d'une sélection aléatoire de 10% de ces observations. Oui, cela demande un peu plus d'efforts, alors voyons-en.

Je ne peux qu'espérer que toutes ces preuves d'incompétence, accumulées en inspectant seulement trois lignes de code , ne parlent pas du projet dans son ensemble et que ce travail sera nettoyé dès que possible.

https://github.com/mongodb/mongo-java-driver/commit/d51b3648a8e1bf1a7b7886b7ceb343064c9e2225#commitcomment-3315694

Il y a 11 heures par gareth-rees:

L'idée est probablement de ne consigner qu'environ 1/10 des défaillances du serveur (et donc d'éviter de spammer massivement le journal), sans encourir le coût de maintenance d'un compteur ou d'une minuterie. (Mais le maintien d'une minuterie serait sûrement abordable?)

Ajouter un membre de classe initialisé à négatif 1:

  private int logit = -1;

Dans le bloc try, faites le test:

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

Cela enregistre toujours la première erreur, puis une erreur sur dix. Les opérateurs logiques "court-circuitent", donc logit n'est incrémenté qu'en cas d'erreur réelle.

Si vous voulez le premier et le dixième de tous erreurs, quelle que soit la connexion, rendez la classe logit statique au lieu d'un membre.

Comme cela avait été noté, cela devrait ê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 90% des erreurs soit une bonne idée.

J'ai déjà vu ce genre de choses auparavant.

Il y avait un morceau de code qui pouvait répondre à certaines «questions» qui provenaient d'un autre morceau de code «boîte noire». Dans le cas où il ne pourrait pas y répondre, il les transmettrait à un autre morceau de code «boîte noire» qui était vraiment lent.

Ainsi, parfois, de nouvelles «questions» inédites apparaissaient et apparaissaient en lot, comme 100 d'entre elles d'affilée.

Le programmeur était satisfait du fonctionnement du programme, mais il voulait peut-être un moyen d'améliorer le logiciel à l'avenir, si de nouvelles questions étaient découvertes.

Donc, la solution était de consigner des questions inconnues, mais il s'est avéré qu'il y avait des milliers de questions différentes. Les journaux sont devenus trop gros et il n'y avait aucun avantage à les accélérer, car ils n'avaient pas de réponses évidentes. Mais de temps en temps, un lot de questions apparaissait et pouvait être répondu.

Étant donné que les journaux devenaient trop volumineux et que la journalisation gênait la journalisation des choses vraiment importantes qu'il avait apportées à cette solution:

N'enregistrez que 5% au hasard, cela nettoiera les journaux, tout en montrant à long terme quelles questions / réponses pourraient être ajoutées.

Donc, si un événement inconnu se produisait, dans un nombre aléatoire de ces cas, il serait enregistré.

Je pense que cela ressemble à ce que vous voyez ici.

Je n'aimais pas cette façon de travailler, j'ai donc supprimé ce morceau de code et j'ai simplement consigné ces messages dans un fichier différent , ils étaient donc tous présents, mais sans encombrer le fichier journal général.