Alors lui, il passe directement dans mes favoris pour plus tard !

Intéressant article qui donne un cadre pour prendre le temps de bien préparer ses dev ! ça rejoint le fait de "bien préparer" ses user story en environnement Scrum... C'est vrai que c'est difficile de prendre ce temps, et pourtant à chaque fois qu'on le fait bien on se rend compte à quel point c'est primordial et comme ça fait gagner du temps !!!

Quelque chose m'a interpelé ceci dit : l'article sacralise presque l'état de "Flow". Or je suis en train de lire "The clean coder" de Bob Martin et j'ai été surpris de voir qu'il considère cet état comme à bannir.
Son argument est qu'en gros, dans cet état on se sent "tout puissant", tout fait sens, et par conséquent on ne peut pas produire du code "propre" (au sens où il l'entend). Et c'est vrai par mon expérience que j'ai eu tendance à écrire beaucoup de code en état de "Flow", qui était très clair dans ma tête au moment de l'écriture, mais qui s'est avéré vraiment complexe à comprendre une fois qu'on y revient la tête plus froide...
Il me semble que la méthode TDD (que je suis en train d'apprendre) empêche de se retrouver en "Flow" non ? Puisqu'on passe en permanence du test au code, on "s’interrompt" tout le temps finalement ?...

Retour intéressant !
Au contraire, je trouve que le TDD me facilite l'accès au flow : je peux aller très vite sans m'inquiéter de casser quelque chose.
Pour ça il faut un feedback rapide des tests.
Après j'ai le sentiment que le TDD t'amène à mieux structurer ton code.
En tout cas, je n'ai pas vraiment vécu le syndrome que tu décris...
Le flow ne m'apporte pas un sentiment de toute puissance, mais un état d'efficacité qui est gratifiant pour les neurones. Ma productivité s'en trouve décuplée.

"Quand vous êtes en état de flow, le code que vous produisez est d’une qualité exceptionnelle, car votre cerveau a concentré 100% de ses ressources sur le sujet."
Du coup, tu n'es pas d'accord avec cet extrait ?

Je ne sais pas trop encore quoi en penser. Concernant la pratique du tdd. je pebse que le plan d'action peut etre utile pour s'assurer qu'on a bien pensé un minimum lee test d'acceptation cible de l'exigence.
je ne suis pas sûr celà dit que Cette approche puisse être generalisable.
je me vois bien l'utiliser dans le cadre de pet projects. pour m'aider a cadrer mon travail.

j'aime bien l'idée d'essayer de mieux comprendre l'état de flow. finalement de mieux se connaître soi même. et d'essayer de comprendre comment mettre en place les conditions qui amènent a être productif. ca peut être un bon moyen de s'économiser.

- "Du coup, tu n'es pas d'accord avec cet extrait ?"
Tout dépend de ce qu'on appelle "qualité exceptionnelle". ;-)
Les exemples de code auxquels je pense issu de mon état de flow n'était ni exempts de bug ni facilement compréhensibles (ni bien testés). Par contre ils mettaient en place des architectures , des concepts et montraient les choix techniques que j'avais pris (dans le but d'embarquer les autres dev dans la même direction). C''est un état qui me permettait d'avoir "tout en tête" en faisant des "gros dev"...et j'avais toujours l'impression d'avoir fait du "bon code".
J'ai beaucoup changé ma façon de développer depuis quelques mois (il n'est jamais trop tard pour se réinventer ^^), notamment grâce à "artisan développeur" ;-) ou le "clean code", mais du coup je suis devenu assez critique envers mon ancien moi ;-)

Pour le TDD, je pense que je ne suis pas encore assez "fluent" et que la méthode elle-même m'oblige encore à beaucoup réfléchir "consciemment" sur ce que je suis en train de faire.

Retour intéressant. Je suis heureux qu’artisan développeur t’ait aidé sur ton chemin.
Clairement : le TDD donne un cadre, une démarche qui protège.
Après, l’ultime c’est de faire ça à deux.
Quand tu es dans le flow en binôme, il se passe des choses très surprenantes. J’ai rarement vécu ça dans ma vie, et c’est bien dommage : on entre dans une autre dimension.

Une chose qu'on peut retenir parmi d'autres est qu'on souhaite réduire ou supprimer les changements de contexte et interruptions.

C'est un sujet récurrent des articles de blog, podcasts et vidéos youtube de Sebastian Daschner.

www.sebastian-daschner.com