J’abandonne

Samedi dernier, Codingame lançait code4life, le dernier contest en date.

N’écoutant que mon courage, je m’y suis jeté. Avec d’abord une implémentation basique pour atteindre le bronze, puis deux déclinaisons successives d’une machine à état.

Et aujourd’hui, avec cette machine profondément optimisée, je suis environ 250ème en silver. Il ne fait aucun doute que d’ici Lundi matin, je vais perdre encore 500 places. Mais je vais arrêter là ce contest. Plusieurs raisons à ça, que je vais détailler ici (non, je ne mettrai pas de post-mortem sur GitHub).

Fais une chose, et fais-la bien

J’ai commencé mon nouveau poste chez Zenika la semaine dernière. Et j’ai entamé ma première mission ce jeudi. Je pourrais vous mettre la liste des mots-clés ici, mais ce serait sûrement un peu prétentieux. Toujours est-il que beaucoup de technologies dans ce projet sont pour moi une nouveauté, ce qui m’a forcé à courir à fond dans la direction des découvertes techniques, ce qui n’est pas forcément compatible avec la précision, la focalisation nécessaire à la réussite d’un contest. Du coup, depuis avant-hier, je n’ai plus de gaz pour réfléchir correctement au problème.

C’est dommage pour mon succès à Codingame, et contrairement à un autre Nicolas, je ne risque pas de gagner de t-shirt, mais d’un autre côté, avoir trop de choses intéressantes à faire, c’est clairement un problème de riche.

Les streams, c’est fini

A un moment donné, j’ai commencé à avoir des sales problèmes de timeout. J’ai pu, à ma surprise et ma déception, j’ai pu associer chacun de ces timeouts à une utilisation des streams Java. Vous imaginez le truc ? Chaque utilisation de stream a occasionné à un moment ou un autre un timeout.

Attention, je ne dis pas que les streams sont mauvais. Juste que pour un contest codingame, les streams doivent être soigneusement évités.

Et ça n’est pas tout.

Vous avez tous vus les déclarations de Comparator sauce Java8 comme cet exemple

Eh bien de la même manière, chaque déclaration de Comparator avec une fonction s’est révélée trop coûteuse en temps CPU. Du coup, j’ai tout viré et tout réécrit de façon traditionnelle.

Et ça, n’importe quel chef de projet informatique vous le dira, ça a un coût. En l’occurence, du temps passé. En regardant mes commits Git, je dirais que j’ai perdu une heure à corriger ces problèmes de performance, avec à chaque fois ces étapes

  1. Copier le test généré
  2. Exécuter le PerformanceTest avec debug et VisualVM connecté
  3. Trouver le bout de code lent
  4. Remplacer le stream par un foreach façon java5

Démoralisant.

Les machines à état, c’est caca

Quand on regarde les règles, clairement, il y a différents états. J’ai tenté de les détailler dans ce schéma (vous pouvez le regarder en détail, mais franchement, on s’en fout).

sequence

Ca a l’air sophistiqué, non ? Eh ben ça l’est … Et je suis loin d’être sûr de la justesse du truc

En fait, tout ça ne sert à rien.

Ca simplifie peut-être un peu le code, mais d’une façon malsaine : je me retrouve à micromanager alors que je devrais arbitrer. Et du coup, chaque état (qui a certes une classe associée) se complique, devient plus lourd, nécessite plus de maintenance.

En vrai, si j’écoutais ce que des gens plus intelligents disent, ce que j’aurais dû faire, c’est de la programmation dynamique.

C’est-à-dire qu’à chaque tour, j’aurais dû calculer tous les mouvements possibles avec autant de profondeur que possible, et choisir le mouvement qui m’apportait statistiquement le meilleur résultat.

Mais je me suis entêté avec ma machine à état. Et je me retrouve comme un con la veille de la fin, sans avoir le temps de corriger mon code. C’est moche. Très moche.

OK, donc t’es qu’une merde en fait ?

Pas tout à fait non plus.

J’ai un peu modifié mon générateur de tests pour y inclure automatique un assertThat(myCommand).isNotEqualsTo(« La commande exécutée ») et ça me fait gagner encore un peu de temps. Par ailleurs, je compte en gagner encore plus – un jour – via un système d’annotation pour écrire automatiquement la méthode de génération de test unitaire (JavaParser et annotations seront de la partie).

Et je vais prochainement releaser sur maven central mon plugin de génération de classe unique.

Ce ne sont pas des victoires, c’est vrai, et je ne gagne pas de XP. Mais je fais des choses qui m’amusent aussi.

Donc tu vas faire le prochain ?

On verra … Mais je pense que oui.

Publicités