DojoDeveloppement/Lundi10Janvier2005

• LaurentBossavit
• EmmanuelGaillot
• PatricePetit
• BernardNotarianni (fan du Dojo et de Squeak :-) )
• CedricGirard
• AntoineContal
• ChristopheThibaut
• MassoudAlidousty
• HamidSaadna
• GillesDesve
• JeromeDantan?
• ConanDalton

Débrieffing séance /DojoZero

• Difficulté à démarrer / maîtrise des outils
• Solution : produire code en binôme avant la séance dojo pour regarder du code collectivement ?
• Alternance pratique (production) / étude (analyse) ?
• Crainte sur la visibilité en termes de progrès individuels
  • Comment évaluer ? Comment s'auto-évaluer ?
• Meilleure maîtrise de techniques peu familières (ex. récursivité)

C'est quoi du bon code ?

• Y a-t-il des critères absolus ? (Problématique du lectorat --> objectif du dojo = former des bons lecteurs de code ?)
• Moins de code, et plus efficace ?
• Du code que tout le monde télécharge et utilise ?

Dojo s'attache surtout à la composante "forme"

Quid composante "organisation d'équipe" ?

• Complexité algorithmique -- NotationGrandO

J'ai suivi la proposition et j'ai été agréablement surpris du résultat. Autant il est difficile de répondre soi-même sur sa performance globale, autant on peut atteindre une objectivité sereine sur un ensemble de petites questions concrètes. La relecture de l'ensemble des réponses permet ensuite de dégager la performance globale auto-évaluée. Un questionnaire dans cet esprit mais adapté au dojo pourrait-il être une réponse ? -- ac

http://www.notarianni.org/index.php/2005/01/11/dojo_1

En fait, je change d'avis : suite à la série d'articles à laquelle Bernard nous renvoie -- google XP Magazine Designing Better Code + j'ai de la chance -- je pense qu'il serait plus intéressant d'utiliser la prochaine séance du dojo pour faire le même exercice que RonJeffries (rien que ça) avec une revue de code simultanée. Le but serait pour une personne d'écrire les tests et le code au fur et à mesure, et pour les autres de proposer des remaniements améliorant le code et la conception. Et comme je n'ai peur de rien, je veux bien préparer le 'numéro de scène' en ruby ;^)

Les intérêts que je vois :

• ça nous changera du KataDeux, en permettant de considérer un problème plus fonctionnel qu'algorithmique
• cela n'empêche pas d'avoir un feedback sur KataDeux, mais limite ce sujet dans le temps : peut-être 30 minutes en mode FishBowl ?
• ça lance des pistes sur les critères d'évaluation d'un code (pourquoi écrire les choses comme ça plutôt qu'autrement ?)
• ça nous permettra de mieux comprendre les /RèglesDeComptageDePointsAuBowling et de pouvoir briller ensuite en société

Propositions ouvertes à discussion, hein... -- eg.

Chui plutot pour... Mais il me semble comprendre que tu propose de faire du collective programming (un qui tiens le clavier, et 10 qui regardent/commentent) Cela est-il réellement gérable? bon ok, faut essayer pour savoir... -- bn

Je propose effectivement une séance de collective programming, pour reprendre ton expression. C'est vrai que si on est nombreux, ça ne sera peut-être pas idéal. Je remarque quand même qu'on est encore loin des 11 inscrits ;^) Si la taille des effectifs devient trop gênante, on peut canaliser la communication, par exemple sous un format FishBowl. -- eg.

• jeux de cartes (bridge, belotte, tarots?...)
• sports (foot, rugby, tennis, golf?...)
• finances personnelles (gestion de tirelire, gestion de compte, impôts...)
• ...?