Coder consiste de jongler entre 4 contraintes différentes :

1. Le code source doit fonctionner : doit présenter une solution cohérente des contraintes du système réel.
2. Le code doit résoudre le problème tel que présenté : la demande business n’est peut-être pas correctement formulée, c’est aux développeur·euse·s d'y apporter une solution adaptée pour satisfaire les besoins réels du client.
3. Le code doit s’insérer proprement à la solution actuelle : il ne peut ni fragiliser, ni rigidifier, ni opacifier ce système.
4. Le code doit être lisible par les autres développeur·euse·s, c’est-à-dire lisible, maintenable et montrer vos intentions.

Quand nous sommes distrait·e·s par un problème, quel qu’il soit, il est préférable de s’attarder à celui-ci ou, du moins, lui allouer un peu de temps. Il vaut toujours mieux prendre une heure pour vous calmer plutôt que persister à écrire du code que vous seriez obligé·e de jeter ou de vivre avec.

On peut parfois être interrompu·e par une ou plusieurs personnes. Il n’est pas professionnel d’être grossier·ère.

• Lorsque nous sommes bloqué·e·s sur un problème, il est préférable de faire appel à un·e partenaire de binôme. En cas d’interruptions, cette personne peut garder le fil de la discussion.
• Lors de TDD, le test actuel incarne le contexte actuel.
• Solution possible : prévoir une plage horaire où vous ne préférez pas être interrompu·e mais prévoyez un moment où votre porte est grande ouverte.

Si on reste assis·e devant notre écran, sans savoir quoi faire :

• Se détendre (aller marcher un peu, boire un café, etc)
• Le manque de sommeil est une cause possible
• Un problème nous trotte dans la tête

Le développement n’est pas un sprint ; c’est un marathon. Ménagez vos ressources.

Lorsque nous insistons alors que nous sommes fatigué·e·s, le seul effet qu’on peut avoir est d’accroître la fatigue. Arrêtez les frais dès que vous êtes fatigué·e·.

Quand on est bloqué·e et fatigué·e·s, faites une pause. Découvrez vos rythmes de créativité et d’éveil ; il vaut mieux travailler avec eux et non contre eux.

On finira tou·te·s par être en retard sur nos estimations.

• Soyez transparent·e : il n’y a rien de pire que de continuer à rassurer quelqu’un qu’on sera dans les temps.
• Montrez régulièrement votre progression.
• Établissez trois dates : au mieux (optimiste), une date nominale (réaliste) et date au pire (pessimiste).
• Soyez honnête avec ces dates.
• Mettez les à jour quotidiennement.
• Ne laissez par les autres commencer à espérer.

Parfois, on peut être amené·e à faire des heures supplémentaires. Mais lorsque c’est pour résoudre un problème de timing sur le projet, on en peut pas travailler davantage que possible et nous ne tiendrons pas ce régime de surcharge plus de deux ou trois semaines.

Si le management nous demande de faire des heures supplémentaires, n’acceptez que si ces trois conditions sont réunies:

1. Si vous pouvez personnellement l’accepter
2. Si c’est pour une durée limitée d’environ deux semaines
3. Si votre team lead a prévu un plan de secours au cas où ce travail supplémentaire ne donnerait pas les résultats escomptés

Lorsqu'une personne commence à dire « j’ai terminé ce ticket » et qu’il ne l’est pas ; c’est contagieux ! Le management va penser que tout va bien et personne n'aura vu le train du travail non-achevé fonçant sur elleux lors de la livraison du projet.

En tant que développeur·euse, il faut toujours se tenir prêt·e à aider nos collègues. Il en va de notre honneur d’accepter cette demande (dans les limites du raisonnable ; l’objectif n’est pas d’absorber le sprint de notre collègue mais bien de le débloquer).

Aussi, on peut avoir besoin d’aide. Si la personne qui a accepté de vous aider ne le fait pas vraiment, proposez d’en rester là et remerciez-là.

1. Vous ne vous autorisez pas à écrire du code de production tant que vous n’avez pas écrit d’abord un test unitaire qui doit évidemment échouer.
2. Vous ne vous autoriserez pas à écrire plus de code de test unitaire que nécessaire pour provoquer l’échec de compilation.
3. Vous ne vous autoriserez pas à écrire plus de code de production que celui qui permet au final de réussir le test unitaire qui échouait.

Si les tests réussissent, on peut être certain·e·s qui le refactoring du code de production n’a pas généré d’effet indésirables (mal fonctionnement, effets de bord,…).

Un taux de coverage d’au moins 90% est conseillé. La plupart des outils qui calculent ce taux ne prennent pas en compte les cas d’exceptions (try…catch) en compte.

Lorsqu’on ne fait pas de TDD, on peut être frileux·se de refactorer une partie du code de peur de rendre l’ensemble non opérationnel. Un code propre est plus facile à relire, à maintenir et à enrichir.

• La lecture des tests permet de savoir comment chaque élément du système fonctionne et comment l’exploiter
• Les test sont la documentation qui décrivent la conception du système
• Les tests sont écrit dans un langage qui quiconque devra comprend

Il est nécessaire de concevoir les tests avant d’écrire le code. Cela permet de concevoir des fonctions qui ne feront pas appels à d’autres fonctions. Écrire les tests avant de rédiger le code nous oblige à concevoir une bonne approche de conception.

Si on veut écrire les tests après avoir écrit le code, on peut avoir une masse informe et difficile à tester (fonctions faisant appel à d’autres fonctions, etc).

Deux approches différentes :

• Approche offensive : écrire les tests avant de rédiger le code : tests précis, informatifs
• Approche défensive : les tests ne peuvent être écrit que par une personne connaissant le système et sait déjà comment le problème à été résolu. On adapte alors les tests au code et non l'inverse.

Faire du TDD favorise la certitude, le courage (de refactorer), la réduction de cas non-gérés, la qualité de la conception, du code et enfin, de la documentation.

Le TDD n’est pas une formule magique. Faire des tests s’apprend : il y a de forte chance qu’avant de faire du code de production incorrect, nous fassions de mauvais tests.

Selon l’auteur, l’entraînement fait partie intégrante du métier pour un développeur professionnel. L’objectif est d’être capable de détecter une grande variété de problèmes et de savoir comment y réagir.

Dans les Arts Martiaux, l’entraînement solitaire s’appelle un kata. Il s’agit du même principe pour le développement ; un problème qu’on répète jusqu'à ce qu’il soit résolu. L’intérêt n’est pas de connaître comment résoudre ce problème en dormant mais bien à prendre des habitudes nous permettant d'être plus productif·e.

La répétition permet d'automatiser les mouvements et les rendre instinctifs pour qu’ils puissent être déclenchés le moment opportun.

• La résolution de l’exercice n’est pas l’objectif
• L’objectif est la mise en pratique des mouvements et des décisions
• Apprendre les raccourcis clavier et à maîtriser nos outils

Quelques sources & katas (tous en anglais) :

• Codekata.com
• Codingdojo.org
• Boyling game kata
• Prime factors
• Word Wrap
• Code Katas with PHPUnit

Un Waza est l’équivalent d’un Kata mais en duo.

• Les deux partenaires choississent un kata ou un problème simple à résoudre
• Læ premier·ère rédige le test unitaire, læ second·e rédige le code qui doit réussir le test
• Échange des rôles

Les développeur·euse·s pratiquent et évaluent les capacités de frappe de touche et l’utilisation de la souris ainsi que le degré de perfection du kata.

On peut également s’imposer des contraintes, par exemple :

• Contrainte de performance
• Occupation mémoire
• Etc

Le jeu en devient ainsi enthousiasmant et amusant.

Le randori est un combat libre. Il se fait en groupe de plusieurs personnes.

• Une première personne écrit un test et puis s’éloigne
• La personne suivante se charge de la réussite du test et écrit le test suivant

Les participants peuvent être assis autour d’une table ou se promener dans la pièce. On élargit ainsi notre horizon technique tout en renforçant nos compétences.

Nombreuses sont les professionnels qui manque de diversité dans le genre de problème que nous savons résoudre. Les employeurs obligent souvent à n’utiliser qu'un seul langage, qu’une seule plateforme et qu’un seul domaine métier. Sans entraînement, on risque d'appauvrir notre CV et notre état d’esprit.

Une solution serait de contribuer à l’open source dans un langage que nous ne connaissons pas, par exemple un·e dev Javascript peut participer à un projet Python, un·e dev C# peut participer à un projet Java, etc.

L’employeur n’est pas censé financer le maintien de nos compétences dans un état optimal. Ce n’est pas son rôle ; nous ne sommes pas payés pour nous entraîner.

On s'entraîne alors sur notre temps personnel, potentiellement dans d’autres langages pour rester polyglotte.

Tous les professionnels s’entraînent pour pouvoir fournir la meilleure prestation possible. On s’entraîne pour pouvoir être payé·e et être payé·e correctement.