“N’écrivez jamaisun mot court si unparagraphe entier   améliore les — Senior Business Consultant IBM
“N’écrivez jamaisun mot long si un  mot court fait    l’affaire.”     — George Orwell
README — un fichier nommé plaisir —                     http://j.mp/R6qnyyParis Web 2012       http://j.mp/R6qnyy
READ/MEParis Web 2012
Thomas Parisot           Développeur Web expérimenté           @oncletom           http://case.oncle-tom.net           htt...
.js      — node.js, Chrome —Résumé des 12 derniers mois
€                /     — le cash a été brûlé —Résumé des 12 derniers mois
Résumé des 12 derniers mois
Ateliers Paris Web 2011
Dialoguer       — parler + écouter —Ateliers Paris Web 2011
:-(Ce qu’on ne voulait pas
Specs    /Ce qu’on ne voulait pas
///          SpecsCe qu’on ne voulait pas
:-)Ce qu’on voulait
KISSCe qu’on voulait
Donc …
Quoi ?          — à quoi ça sert —Recette
Comment ?— install/update/dev/deploy … —Recette
Comment ?          — ça s’utilise —Recette
Succès#WIN
Github#WIN
Github
1 er#WIN
1er élément visible
—         À jour    et/donc/parce que   toujours visible                   —#WIN
Modification en ligne quand on a la flemme
—             0           apprentissage   —#WIN
Des logiciels de rédaction existent déjà
Simple       —   # + * + ** + []()   —#WIN
Rapide —   ça laisse du temps pour causer   —#WIN
Facile       —   pour en discuter   —#WIN
Tester       —   sans tester   —#WIN
Exemples …
Testabilité       —   facilite les tests   —#WIN
… et leurs tests
Compatible       —   TDD, BDD, WTFDD etc.   —#WIN
RDD— Readme Driven Development —Origines
Merci :-)
http://clients.tranches-de-vie.com/index.php/2011/paris-web-2011/1015-ateliers/img-0275http://tom.preston-werner.com/2010/...
README, un fichier nommé plaisir
README, un fichier nommé plaisir
README, un fichier nommé plaisir
README, un fichier nommé plaisir
README, un fichier nommé plaisir
Prochain SlideShare
Chargement dans…5
×

README, un fichier nommé plaisir

2 672 vues

Publié le

Vendredi, mise en production. Vous annoncez à vos proches que pour l'apéro ce soir, c'est mort, vous êtes dé-bor-dé(e).

Un mauvais clic plus tard, le site est mort. Ambiance fin du monde pendant que vos amis s'amusent.

Si vous aviez su que la rédaction du README de votre projet vous aurait permis non seulement de préserver votre apéro sacré, mais en plus de livrer le cœur léger, vous l'auriez sûrement écrit plus tôt.

Avant que le monde ne s'effondre sur lui-même, nous ferons encore mieux : 15 minutes c'est juste ce qu'il faut pour créer un code robuste.

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 672
Sur SlideShare
0
Issues des intégrations
0
Intégrations
839
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • J’ai laissé tomber le mot consultant, ça ne rapproche pas assez des gens\n\n
  • Sur les 12 derniers mois, on n’a fait que du JavaScript.\nEt toujours pas de cancer à force d’utiliser NodeJS.\n
  • On a levé des sous mais tout a été brûlé.\n
  • Mais c’est pas grave, on s’est amusé et on a beaucoup appris.\n
  • \n
  • * atelier Paris Web par Pablo : meilleure qualité dans la parole\n* moins d’écrits, plus de dialogue\n* moins d’écrit, mais davantage qualitatif\n* c’est quoi un écrit qualitatif ?\n* c’est quoi un écrit qualitatif pour un développeur ?\n
  • On était 4, on devait avancer rapidement, pouvoir évoluer rapidement.\n
  • Pas envie de rédiger 40 pages de specs fonctionnelles.Pas envie de rédiger 40 pages de specs techniques.\n
  • On ne voulait pas maintenir toutes ces pages de specs.\n
  • \n
  • On voulait du simple, de l’efficace et qui fonctionne à distance (télétravail oblige).\n
  • Donc on en revient au sujet\n
  • Basique mais permet déjà de mettre le doigt sur les premiers flous artistiques\n
  • \n
  • Le développeur est aussi utilisateur. Il faut pouvoir rentrer dedans sans éplucher tous les fichiers :\n* APIs principales\n* exemples (comment je manipule le code)\n* navigation vers les détails d’API (pratique si volumineux)\n
  • À replacer dans le contexte : 4 dév, télétravail, jalon à 1 ou 2 semaines, priorisation à la journée.\n
  • Outil de travail simple, collaboratif et qu’on *aime*.\n
  • \n
  • Un des premiers éléments visibles, merci Github !\n
  • \n
  • Et puisque visible, on pense plus facilement à le mettre à jour\n
  • \n
  • Rien à apprendre, juste à écrire, et penser\n
  • \n
  • Simple à lire, à écrire.\nSimple d’y mettre du littéral, du code.\nTestait par l’écriture la simplicité et la cohérence des API à développer\n
  • En plus c’est rapide à écrire, avant que le projet ne débute, quand on est encore motivé.\n
  • Et comme c’est plus court, ça se lit plus facilement, se comprend plus facilement, plus facile de parler de ce qui était écrit (car plus facile à lire).\n
  • Les exemples permettent de tester l’écriture des API, et vérifier les incohérences juste à l’œil nu et en discutant.\n\n\n
  • \n
  • Bon point également : ça prépare le terrain de la rédaction des tests unitaires.Autre bon point : on n’est pas obligé de savoir rédiger des tests unitaires, et ça permettra de s’y mettre facilement.\n
  • \n
  • Aucune contrainte sur le type d’organisation du projet, qu’il utilise des tests ou non.\n
  • Tom Preston-Werner qui en parle en août 2010.\n
  • \n
  • Et puisque visible, on pense plus facilement à le mettre à jour\n
  • README, un fichier nommé plaisir

    1. 1. “N’écrivez jamaisun mot court si unparagraphe entier améliore les — Senior Business Consultant IBM
    2. 2. “N’écrivez jamaisun mot long si un mot court fait l’affaire.” — George Orwell
    3. 3. README — un fichier nommé plaisir — http://j.mp/R6qnyyParis Web 2012 http://j.mp/R6qnyy
    4. 4. READ/MEParis Web 2012
    5. 5. Thomas Parisot Développeur Web expérimenté @oncletom http://case.oncle-tom.net http://cyneticmonkey.comabout:me
    6. 6. .js — node.js, Chrome —Résumé des 12 derniers mois
    7. 7. € / — le cash a été brûlé —Résumé des 12 derniers mois
    8. 8. Résumé des 12 derniers mois
    9. 9. Ateliers Paris Web 2011
    10. 10. Dialoguer — parler + écouter —Ateliers Paris Web 2011
    11. 11. :-(Ce qu’on ne voulait pas
    12. 12. Specs /Ce qu’on ne voulait pas
    13. 13. /// SpecsCe qu’on ne voulait pas
    14. 14. :-)Ce qu’on voulait
    15. 15. KISSCe qu’on voulait
    16. 16. Donc …
    17. 17. Quoi ? — à quoi ça sert —Recette
    18. 18. Comment ?— install/update/dev/deploy … —Recette
    19. 19. Comment ? — ça s’utilise —Recette
    20. 20. Succès#WIN
    21. 21. Github#WIN
    22. 22. Github
    23. 23. 1 er#WIN
    24. 24. 1er élément visible
    25. 25. — À jour et/donc/parce que toujours visible —#WIN
    26. 26. Modification en ligne quand on a la flemme
    27. 27. — 0 apprentissage —#WIN
    28. 28. Des logiciels de rédaction existent déjà
    29. 29. Simple — # + * + ** + []() —#WIN
    30. 30. Rapide — ça laisse du temps pour causer —#WIN
    31. 31. Facile — pour en discuter —#WIN
    32. 32. Tester — sans tester —#WIN
    33. 33. Exemples …
    34. 34. Testabilité — facilite les tests —#WIN
    35. 35. … et leurs tests
    36. 36. Compatible — TDD, BDD, WTFDD etc. —#WIN
    37. 37. RDD— Readme Driven Development —Origines
    38. 38. Merci :-)
    39. 39. http://clients.tranches-de-vie.com/index.php/2011/paris-web-2011/1015-ateliers/img-0275http://tom.preston-werner.com/2010/08/23/readme-driven-development.htmlhttp://www.slideshare.net/maetl/readme-driven-development-12783652https://github.com/moonmaster9000/specdown Crédits

    ×