Guide de survie du Craft

Abécédaire des concepts essentiels

Julien Lenormand

Ca va bientôt commencer

Vous pouvez prendre le temps de méditer votre réponse à quelques questions :

* Avez-vous appris quelque chose cette semaine sur votre métier ?
  Et depuis vos débuts en informatique ?
* Quels sont les inconvénients des IDE ?
  De Git ?
  De GitHub ?
  De Python ?

.

.

.

.

.

.

.

.

.

.

.

.

Introduction

  • projets scolaires
  • premier projet pro
  • interrogations
  • Agile bullshit ?
  • introduction

Mes 26 10 concepts-clés du Craft

A comme Apprentissage continu

  • Depuis l’école
  • Tous les jours, encore aujourd’hui
  • curiosité
  • objectif
  • veille
  • questions dans des communautés
  • en groupe (comme en ce moment)
  • pratique délibérée et répétée
  • expérience et inter-génération
  • apprentissage et compagnonnage

B comme Best Practices

Y-a-t’il des best practices ?

  • Quelles bonnes raisons de ne pas utiliser ?
    • IDE
    • Git
    • GitHub
    • Python
  • Contexte !
  • Discussion : identification et partage

C comme Clean Code

C comme Code Review

  • Qui sait comment faire du “code Clean” ?
  • Blague à part, qui a lu le livre d’Uncle Bob (Robert C. Martin) ?
    • (qui est 100% d’accord avec ce qui est dedans ?)
  • Pour qui on code ?
    • les machines, accidentellement
    • les humains, surtout

    • Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler

  • Code smells (cf Best Practices et Code Review)
  • mesure de la qualité du code : WTF/minute
  • boy scout rule :

    • Always leave the code you’re editing a little better than you found it – Uncle Bob (Robert C. Martin)

D comme Design Patterns

  • Design Patterns: Elements of Reusable Object-Oriented Software – Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, 1994

  • mettre des carrés dans des ronds
  • appeler un chat un chat
  • des outils comme les autres, utiles à connaître
  • les outils ne sont pas des solutions

E comme Euh j’ai pas le temps …

K comme KISS

Keep It Simple, Stupid

  • faire le + simple possible !
  • faire + simple encore !!
  • et ensuite complexifier si besoin …

  • Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. – peut-être Brian Kernighan

    • Débugger est 2 fois + difficile que d’écrire le code. Donc si vous écrivez le code le plus intelligemment possible, vous n’êtes par définition pas assez intelligent pour le débugger.

  • Avoid premature optimization – Donald Knuth (citation hors-contexte)

  • Livrer de la valeur plutôt que du code

L comme Là j’ai vraiment pas le temps de faire tout l’alphabet !

P comme Pair-programming

Pair-prog, Mob-prog, Software Teaming, …

  • Deux cerveaux valent mieux qu’un
  • Collective Ownership, Bus Factor
  • Dojo et Kata
    • dans votre entreprise ?
    • meetups dans votre ville (Grenoble/Lyon/…)

R comme Refactoring

  • j’y reviens plus tard !

S comme SOLID

.

.

.

.

.

.

  • SRP : Single Responsibility Principle
  • OCP : Open-Closed Principle
  • LSP : Liskov Substitution Principle
  • ISP : Interface Segregation Principle
  • DIP : Dependency Inversion Principle
  • ne garder que SRP et DIP ?

T comme Test

  • Qui fait de l’escalade ?
    • qui fait du bloc ?
    • qui fait du free solo ?
  • Qui écrit du code sans test ?

T comme Test-Driven Development

  • n’est pas “LA SOLUTION ULTIME A TOUS LES PROBLEMES !!!1!!”
  • mais peut aider à certains objectifs :
    • avoir une visibilité claire sur l’avancement (ce qui marche ou pas)
    • avoir une “doc” de l’utilisation de comment utiliser le code
    • avoir du code testable
    • faire des “petits pas”
    • avoir du feedback rapide
    • être sûr d’avoir des tests à la fin
    • …

T surtout comme Test

  • les tests sont essentiels à un projet :
    • pouvoir livrer avec confiance que ce qui est ajouté fonctionne
    • pouvoir livrer avec confiance que ce qui n’a pas changé fonctionne encore
    • pouvoir changer le code –> refactoring
    • pouvoir survivre à un changement d’équipe
  • automatiques ou manuels, ça peut dépendre
  • mais de bonne qualité : clairs, rapides, fiables, …
  • comment faire ?
    • apprendre !

R comme Refactoring

  • Quelle définition de “refactoring” ?
    • un changement sans impact sur le fonctionnel ?
  • des techniques à maîtriser
  • garder la maîtrise du code
  • une symbiose avec les tests

V comme Valeurs

  • l’Agile n’a pas fonctionné pour les devs (cf ma conf)
  • le Craft en tant que mouvement réactionnaire
  • des valeurs + claires ?
  • Raising the bar
  • aspiring
  • by practicing and helping others learn
  • values :
    • well-crafted software
    • steadily adding value
    • community of professionals
    • productive partnerships

Crédits

Images :

  • exercice de catmatic
  • toutes les sources citées au fil de la présentation
  • livre “Software Craft” chez Dunod

Julien Lenormand

Dev / DevOps / Craft / Talk

LinkedIn/julien-lenormand

Questions ?

ROTI
slides

Z comme ZzzzzZzzZzzzzzzZz

Z comme Zen