Design ?

C'est la façon de structurer son code à moindre coût.
Le design trouve son intérêt seulement si le code serait amené à changer en raison du contexte métier.

Pourquoi s'intéresser au design?

1. Si l'application change, le développeur a intérêt alors à mobiliser son énergie sur la conception de son code car tout l'enjeu est de la faire évoluer sereinement à un coût raisonnable.
   + Notion de longévité
   + Coût financier
   + Coût humain
2. Pour l'entreprise, le design représente l'enjeu stratégique de pérennité de ses actifs immatériels.
3. Pour les développeurs, c'est la source de motivation, l'épanouissement personnel et professionnel.

Tout change tout le temps

• Loi immuable (ce qui ne change jamais = c'est ce qui change tout le temps)
• Le monde dans lequel on vit s'accélère (time to market de + en + fréquent)

C'est pourquoi on doit sans cesse

• faire des feed-back (la vérité est dans le code sur le terrain)

• trouver les moyens pour s'adapter aux changements et travailler plus vite avec agilité pour atteindre nos objectifs.

• responsabiliser les développeurs et les sensibiliser à l'utilisation des bonnes pratiques de codage

Repousser les décisions - OVERDESIGN

Quand ?

• Effet du mikado : design insuffisant (une modification du code a un effet non contrôlé dans le reste du code)
• C'est pas prévu : beaucoup trop de designs

Dans l'approche classique de gestion de projets, repousser les décisions entraîne des surcoûts à cause du fait qu'on a cette tendance à vouloir tout prévoir à l'avance : BUFD (Big Up Front Design)

De plus, anticiper l'avenir  = dons anormaux et qui repose sur le fait de :

• l'héritage en cascade
• l'héritage du monde réel

Héritage en cascade:

La gestion très linéaire étape par étape a un impact très important en cas de changement dans le projet et risque de coûter très cher. Par conséquent, on ne peut pas se permettre de repousser les décisions !

Héritage du monde réel:

Dans l'approche classique du cycle V et en pratique, on a tout intérêt à anticiper à l'avance car cela coûte cher de différer les décisions.

En revanche, la méthode agile permet de minimiser ce coût car on n'a pas le problème de prise de décisions en amont. L'écart de coût à un instant t est réduit et va nous permettre de différer plus longtemps les décisions.

Le graphique suivant nous permet de comparer les écarts de coûts ∆1 et ∆2 respectivement pour l'approche classique du cycle v et l'approche agile entre deux instants t1 et t2

3 ième principe: Affûter ses techniques

"Comme tout effort humain, la conception logicielle requiert de la technique, un travail dur, de l'inspiration technique profonde."
--- Rebecca Wires Brock ---

Techniques profondes:

• Conception Orienté Objet
• Responsability Driven Design
• Design Pattern
• Refactoring
• Test First

Les compétences de surface comme la connaissance des Frameworks ne suffit pas pour concevoir du code durable.

Une multitude manières de faire du code durable

L'enjeu est de réaliser quelque chose qui marche et non pas que que chose de jolie.

A. La conception est art. Un art de :

• prendre des décisions stratégiques et impactantes 
  - Si la prise de décision se fait trop tôt, il y aura un risque de se retrouver coincé avec du code trop alourdi
  - Si trop tard, risque de dette et de perdre de la maîtrise
• livrer de la valeur à court terme
• faire évoluer à long terme

B. Pas de dogme

Les règles sont connues et il faut savoir les interpréter via de la pratique

Les règles sont établies pour êtres dépassées à condition de les respecter et de les maîtriser. 

Il n'y a pas de règles absolues, tout est question de compromis:
+ La bonne nouvelle c'est qu'on a la liberté de s'exprimer
- La mauvaise c'est qu'on ne sait jamais si on a pris ou pas la bonne décision à priori(on ne le saura peut-être que plus tard, à l'issue des résultats que l'on obtiendra au fur et à mesure ... )

C. Tout est question de compromis

Compromis permanent:

Il s'agit de concentrer toute son énergie sur les décisions qu'on va prendre maintenant et de préparer l'avenir. Autrement dit, se concentrer sur ce qui marche bien aujourd'hui et qui restera évolutif dans le futur ...

Préparer l'avenir ne veut pas dire anticiper l'avenir (au risque de faire qqchose de lourd aujourd'hui) mais plutôt être souple aujourd'hui et évolutif demain.

Faire vite et bien c'est possible mais il faut avoir de la technique et de la maîtrise pour cela.

D. Qualité de code et dette technique

1. Dette = "frein à l'évolution"

   Mais la dette peut être un levier pour amener au niveau suivant à condition d'être capable de la maîtriser et de la rembourser au fur et à mesure. Si on n'est pas sûr ou qu'on a peur d'être dépassé, mieux vaut ne pas emprunter !

2. Qualité du code
   "C'est la capacité de rester évolutif à moindre coût" -- Sandy Metz --

   On mesure la qualité du code via l'indicateur WTF (Works That Frustrate) / minute.
   L'ensemble des mesures (ex. la couverture de code entre autre) est un indicateur sur la qualité intrinsèque dans le design du code. On ne peut pas tout mesurer mais ça permet de rester lucide et de savoir où on va.

3. Question de contexte
   Un bon design c'est:
   + Design clair et compréhensible par l'ensemble de l'équipe
   + Design permettant de faire évoluer une application
   + Le bon design du code est aussi lié à une équipe d'où l'importance du binômage qui est une bonne méthode de transmission du savoir.