Une expérience : refactorer un peu de code de ZdS en live !

Bonne idée, j’approuve

Je vais essayer de passer !

will be there

Y’aura une rediff dispo quelque part ?

Twitch te permet de rediff, suffit d’activer l’option.

Mon gars, t’as tellement pas intéret à louper ta refactorisation. Mais j’approuve l’idée.

Super idée ! J’espère être dispo à ce moment.

PS : Pour ceux qui se posent la question, ça fait 12h UTC et 8h heure de Montréal.

Il fallait mettre un bloc jsfiddle avec un countdown à l’intérieur.

Pour ceux qui ont un doute sur leur décalage horaire : http://jsfiddle.net/9dgvd59c/

Haha, ouais mais non.

1. Je ne suis pas un développeur python, mes connaissances de ce langage et de django sont assez limitées.
2. Je l’ai dit, le but n’est pas de partir du code actuel qui est moche mais qui fonctionne et d’avoir 1h plus tard du code élégant qui fonctionne.

Donc je ne peux pas me planter.

Il n’y a pas besoin d’être expert dans ces 2 technos pour être capable de grandement améliorer la qualité de ce à quoi je m’attaquerai demain. Le refactoring, c’est une question d’expérience et de feeling. Il faut comprendre ce que le code fait, et avoir le sens de ce qu’on peut extraire, ce qu’on peut généraliser, ce qu’on peut éliminer, ce qu’on peut simplifier.

Je te donne un exemple de bon refactoring d’hier lié à ZdS. Vos signatures, ici en commentaire et sur les forums, c’est du Markdown. En revanche seul les éléments "inline" sont parsés. C’est une des dernières choses qui manquait à notre nouveau parseur de Markdown. J’ai donc développé un plugin pour le parseur pour désactiver le parsing des éléments block. Ensuite, pour permettre d’utiliser le plugin partout sans devoir changer ce que le parser charge automatiquement, j’ai mis une option permettant de désactiver le désactivage des blocks. Ensuite, je me suis dit que dans le futur certains auraient peut-être des blocks custom parsés par plugin, et qu’il fallait donc que les types de noeuds blocks à désactiver soient configurable. J’ai généralisé la chose. Ensuite je me suis dit qu’il n’y avait pas de raison de ne rendre désactivables par ce plugin que les éléments blocks, j’ai donc rendu configurable la désactivation des noeuds block ou inline passés en argument. Ensuite je me suis dit qu’il y avait deux use cases possibles : soit on veut ignorer ces éléments et donc garder le markdown des éléments pas parsés, soit on veut lancer une exception pour activement prévenir leur emploi. J’ai donc implémenté une config permettant ces 2 cas.

Dans les 2h qu’il m’a fallu pour arriver à l’API finale de mon plugin, et à son code final, il y a eu 4 refactoring. Et c’est ça, développer. C’est pas cracher des centaines de lignes de code, pas foutre le max de features possibles.

C’est plutôt

• définir une API la meilleure possible pour ton module / ta fonction / ton programme
• l’implémenter de la façon la plus maintenable possible. Pas possible de donner une liste exhaustive de ce à quoi on peut penser ici, mais par exemple être le plus clever possible dans ton utilisation du langage à disposition, c’est l’inverse de rendre ton code maintenable.

Je ne peux donc pas me planter dans mon refactoring. Je vais prendre du code écrit pour l’interpréteur Python et en faire du code écrit pour les êtres humains qui auraient dû être la cible originelle de ce code. Les êtres humains censés maintenir et débugger ce code.

Je suis pas une autorité en la matière, ce que je vais faire demain je suis pas la référence, vraiment pas. Mais à force de voir du code entrer dans ZdS et voir ce qu’il y a dedans, et sachant bien que le refactoring ça s’apprend pas dans les cours, ni tout seul dans son coin, je me dis que ça vaut la peine de montrer ce que je pense.

Genial , @vhf j’y serrai

Il faut plutôt y voir… un élan.

Un caribou aurait donc été plus adapté

Le caribou, symbole du refacto ?

C’était stylé. J’ai bien aimé. Pas trop de com’. T’es peut-être allé un peu vite sur certaines manip’ relatives à git / gist et co’ et l’environnement de dev, mais comme j’ai attrapé le live en vol, peut-être que tu as fais quelques rappels en amont.

Merci aux participants !

Globalement c’était un succès.

• Merci à A-312 et Amar0k dont l’aide pour mettre en place Twitch et OBS m’a été indispensable.
• Il m’a fallu du temps pour réussir à coordonner mes pensées en gardant un oeil sur le chat. C’est pas facile, je me retrouve vite déconcentré par le chat, perdre ma pensée courante, et ça c’est pas bon.
• Prochaine fois je devrais peut-être me préparer un petit peu plus. Là il m’a fallu pas mal de temps pour comprendre qu’est-ce qui est quoi. C’est la preuve que ce refactoring était nécessaire : le code original était très opaque notamment parce que le nommage des variables était assez mauvais.
• Je ne sais pas à quel point je m’exprimais clairement ou je marmonnais des demi-phrases en mode stream of consciousness.
• J’ai beaucoup apprécié les commentaires sur le chat. Ça a donné quelque chose proche du pair-programming, où je peux expliquer ce que je comprends ET prendre en compte les idées présentées. Que des bons commentaires, pertinents et tout. Super !

J’aimerais remettre ça. J’aimerais voir ce que ça donne dans un domaine où je suis plus à l’aise que Python. Je pense qu’on peut faire plusieurs expériences potentiellement intéressantes pour l’équipe technique de ZdS et pour ZdS !

• Débugger un truc en live / résoudre un petit ticket.
• Implémenter une petite fonctionnalité en live.
• Mettre en prod en live ?

Implémenter une petite fonctionnalité en live.

je pense préparer ça pour août (le 2 ou le 3, je sais pas encore). Par contre faudra que je vois ce que je vais implémenter.

C’etait cool

J’ai téléchargé la rediff, je regarderais ça plus tard

Ça ne c’est pas vu pendant la diffusion. Après les premières minutes c’était très fluide.

Oui et non, ça aide les viewers à comprendre (parce que nous ne sommes pas non plus préparé ). Ça rend le stream plus naturelle/accessible. J’ai peur que si tu te prépares, tu oublies d’expliquer ou tu n’expliques pas tout.

Je sais pas pourquoi, j’étais persuadé que c’était ce soir, du coup j’ai loupé ): je viens de regarder la rediff. Le format est assez intéressant. C’est vrai que parfois, tu as perdu un peu de temps à essayer de comprendre ce que faisait la fonction de base, mais ça n’a pas gêné outre mesure. Petite frustration cependant, le fait de ne pas avoir été « jusqu’au bout ». d: Après, je peux comprendre que faire passer les tests peut demander un temps non négligeable pour un gain pas forcément énorme (d’autant qu’ils ont l’air d’être assez lourds).

J’en redemande !

Quand tu dis autre chose que le python, tu penses au Javascript ?

C’est surtout qu’une heure de stream c’est long.

J’ai uploadé une bonne version du live sur youtube, je partagerai le lien ici dès que le "traitement" que fait youtube derrière est terminé !

J’aurais continué jusqu’aux tests si on n’avait pas atteint 1h, je pense. Là je commençais à fatiguer un peu, et je pense que les participants aussi.

Oui !

• Replay Twitch : https://www.twitch.tv/videos/159307083 Vous pouvez sauter jusqu’à 01:47, c’est là que ça commence.
• Replay Youtube : https://www.youtube.com/watch?v=JowvwdiiIOk

J’ai attrapé le truc en vol et j’ai loupé la fin mais c’était sympa !

À renouveler.

C’était sympa dans l’ensemble. J’ai bien aimé le rythme, les explications, et la diction qui était bonne.

Il m’a fallu du temps pour réussir à coordonner mes pensées en gardant un oeil sur le chat. C’est pas facile, je me retrouve vite déconcentré par le chat, perdre ma pensée courante, et ça c’est pas bon.

Ouai, un peu au début mais franchement après, ça marchait mieux. Question d’habitude ?

Prochaine fois je devrais peut-être me préparer un petit peu plus. Là il m’a fallu pas mal de temps pour comprendre qu’est-ce qui est quoi. C’est la preuve que ce refactoring était nécessaire : le code original était très opaque notamment parce que le nommage des variables était assez mauvais.

Je suis tout à fait d’accord avec toi, le code était pas clair et les variables était super mal nommés, je pense que ça joue énormément sur le temps de compréhension. Un peu plus de préparation, pourquoi pas. En tant que spectateur, y’a pas de moment ou je me suis dit, à tiens, j’ai pigé ce bout de code avant lui donc j’ai jamais vraiment attendu. Pour moi, c’était pas choquant.

Je ne sais pas à quel point je m’exprimais clairement ou je marmonnais des demi-phrases en mode stream of consciousness.

Pas eu cette impression ou en tous cas j’ai pas plus remarqué.

J’aurais continué jusqu’aux tests si on n’avait pas atteint 1h, je pense. Là je commençais à fatiguer un peu, et je pense que les participants aussi.

Pas plus d’une heure, sur ce rythme là sinon c’est trop.

Débugger un truc en live / résoudre un petit ticket. Implémenter une petite fonctionnalité en live.

Ouai, c’est des bonnes idées.

Mettre en prod en live ?

Tu veux dire, présenter l’architecture applicative et les scripts de mise en prod ou vraiment la checklist de mise en prod ?

J’avais pensé à une install party zds, à voir. Expliquer l’installation et les images docker.

Peut-être que pour aider à la comprehension, avant de refacto, montrer un peu les tests unitaires associés aux lignes de codes à refacto, parfois ça aide à comprendre ce que fait la fonction. Je sais pas si on avait des tests unitaires ou seulement des tests d’intégration pour cette fonction. Je suis pas allé checker.

Edit: test auto

Je ne sais pas à quel point je m’exprimais clairement ou je marmonnais des demi-phrases en mode stream of consciousness.

J’ai globalement réussit à comprendre ce que tu faisait alors que je ne sais quasiment pas programmer en python. Donc je pense que c’était plutôt clair.