Michael Jackson

A stranger in MoSCoW

MoSCoW - Théorie

Technique permettant  de prioriser les besoins / exigences / définir un Minimum Viable Product

• M : must have this
  • Vital : doit être fait
• S : should have this if at all possible
  • Essentiel : dans la mesure du possible
• C : could have this if it does not affect anything else
  • Confort : pourrait être fait dans la mesure où cela n'a pas d'impact sur les autres tâches.
• W : won't have this time but would like in the future
  • Luxe : ne sera pas fait cette fois (contrainte budget)

MoSCoW - Exemple

Pour un outil de gestion des tâches :

1. M : Les utilisateurs se connectent à l'outil
2. S : Les utilisateurs récupérent un nouveau mot de passe par email
3. M : Les utilisateurs créaient des tâches
4. C : L'ajout de tâche se fait par email
5. W : Si la demande contient une url, elle devient cliquable

KISS

I was made to coding you

KISS - Théorie

C'est un principe de conception utilisable (aéronautique, journalisme, ...)

• K : Keep
• I : It
• S : Simple
• S : Stupid                                                                                                                                    

La complexité est une source :

• de coûts de conception et de maintenance,                                                           
• potentielle d'erreurs.

En conception technique :

• Il faut maîtriser une version simple avant de vouloir optimiser.

En conception fonctionnelle :

• Plus le produit est simple, plus l'utilisateur le maîtrisera... Il faut parfois faire des sacrifices.

KISS - Exemple

• Les multiples ne doivent pas être utilisés sans nécessité
  • Guillaume Ockham
• La simplicité est la sophistication suprême
  • Léonard de Vinci (Code)
• Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher
  • Antoine de Saint-Exupéry
• Pourquoi faire simple quand on peut faire compliqué ?
  • Shadock (Oups ! C'est l'inverse.)

America

Worse Is Better with no name

Worse is Better - Théorie

• Simplicité
  • La conception doit être simple
• Exactitude
  • La conception doit être correcte dans tous les aspects visibles
• Cohérence / Consistante
  • La conception ne doit pas être trop incohérente. La cohérence peut être sacrifié pour la simplicité. Il est préférable d'abandonner les parties concernées.
• Exhaustivité
  • La conception doit couvrir les situations importantes et/ou pratiques. Tous les cas raisonnablement prévisibles doivent être couvert. L'exhausitivité peut être sacrifié en faveur de toutes autres qualité.
  • Les critères précédents ont permis la création du C et d'Unix

Worse is Better v MIT - Clash

• Simplicité
  • L'interface est plus importante que la mise en oeuvre.
• Exactitude
  • L'inexactitude est interdite.
• Cohérence / Consistante
  • La conception doit être cohérente.
• Exhaustivité
  • La simplicité n'est pas un argument pour réduire les autres facteurs de qualité !
• Le MIT est plus radicale !

La Roux

No Silver Bullet Proof

No Silver Bullet - Théorie

• En résumé, il n'y a pas de technologies miracles qui permet
  • d'augmenter la productivité
  • diminuer le nombre de bugs
• Les facteurs d'echec dans les développements, c'est les :
  • difficultés accidentelles (language de programmation, système laborieux, ...)
    • correction : usage de l'objet, de framework...
  • difficultés essentielles (lié à la création d'un produit)
    • correction : création d'ensemble unitaires
• Remise en cause du mois-homme, ...

Metal Gear

SOLID Theme

SOLID - Théorie

• S : [SRP] : Single Responsibility Principle
  • Une classe n'a qu'une seule responsabilité
• O : [OCP] : Open/Closed Principle
  • Les entités doivent être ouvertes à l'extension mais fermées à la modification
• L : [LSP] : Liskov Subtitution Principle / Design by Contract
  • Les objects doivent être remplaçables par leurs enfants sans alteration du logiciel
• I : [ISP] : Interface Segregation Principle

  • Plusieurs interfaces clients spécifiques sont mieux qu'une générale qui gère tout

• D : [DIP] : Dependency Inversion Principle

  • Il faut dépendre des abstractions et non des implémentations (Inversion des dépendances)

SOLID - Théorie / Exemple

S : [SRP] : Single Responsibility Principle

• Chaque classe est responsable d'une seule partie fonctionnels
• Exemple :
  • Une classe / un module qui compile des informations et permet de l'afficher
    • Le jour où l'on souhaite modifier le format d'affichage html, json, xml, pdf...
    • On va mettre les mains dans du code qui permet aussi de collecter et d'aggreger les informations.
    • Donc il y a un danger de regression.

SOLID - Théorie / Exemple

O : [OCP] : Open/Close Responsible

• Une classe doit être
  • ouverte à l'extension
    • capacité à être étendue
  • fermée à la modification
    • modifiable uniquement par extension
• Une fois qu'une classe a été définie et est utilisée
  • Elle ne peut plus être modifiée
  • Elle peut être qu'étendue
• Cela force l'usage de l'abstraction et du polymorphisme                               

SOLID - Théorie / Exemple

L : [LSP] : Liskov Substitution Principle

• C'est lié à la programmation par Contrat
  • Les traitements sont définis par des règles / assertions.
  • Les règles forment un contrat qui précise les responsabilités entre le client et le fournisseur d'un morceau de code.
    • On ne peut pas avoir avoir une sous-classe avec des préconditions plus fortes que celles de sa superclasse ;
    • On ne peut pas avoir une sous-classe avec des postconditions plus faibles que celles de sa superclasse.
• Version Maths : 
  • Si q(x) est une propriété démontrable pour tout objet x de type T ,
  • alors est q(y) vraie pour tout objet y de type S
  • tel que S est un sous-type de T.     
• Un carré qui dérive d'un rectangle casse le principe LSP.                     

SOLID - Théorie / Exemple

I : [ISP] : Interface Segregation Principle

• Aucun client ne doit être contraint à dépendre de méthodes, s'il ne les utilise pas. 
• ISP divise les grandes interfaces en plus petites et plus spécifiques, afin que les clients connaissent uniquement les méthodes qui leur sont interessantes.
• On peut assimiler ces interfaces à des interfaces ayant un rôle.
• Le but est de maintenir un système découplé et donc plus facile à refactoriser, à changer et à redéployer.                

SOLID - Théorie / Exemple

D : [DIP] : Dependency Inversion Principle

• Le principe renvoie à une forme spécifique de découplage.
• Ce principe stipule :
  • Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d'abstractions.
  • Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.
• Ce principe inverse :
  • la façon dont certaines personnes pensent la conception orientée objet. En disant que les deux objets de haut et de faible niveau doivent dépendre de la même abstraction.        

Pentakill, League of Legends

Deathfire GRASP 

[EN COURS]

GRASP - Théorie

General Responsibility Assignment Software Patterns (Principles)

• C'est ensemble de lignes directrices pour attribuer la responsabilité  des classes et des objets dans la conception orientée objet.
• Les différents modèles et principes utilisés :
  • sont : contrôleur, créateur, indirection, expertise, haut de cohésion, faible couplage, polymorphisme, variations protégées, et fabrication pure.
  • répondent à certains problèmes communs que l'on rencontre dans presque tous les cas.
  • Ces techniques n'ont pas été inventé pour créer de nouvelles façons de travailler, mais à mieux documenter, normaliser et à tester.
• Ainsi, le GRASP est vraiment un ensemble d'outils qui aide à l'apprentissage et permet une conception logiciels orientés objet.
• Lié à la méthode de conception Boundary Control Entity

GRASP - Théorie

• Controller

  • Le patron controller a la responsabilité de traiter avec les événements du système vers une classe (non-ui) qui représente l'ensemble du système

  • C'est le premier objet au-delà de la couche d'interface utilisateur qui reçoit et coordonne («contrôle») le fonctionnement du système.

  • Le contrôleur doit déléguer le travail qui doit être fait par d'autres objets.

GRASP - Théorie

• Creator (Factory)

  • La création d'objet est la chose la plus fondamentale

  • En général, une classe B est responsable de la création d'instances de la classe A si un ou plusieurs points suivants s'appliquent. Les instances de B

    • contiennent des instances de A (ou des aggregats)

    • enregistrent des instances de A

    • utilisent étroitement instances de A

    • disposent de l'information d'initialisation pour instances de A et passent sur la création.

GRASP - Théorie

• High Cohesion
  • La cohésion est un principe de conception informatique définissant un degré d'accord entre les différents éléments d'un module
    • Accidentel : décrivant le niveau le plus faible où le lien entre les différentes méthodes est inexistant (futile)
    • Logique : lorsque les méthodes sont reliées logiquement par un ou plusieurs critères communs
    • Temporel : lorsque les méthodes doivent être appelées au cours de la même période de temps.
    • Procédural : lorsque les méthodes doivent être appelées dans un ordre spécifique.
    • Communicationnel : lorsque les méthodes manipulent le même ensemble spécifique de données.
    • Séquentiel : lorsque les méthodes qui manipulent le même ensemble de données doivent être appelées dans un ordre spécifique.
    • Fonctionnel : réalise le niveau le plus élevé lorsque la classe ou le module est dédié à une seule et unique tâche bien spécifique.

! Anemic Domain Model

Anemic Domain Model

• Cela provient du Domain Model : où les objets du domaine contienne peu ou pas de logique métier
• L'objectif étant de découpler un maximum de choses, il peut être considéré comme un anti-patron
• Les plus
  • Séparation claire entre la logique et les données
  • Fonctionne bien pour des applications simples
  • Les resultats restent dans la logique "stateless", ce qui facilite la maintenabilité
  • Evite un mapping complexe entre les objets et la base de données
  • Cela suit le principe de responsabilité unique [SRP]
• A surveiller
  • L'objet lui même ne connait pas sa validité, car la logique, la validation est stockée à un ou plusieurs endroits
  • Le modèle est moins expressif

Justin Timberlake

DRY me a river

Don't Repeat Yourself

Ne vous répétez pas !

• Eviter la redondance, cela facilite
  • la maintenance
  • la création de tests
  • le debogage
• Bonne pratique
  • s'appuyer sur les générateurs de codes, @annotations, ...                       
  • à appliquer partout :
    • base de données
    • documentation
    • code

  Michael Jackson

YAGNI are you ok ? Smooth Criminal

You Ain't Gonna Need It!

Vous n'en aurez pas besoin !

• La tentation d'écrire du code qui n'est pas nécessaire, mais qui pourrait l'être dans le futur, entraine des inconvénients
• Le temps nécessaire est pris sur l'ajout, le test ou l'amélioration de fonctionnalités immédiatement nécessaires
• Les fonctionnalités supplémentaires
  • doivent être debugguées, documentées, et maintenues
  • imposent des contraintes sur ce qui peut être fait dans le futur,
    • risque de conflit avec une future fonctionnalité nécessaire
  • risquent de ne pas être connus de tous
  • sont difficile à tester, à spécifier
    • donc avec un risque de ne pas fonctionner
  • provoquent des effets boules de neiges
    • ... on ajoute des trucs car la nouvelle fonctionnalité a inspirée

  Eric S. Raymond

The Cathedral and The Bazaar

The Cathedral and The Bazaar

• Tout bon travail commencent par l'éveil de la curiosité des devs

• Les bons devs savent quoi écrire, les meilleurs savent quoi réécrire ou réutiliser

• Prevoir de jeter une version à la poubelle, de toute façon, c'est ce qui va se passer

• Si vous avez la bonne attitude, les problèmes interessant vous trouveront

• Quand vous perdez de l'intérêt pour un développement, votre dernier devoir est de le confier à un successeur compétent

• Traiter vos utilisateurs comme des partenaires c'est la manière la plus rapide d'améliorer votre code et de corriger avec efficacité

• Déployer au plus tôt, déployer le plus souvent et écoutez vos clients.

The Cathedral and The Bazaar

• Avoir suffisament de développeurs et de béta-testeurs, permet d'identifier les problèmes rapidement et d'avoir une personne avec une solution évidente.

• Avoir une structure de données intelligentes et du code stupide marche mieux que l'inverse

• Si vous traitez vos beta-testeurs comme la plus précieuse des ressources, ils agiront alors comme tel.

• Il faut reconnaitre que vos utilisateurs peuvent avoir de bonnes idées.

• Souvent, le solution les plus frappantes et innovantes viennent du fait que le concept du problème était mauvais

• La fameuse phrase de Saint-Exupéry

The Cathedral and The Bazaar

• Un outil qui s'utilise comme vous le souhaitez c'est bien, un outil qui fait des choses inattendu (au delà de ce qui est prévu)  c'est excellent

• Lorsqu'on écrit une passerelle, il faut modifier le flux d'informations à minima et éviter de jeter des informations (sauf si le bénéficiaire vous y oblige)

• Quand ton langage est loin d'être "turing-complete" alors le sucre syntaxique peut être ton ami

• Un système sécurisé l'est seulement si c'est secret. Prenez garde aux pseudo-secrets

• Pour résoudre un problème intéressant, commencer par trouver le problème qui est intéressant pour vous

• Pourvu que le coordonnateur dispose d'un moyen de communication au moins aussi bon qu'Internet, et sait comment faire face aux  contraintes.