Formation Qualité Logicielle

Voici un support de formation Qualité Logicielle qui aborde de nombreux points déjà abordés dans ce blog.

Dilbert by Scott Adams

Dans l'ordre, j'ai choisi de présenter :

1. Les principales mécaniques de Refactoring, sauvagement appelé `Réusinage de code` en français
2. Les fameux principes SOLID
3. Un peu de programmation fonctionnelle avec une courte démonstration de LINQ (un cours entier consacré à LINQ suivra)
4. L'analyse statique de code qui devient très à la mode, notamment grâce au changement de job d'Eric Lippert, l'un des top users de StackOverflow, ancien programmeur sur le compilateur C#, qui travail maintenant pour Coverity, éditeur d'un logiciel d'analyse statique
5. Pour finir, de la programmation par contrat qui en est à ces débuts (façon de parler, c'est juste que ce n'est pas natif C# encore, le principe existe depuis 1985)

Cette présentation est à destination des programmeurs de tout niveaux, que ce soit pour renforcer des connaissances ou pour apprendre à mieux développer.

Pour certains points, il est nécessaire d'avoir des bases en programmation orienté objet tout de même.
La présentation est parsemée d'images et de citations qui je l'espère aide à garder la lecture agréable et pas trop universitaire.

Le MBTI (test de personnalité)

Les tests de personnalité, c'est un peu comme la religion. Il y a les croyants, les non-croyants, et le reste, soit 90% des gens qui n'ont pas vraiment choisi.

J'ai fait récemment le test de personnalité MBTI (Myers Briggs Type Indicator), le plus pratiqué des tests par les RHs du monde entier.

L'idée est de classer les personnes selon 4 critères : Energie, Observation, Choix et Action. Ces 4 critères sont complètement bipolaires, soit vous êtes d'un coté de la barrière, soit de l'autre.

• Energie : soit vous êtes Extraverti : vous tirez votre énergie des personnes qui vous entoure; ou Introverti : vous tirez votre énergie de la solitude
• Observation : soit vous êtes iNtuitifs : vous voyez les choses globalement; ou Sensitif : vous voyez les choses dans leurs détails
• Choix : soit vous êtes logique (Thinking) : vous faites vos choix basé sur des critères précis; ou émotif (Feeling) : vous faits vos choix basé sur vos coups de cœurs
• Action : soit vous êtes structuré (Jugment) : vous préférez les environnements bien établis et stables; ou souple (Perceiving) : vous préférez les environnements organiques, qui changent souvent.

Les axes sont donc E/I, N/S, T/F et J/P. Choisissez bien vos lettres, après on ne peut plus en changer. Enfin, la théorie du test dit qu'on est forcement catégorisé, depuis très jeune, et que quoi qu'il arrive, on conservera toujours notre personnalité de départ tout au long de notre vie (non, on ne devient pas Extraverti, ni Introverti, ou l'est ou on ne l'est pas).

ENFP - La vie est plus belle avec un sourire

Je suis tombé sur ENFP, ce qui fait de moi le Champion (c'est pas moi qui le dit c'est Wikipédia). Cela me donne une bonne raison d'être plutôt du côté croyant que non-croyant !

Ce test est utile si vous vous posez des questions sur votre rapport à votre travail notamment. Peut être que votre personnalité ne correspond pas du tout à votre rôle dans l'entreprise. Dans ce cas, ce test peut vous aider à vous réorienter sur un chemin de carrière plus compatible avec votre personnalité. Une personne de type souple aura du mal dans l'administration, et inversement, quelqu'un de structuré se sentira mal à l'aise en start-up.

Les critiques soulèvent le problème que projeter 7 milliards d'individus dans 16 cases c'est un peu gros. En effet, ce test reste une grosse approximation de la complexité de l'esprit humain. Les approximations n'ont tout de même pas empêché l'homme d'aller sur la lune, donc pourquoi ne pas tenter le coup !

Enfin, sachez que le test MBTI est un test payant, qui doit être fait par un professionnel pour le relire et en discuter avec vous avant de tirer toute conclusion et pouvoir valider votre profil. Si cependant vous êtes ruiné, sachez qu'en cherchant `mbti test` sous google, vous avez de grande chance d'en trouver quand même.

Bientôt les soldes, réchauffez vos neurones

Vous allez dans un magasin avec un bon de réduction de -30%. Vous décidez d'acheter un article à 120€, soldé à -80%, et ô magie, les deux réductions sont cumulables.
Combien va vous coûter l'article au final, et est-il plus intéressant d'appliquer d'abord les -80% puis les -30%, ou bien l'inverse ?

Ceci nous ramène à quelques calculs de pourcentages. Commençons par la base, comment applique-t-on une réduction de -80% ?
Appliquer -80% revient à payer 20% du prix. Il faut trouver le complémentaire de 80% pour arriver à 100%. L'opération est donc 100% - 80% = 20%.


L'article coûte 120€, donc on paye 20% de 120€. Cela revient à l'opération 120 x 0.2. Le plus simple pour faire le calcul est de conserver les chiffres significatifs, ici 12 et 2, et de les multiplier, cela nous donne 24, et ensuite de s'assurer d'avoir un résultat crédible, 24€ semble un chiffre crédible.

Appliquons la deuxième réduction, -30%. Le complément est 70%. Chiffre significatif, 7 * 24 = 168. Rajoutons une virgule au bon endroit pour avoir un résultat crédible, 16.80€.

Que se passe-t-il si on inverse l'ordre des réductions ? Commençons par la réduction de 30% puis celle à 80%.
Première réduction : 70% de 120€, 7 * 12 = 84€. Puis la deuxième, 84 * 2 = 168 = 16.80€, pareil.

L'ordre des réductions n'est pas important, puisqu'on ne fait que multiplier des nombres entre eux, et la multiplication est commutative, a x b = b x a.

Petite démonstration : soit x1 la première réduction, x2 la deuxième réduction et N le prix de départ. Soit R1 le prix final dans le scénario x1 puis x2, et R2 le prix final dans le scénario x2 puis x1.

R1 = (100% - x1).(100%-x2).N

R2 = (100% - x2).(100%-x1).N = (100% - x1).(100%-x2).N = R1

Et au final, R1 = R2, donc l'ordre des réductions n'a pas d'impact sur le résultat.

Cela nous donne aussi la formule pour calculer la réduction totale de deux réductions cumulées. Si je cumule 80% et 30%, quelle est ma réduction finale ?

(100%-30%).(100%-80%) = 70% . 20% = 14%

Je payerai donc 14% du prix au final, soit une réduction de 86%. Et ce quelque soit l'ordre dans lequel j'applique mes réductions.

Vérifions sur l'exemple : 120€ * 14% = 16.80€, le compte est bon!

Le conte de la course d'aviron entre les États-Unis et le Japon

Ce conte nous est rapporté par Debito Arudou, depuis son site www.debito.org, et originalement nommé The tale of the boat race between the us and japan.

Debito aurait reçu ce texte en janvier 1997 d'un étudiant diplômé de UCLA nommé Dave Friedman.

En voici la traduction :

La grande course américaine 

Deux grandes entreprises américaine et japonaise ont décidé de s'engager dans une course d'aviron. Les deux équipes se sont entraînées durement et longtemps pour atteindre leur meilleur niveau. Le jour J, les deux équipes se sentaient prêtes. Les japonais gagnèrent avec 1.5 km d'avance. 

Les américains étaient très déçus par cet échec et le moral était au plus bas. La direction de l'entreprise décida que les raisons de l'échec devait être identifiées. Elle engagea un cabinet de conseil pour étudier le problème et recommander des mesures correctives. 

La conclusion des consultants fut la suivante : les japonais avaient 8 rameurs et 1 barreur. Les américains avaient 1 rameur et 8 barreurs. 

Après une année à étudier le problème, et des millions dépensés, le cabinet de conseil conclut qu'il y avait trop de barreurs, et pas assez de rameurs. 

Le jour de la course approcha et la hiérarchie s'en trouva complètement réorganisée. La nouvelle structure comprenait 4 barreurs principaux; 3 barreurs, 1 par partie : avant, milieu et arrière; et un nouveau système d'évaluation des performances pour inciter le rameur à ramer plus efficacement. 

Les japonais remportèrent la course avec 3 km d'avance. 

A nouveau humilié, l'entreprise américaine renvoya le rameur pour performance insuffisante, et donna un bonus aux managers pour avoir découvert le problème.

L'aléatoire en informatique

Vous savez surement lancer un dé ? Ça vous donne un nombre aléatoire entre 1 et 6. Rien de plus simple dans la réalité que de générer un nombre aléatoire. On utilise beaucoup les dés à 6 faces dans toutes sortes de jeu. On appelle ça un D6. Il existe aussi des dés à 20 faces, des D20, et on monte jusqu'à 100 faces même !

Bref, dans la réalité, on sait faire. Comment s'en sort l'informatique ? L'ordinateur ne lance pas un dé pour faire ça, ça prendrait trop de temps ! Certains algorithmes demandent des centaines de milliers de chiffres aléatoires à générer, il faut pouvoir les générer rapidement. Le plus connu est la méthode Monte-Carlo, utile pour calculer des probabilités à de très grandes échelles.

Pour générer ces nombres, on ne va pas faire de l'aléatoire, mais du pseudo-aléatoire. C'est presque aléatoire, mais pas vraiment.

L'idée est de générer une simple suite de nombre, de la forme u_n = A u_n-1 + B.
On choisit un point de départ, u₀.
Ensuite, u₁ = A . u₀ + B
Puis u₂ = A . u₁ + B
etc...

Ainsi on généré la suite u_n : u₀, u₁, u₂.... Qui nous donne autant de nombre aléatoire que l'on veut !
Pour avoir des nombres qui imite le fonctionnement d'un dé, on va ajouter un modulo 6 pour être sur de rester entre 1 et 6, ce qui nous donne la formule d'un générateur congruentiel linéaire :

u_n = [A u_n-1 + B] mod m

Et là, si vous avez suivi, vous avez envie de dire `mais, la suite va toujours avoir la même tête pour le même u<sub>0</sub>`, et je vous répondrais que c'est vrai. u₀ est appelé la graine du générateur, ou `seed` en anglais. Il faut pouvoir la choisir.... aléatoirement !
En pratique, on utilise souvent la date actuelle, ce qui suffit à avoir une génération assez aléatoire.

Enfin, les constantes A et B doivent être choisies pour obtenir les meilleurs suites aléatoires possibles. De nombreux mathématiciens se sont pencher sur le problème, au hasard, A = 31415821, B = 1 et C = 10⁸, et on obtient le générateur de Robert Sedgewick.

Il existe aussi d'autres formules pour créer la suite, d'autre choix de constante, mais le principe de base est toujours le même, un élément de départ u₀, puis une suite u_n = f(u_n-1).

L'erreur que font la plupart des développeurs est de réinitialiser la graine trop souvent avec la même valeur. Si on initialise la suite selon la seconde actuelle, et qu'on lance l'algorithme 3 fois pendant la même seconde, et bien on tombera 3 fois sur le même résultat, pas super aléatoire.

La méconnaissance de la base de la génération des nombres pseudo-aléatoires amène beaucoup de suspicion et de crainte quand à leurs utilisations, alors qu'en pratique, c'est une simple suite mathématique !

Pour les plus développeurs d'entre vous, l'article de Microsoft sur l'utilisation de la classe Random en C# est concis avec un exemple très précis des erreurs à ne pas faire : Random (Constructeur)

La valeur initiale par défaut est dérivée de l'horloge système et a la résolution finie. En conséquence, les objets Random différents qui sont créés successivement par un appel au constructeur par défaut ont des valeurs initiales par défaut identiques et produisent ainsi des jeux identiques de nombres aléatoires. Ce problème peut être évité en utilisant un seul objet Random pour générer tous les nombres aléatoires. Vous pouvez également le contourner en modifiant la valeur de départ retournée par l'horloge système, puis en fournissant explicitement cette nouvelle valeur de départ au constructeur Random(Int32).

Les CVs ne servent à rien

Les CVs et les lettres de motivation sont inutiles pour recruter un bon informaticien. En fait, ils sont inutiles pour n'importe quel genre de travail.

Ai-je envie de recruter le candidat le plus capable de faire un CV complet, concis, précis, parfait ? Je ne sais pas, peut-être, si le job que je veux lui proposer est de rédiger des dizaines de CVs par jour. Mais je voulais recruter un très bon informaticien. Alors je n'ai pas lu les CVs, ni les lettres de motivation.

Non, à la place, j'ai envoyé un test. Un test technique précisément, que les candidats devaient résoudre. Un test qui mêlait code informatique et réflexion mathématique. Rien de très compliqué, juste pour voir de quoi le candidat était capable. On m'a pris pour un original ! Quel idée, alors que lire un CV suffirait largement à savoir de quoi un candidat est capable.

Imaginons qu'à la place de vouloir recruter un informaticien, vous souhaitez recruter un jongleur.

- Recruteur : `Alors comme ça, vous savez jongler jusqu'à 5 balles ?`
- Candidat : `Oui, 5 balles, et facilement en plus.`
- Recruteur : `Et avec des quilles ?`
- Candidat : `5 quilles aussi.`
- Recruteur : `Formidable, on vous embauche !`

A aucun moment vous ne souhaitez voir le jongleur faire une démonstration ? Hélas, c'est ce qu'il se passe souvent en informatique, les recruteurs n'ont que très rarement les capacités d'évaluer techniquement les candidats. Donc on recrute sur CV. On joue au Bingo des mot-clés. `HTML`, `JavaScript`, `NodeJS`, `MySQL`, `PHP` BINGO ! On vous embauche.

Je préfère demander aux candidats d'envoyer un code. Si le code est bon, je lirai le CV, sinon le candidat sera éliminé d'office. Certains CVs de développeurs expérimentés se sont fait éliminés, pendant que j'interviewais des jeunes diplômés. Pourtant si on regardait les CVs, il n'y avait pas photos, le développeur expérimenté était meilleur. Mais le CV n'est que le reflet de la capacité d'un candidat à savoir rédiger un document hyper formaté. En aucun cas cela ne reflète ses capacités techniques.

Il y a quelque temps, un institut de recherche n'a pas retenu ma candidature pour un poste qu'il proposait. Il recherchait un développeur pour créer un logiciel de récupération de données automatisées sur des détecteurs répartis dans des champs de culture, pour créer différents rapports. Je n'ai pas eu d'entretien. Réponse du recruteur : `Nous n'avons pas retenu votre candidature, votre CV n'est pas assez orienté informatique industrielle`.

Je n'ai jamais eu de chance au jeu du bingo.

Bonus : Technical Interviewing - You're Doing it Wrong!

Un point sur les méthodes modernes d'entretien.

Petit traité de manipulation à l'usage des honnêtes gens

Vous souhaitez connaitre les secrets de la publicité, du marketing, ou juste apprendre 2-3 trucs pour vous aider à éduquer votre enfant ? Ce livre est fait pour vous.

Devenu un best-seller, ce livre est un formidable vulgarisateur de pensée psychologique. Quelques passages très universitaires pourront troubler les lecteurs les moins académiques d'entre nous, moi le premier. Cependant, le reste du bouquin est formidablement simple à comprendre.

Les auteurs nous expliquent que la base de la manipulation est l'engagement. Arrivé à faire s'engager quelqu'un dans quelque chose d'aussi anodin que répondre à une question est déjà une victoire. Le plus simple et le plus frappant des exemples est celui-ci :

Il vous manque 50 centimes pour acheter votre journal. Vous décidez de demander à des passants la monnaie manquante.

1. Vous choisissez une stratégie simple : `Bonjour, il me manque 50 centimes pour acheter mon journal, les auriez-vous s'il vous plait ?`
2. Vous choisissez une stratégie dite de pied-dans-la-bouche : `Bonjour, avez-vous l'heure ?` - `Oui, il est 11h53` - `Merci. Auriez-vous 50 centimes à me donner pour m'acheter mon journal ?`

Faites l'expérience, mais la deuxième méthode vous permettra d'augmenter énormément vos chances de réussite. Evidemment, on ne parle ici que de réussite statistique, rien ne vous garantira un résultat à 100%. Mais augmentez vos chances de réussite, c'est déjà énorme. Pourquoi ça marche ? Parce que le passant se sentira engagé, vous aurez établi un contact, et il se sentira mal à l'aise à l'idée de refuser une somme aussi ridicule que 50 centimes. Il est bien plus simple de refuser 50 centimes à quelqu'un que l'on ne connait pas.

Tout un éventail de techniques vous seront exposées : 

• Pied-dans-la-porte : une première demande peu coûteuse avant de faire la vrai demande
• Porte-au-nez : une première demande très coûteuse avant de faire la vrai demande
• Pied-dans-la-bouche : ouvrir le dialogue avant de faire la vrai demande
• Toucher : toucher la personne avant de faire la vrai demande

Il y en a beaucoup d'autres, je vous invite à lire ces notes de lecture qui vous économiseront la lecture du livre en entier. Sans parler du fait que les auteurs terminent par combiner des techniques entre elles, ce qui rend certaines stratégies diaboliquement efficaces.

Une technique qui m'a particulièrement plu, de par sa simplicité et son efficacité est la technique de l’étiquetage. Je l'apprécie particulièrement vu son application immédiate pour l'éducation des enfants. Le principe est de donner une qualité que l'on souhaiterais voir s'exaucer. L'enfant aura tendance à s'y tenir.

Par exemple : `Que tu es sage en voiture`. L'enfant intériorisera ce trait de caractère, et deviendra sage comme une image en voiture. Marche aussi pour les adultes, bien que les adultes ne soient pas particulièrement turbulents en voiture.

Ce qui est beau dans la manipulation, c'est que le manipulé ne se rendra compte de rien. Le pire, c'est qu'il se créera lui-même ses propres raisons pour justifier ses choix. `Pourquoi as-tu décidé de donner à tel organisme humanitaire plutôt qu'un autre ?` - `Parce que leurs combats me correspond plus.` - ou bien parce que leurs bénévoles étaient les meilleurs manipulateurs !

On fera aussi le parallèle avec le pouvoir démotivant des récompenses :

Dans un supermarché, on demande à une personne de garder nos provisions, car:

• Groupe 1 (faible justification): on a perdu un billet de 1$

• Groupe 2 (justification forte): on a perdu un portefeuille avec beaucoup d'argent dedans.

Quelques secondes plus tard, un objet tombe du sac d'un second expérimentateur. Dans la condition de contrôle, 35% des personnes alertèrent le second expérimentateur. Pour les personnes du groupe 1, 80% alertèrent le second expérimentateur (On note l'efficacité du pied dans la porte). Quant au groupe 2 (forte justification), seulement 45%. Tout ce passe comme si une forte justification équivalait à une pression. On ne peut pas refuser son aide à une personne ayant perdu son portefeuille plein d'argent. Ainsi, les sujets sont peu engagés par leur décision. C'est la théorie de l'engagement. Néanmoins, il faut remarquer que tous les sujets (faible ou forte justification) ont acceptés de garder les provisions. L'engagement dépend du sentiment de liberté qu'on a eu en prenant la décision. [Expérience N°6]

L'argent n'est pas un critère engageant. Promettre une récompense ne donnera pas à vos employés une occasion de s'engager envers votre entreprise, puisque ce sera la récompense qui servira de justification à leurs actes.

Ressources :

• Petit traité@Wikipedia
• Engagement@Wikipedia
• Avis client@Amazon

C'est quoi un code smell ?

En anglais, `smell` veut dire odeur, et implique précisément une mauvaise odeur. Un `Code Smell` est donc une mauvais odeur de code. Vulgairement, `un code qui pue`.

Il existe beaucoup de code smell, et on en a tous fait. En tant que développeur, il faut essayer de corriger nos propres code smell, et donc, il faut travailler son nez. Reconnaître un code smell est déjà la moitié du chemin de parcouru pour mieux coder, coder un code qui sent bon le bonbon rose.

Mon code smell favori à mes débuts était l'écriture de fonction longue comme un repas de noël, et impliquait l'utilisation intensive des touches Ctrl, C, et V.

Voici une liste non exhaustive de code smell :

• La notation hongroise. `int iInteger`, `long lLong`, `bool bReturn`. On ajoute l'initiale du type au nom de la variable. Mal enseignée, mal comprise, mal utilisée, on arrête tout. Voici un excellent article sur le sujet : Making Wrong Code Look Wrong. A lire 3 fois par jour jusqu'à le connaitre par cœur.
• Des commentaires tout le temps, partout. Là encore, l'école n'y est pas pour rien. Qui n'a jamais entendu de professeur ressasser `une ligne, un commentaire` ? Trop de commentaires est pire que pas de commentaires du tout. Le nom des variables et des fonctions doivent être suffisamment explicite pour ne pas avoir à commenter. `connection.Close(); // close the connection`. On s'en doutait ! Les commentaires sont là pour dire pourquoi vous faites quelque chose, et non pas pour décrire ce que vous faites.
• Duplication de code, deux fois les mêmes lignes, aïe.
• Objet dieu, ou `God Object`, des objets qui font tout, IHM, algorithme, généralement plusieurs milliers de lignes.
• Dans le même genre, des fonctions qui dépasse la centaine de lignes.
• Non uniformité de l'écriture des variables et des fonctions. Dans la même classe, `ma_premiere_method`, puis `MaDeuxiemeMethod`. Au sein d'une équipe, il est déjà difficile de garder tout le monde à la même enseigne, mais si tout seul, on est déjà pas d'accord avec soi même, on ne s'en sortira jamais.
• Getters et Setters auto généré. Ça casse le principe même d'encapsulage et ce n'est pas objet du tout.
• L'envie de fonctionnalité, `Feature Envy`, ou comment votre classe aimerait tellement faire pareil que le voisin. Reconnaissable à la ligne `A.getB().getC().getD().getTheNeededData();`. L'un de mes pêchés mignons. 
• Indentation manquante, ça ne pardonne pas.

Le Code Smell n'est pas un bug et est invisible à l'utilisateur. Par contre, le Code Smell ralentit le développement de nouvelles fonctionnalités, et assure d'horribles régressions lors de nouvelles livraisons.

Ressources :

• Code Smell@Wikipedia
• Code Smells@Coding Horror
• A Taxonomy for "Bad Code Smells"

C'est quoi un pixel ?

Le pixel, la hantise de toute bonne mère de famille qui souhaite faire un pêle-mêle avec les photos de son petit bébé adoré. Vas-y qu'on installe Photoshop, et qu'on télécharge de belles images vectorielles, on prépare tout, puis on dit à la gentille maman : "Allez, tu n'as plu qu'à ajouter les photos".

Et là, c'est le drame. Le bébé se retrouve avec la tête de Mario sur NES, et la maman est en pleurs : "J'y arrive paaaaaaaaaaaaaaaaaaaaas".

Pas de panique, reprenons tout depuis le début. Une image, ou photo, est constituée de pleins de petits points de couleurs. Ces petits points associés ensembles forment une image si on la regarde d'assez loin. Chaque petit point est appelé pixel. Donc si on dit qu'une photo fait une résolution de 2000x1000, c'est qu'il y a 2000 pixels de large, et 1000 pixels de hauteur, soit 2 millions de pixels, ou bien 2 mégapixels.

Et magie, la même chose s'applique aux écrans. Un écran de télé ou d'ordinateur est constitué de minuscules petites diodes lumineuses, qui affichent au final une image. Donc l'écran a une résolution 'normale', qui correspond à son nombre de diode, par exemple 1920x1080. Ici aussi on parle de pixel, même si ce n'est pas tout à fait la même notion.

Question classique : "1cm ça fait combien de pixel ?". Et bien ça dépend de comment on l'imprime ! La même image de 10x10 peut très bien être imprimée sur une feuille A4, ou une feuille A3. Le rendu sera plus ou moins pixelisé. Ça dépend de combien de pixels vous désirez pour 1cm. L'image sera de plus ou moins bonne résolution, et on verra plus ou moins les pixels si vous regardez la photo de plus ou moins loin. Wikipédia a un excellent article la dessus qui est concis et assez clair, je n'y reviendrai pas plus en détails : Résolution spatiale des images matricielles.

Même nombre de centimètres, nombre de pixels différent, ça va, ça va un peu, ça va plus du tout du tout !

Revenons à nos pixels. Pourquoi la tête de bébé était toute pixelisée ? Parce que la maman avait crée une image de fond de 400x300, ce qui est très très peu. Du coup, lorsqu'elle a mis les photos de bébé de 4000x3000, elle a dû les réduire d'un facteur 100 : on est passé de 1.200.000 à 120.000 ! Et bim, la belle photo est devenue un amas de pixels horrible.

La règle de la retouche d'image, c'est de toujours partir d'une très haute résolution. Le traitement doit être fait avec le maximum de pixels possible, il sera toujours possible de réduire si besoin, mais au moins à l'impression, il sera possible d'imprimer des photos d'extrêmement bonne qualité, et c'est là tout le but recherché quand on veut un beau bébé !

Tadaaaaaaaaaaa !

Les récompenses sont démotivantes

Dans une conférence TED, j'ai appris que les récompenses, financières ou autre, n'était pas un facteur de motivation :

On m'aurait menti depuis tout ce temps ? Alors que l'on m'a poussé à faire un bac générale, puis une prépa, puis une école d'ingénieur, pour gagner un maximum d'argent, je découvre aujourd'hui que c'était un mensonge ? L'argent ne fait pas le bonheur ? Mince alors !

En fait si, l'argent fait le bonheur, jusqu'à un certain point. Une fois comblé les besoins naturels : habitation, alimentation, sécurité, (on parle de besoins physiologiques) le reste ne sert pas à s'épanouir plus. Au mieux, il permet d'accéder à un confort supérieur. Au pire, il est un frein à un développement plus personnel : de meilleurs horaires, un travail moins loin, un travail plus intéressant, un mi-temps...

Mais ce n'est pas tout. Non seulement l'argent n'est pas motivant, mais devient même un excellent démotivant. Dans l'étude dont parle la vidéo, on a assigné une énigme à deux groupes. Le premier le faisait pour la science, le deuxième pour une maigre somme d'argent. Le premier groupe a été plus efficace que le deuxième. L'argent nous motive pour travailler plus vite, mais il ne nous permet pas de travailler mieux. Hors pour la résolution d'une énigme, ou tout autre tâche qui requiert de l'intelligence, l'argent devient un frein.

Un autre exemple est l'éducation des enfants. Vous souhaitez que votre enfant teste un nouveau sport comme le judo alors qu'il n'est pas très motivé. Pourtant vous pensez que ça pourrait l'aider à se développer et à le rendre moins timide. Si vous lui proposez une récompense comme une glace ou un ballon, la prochaine fois qu'il devra allez au judo, il désirera une récompense. Il ne souhaiteras plus y aller sans contrepartie, et il ne prendra pas réellement plaisir à ce sport, car le judo sera lié à un mécanisme de récompense. Je ne prend pas plaisir à pratiquer le judo, je le fais pour la récompense.
Une meilleur façon de s'y prendre est de fournir des raisons intrinsèques. Tu me feras plaisir si tu vas au judo. Je serais vraiment fier de toi. L'enfant se sentira réellement motivé, car il aime faire plaisir, et il y retournera volontiers, et peut être même qu'il se mettra à aimer ça.

On peut aisément transférer cette situation dans le monde professionnel. Si vous souhaitez assigner une nouvelle tache à l'un de vos employés, ne parlez pas de récompense. Cela ne motivera pas votre employé, et il risque de devenir complètement improductif. L'employé doit être motivé par des raisons intrinsèques : Autonomie, Maîtrise et Pertinence. Faire ce qu'on veut, le faire bien, et parce que on y croit.

Si un beau poster et une jolie phrase est tout ce qu'il te faut pour être motivé,
tu as probablement un boulot très simple, le genre que les robots feront bientôt

Dilemme de la reprise de projet : tout détruire ou pas ?

Durant ma carrière, j'ai souvent été confronté à la même question. En face d'un projet biscornu, quel était la meilleure solution ?

Le dilemme de la reprise de projet sur CommitStrip

Soit on appelle la boule de démolition, soit on rénove. Qu'est ce que prendra moins de temps ? Qu'est ce qui est le mieux ?

Le jeune stagiaire plein de bonne volonté n'a pas très envie de reprendre du code existant. Il est toujours plus agréable de repartir de zéro, de tout reconstruire. Au moins, ce sera notre logiciel, pas celui d'un autre.

Mais attention, la plupart du temps, repartir de zéro est une très mauvaise idée. C'est très séduisant, les développeurs vous vanteront les défauts du code existant, les mérites des nouvelles technologies, et puis que les vieux n'y comprennent rien, ou que le stagiaire a fait n'importe quoi.

Dans l'article Les choses que vous ne devez jamais faire, l'auteur Joel Spolsky préconise de ne jamais repartir de zéro. Repartir de zéro implique de ne plus avoir un produit livrable. Et perdre le potentiel d'avoir un produit livrable, c'est perdre un marché. On perd aussi des informations précieuses que les anciens développeurs ont déjà découverts : bugs de compatibilité, règles fonctionnelles biscornues... Il faut tout reprendre, tout revoir, êtes vous sûr que cela ne vas pas prendre plus de temps ?

Dans mon projet actuel, on est parti de très loin. Le logiciel était en ruine, programmé de la pire des manières : variables globales, aucune instance d'objet, code non optimisé (pour les connaisseurs, le tri à bulle était utilisé de partout), non hiérarchisé, environ 100.000 lignes de code répartit dans une vingtaine de fichiers, sans aucun dossier. On m'a embauché pour remettre de l'ordre, allais-je repartir de zéro ?

Le logiciel était utilisé par trois personnes de manière intensive. Ils avaient besoin de correction, maintenant, pas dans un an. Réécrire de zéro m'aurait pris au moins une année pleine, et encore, c'est optimiste. Les utilisateurs ne pouvaient pas rester avec un logiciel inefficace pendant toute une année, car cela allait impacter directement sur la production de l'entreprise.

J'ai choisi de faire une rénovation complète du logiciel, en conservant constamment une version livrable et fonctionnelle, moins pire que la précédente. Cela a été difficile et compliqué. Il a fallut se battre contre la médiocrité, corriger les aberrations, être confronté au jour le jour à des absurdités. Il est plus difficile de lire du code que de l'écrire. C'est éprouvant émotionnellement de reprendre le code d'autrui, d'autant plus quand il est mauvais. Imaginez-vous lire `Les misérables` en langage sms.

Cependant, les bénéfices ont été innombrables. Les utilisateurs ont pu voir au cours de l'année des améliorations visibles et décisives. Les temps de calculs fondaient à vue d’œil, les bugs devenaient de plus en plus rares, le logiciel devenait fiable, robuste et performant. Et le plus important, les utilisateurs reprenaient confiance dans le logiciel. Ils n'en avaient plus peur, ils avaient envie de l'utiliser, la productivité devenait meilleure.

Bien sur, la taille du projet rentre en compte. Si vous avez quelques centaines de lignes de code, il vaut peut être mieux tout reprendre de zéro. Mais rapidement, si vous commencer à dépasser quelques milliers de lignes, réfléchissez bien à l'impact de repartir de zéro.

Combien de temps ?

Dans mon métier, on me demande souvent combien de temps cela va prendre pour développer telle ou telle fonctionnalité, ou pour résoudre tel ou tel bug.

Dans ces cas là, voici ce qu'il y a dans mon cerveau :

La roue du chiffrage sur CommitStrip

Quel idée de demander à un écrivain combien de temps cela lui prendra pour écrire son prochain roman. Ou combien de temps cela prendra à un peintre de sortir son prochain tableau.

Certains chef d'oeuvre ont pris des années, d'autre quelques minutes. Certains me diront que comparer l'écriture d'un logiciel à de la peinture, c'est exagéré. Et pourtant, les deux sont des activités créatives.

Pour un bûcheron, couper un arbre n'est pas créatif. C'est procédurale. On peut facilement calculer le temps exact que mettra le bûcheron à abattre une dizaine d'arbres.

Un travail de création demande de l'imagination, de l'innovation, des choses incalculables et non mesurables. Quand on me demande le temps que je mettrais à faire une tâche, je réponds le plus honnêtement possible. Des fois ça prend deux fois plus de temps, des fois deux fois moins de temps. Un manager m'a dit un jour que mon manque d'expérience m’empêchait d'établir un chiffrage précis. Evidemment, ce manager n'avait jamais touché une ligne de code, considérait les développeurs comme des ressources interchangeables, et l'informatique comme une chaîne de montage industrielle.

Il existe tout de même des solutions pour permettre des chiffrages plus justes. De nouvelles méthodes de management de projet, comme les méthodes agiles, préconisent par exemple de réévaluer en cours de route les chiffrage horaires. Cela parait plus juste, car au fil de l'avancement d'un projet, on sait de mieux en mieux combien de temps nous prendra ce qu'il reste. Du côté des mauvaises nouvelles, cela empêche d'avoir un budget précis avant le début du projet. Et ça les décideurs n'aiment pas ne pas savoir. Pourtant, combien de projets ont été abandonnés parce que les chiffrages étaient coulés dans le marbre ? Trop en retard, trop cher, trop mal conçu, trop mal managé. L'agilité permet de la souplesse dans les plannings. Avec l'expérience acquise au fil des ans, on sait que le chiffrage d'un projet au départ ne correspondra pas au temps que cela coûtera réellement. Il faut prendre ces paramètres en compte lors d'un chiffrage, et garder en tête que ce ne sont que des prévisions, qu'il faudra sans cesse réévaluer.

Les 12 leçons de Steve Jobs

Guy Kawasaki est l'un de ceux qui ont eu la chance de travailler avec Steve Jobs. Ça pose un bonhomme !

Lors d'une conférence TEDx, la TEDxUCSD (université de Californie à San Diego) qui a eu lieu le 11 mai 2013 , il nous présente les leçons qu'il a appris de Steve Jobs, en anglais :

Cette conférence reprend le billet que l'on peut trouver sur son blog dont voici la traduction :

Beaucoup de personne nous ont énuméré les leçons de Steve Jobs, mais peu ont réellement travaillé avec lui. Je ne veux pas que ces leçons soient perdues ou oubliées, voici donc ma liste des 12 leçons que j'ai apprises de Steve Jobs.

1. Les experts sont inutiles

Les experts : journalistes, analystes, consultants, banquiers et gourous ne savent rien faire, donc ils conseillent. Ils sont capables de vous dire ce qui ne va pas avec votre produit, mais ils sont incapables d'en fabriquer un. Ils peuvent vous dire comment vendre quelque chose alors qu'ils n'ont rien à vendre. Ils peuvent vous dire comment créer de supers équipes alors qu'ils sont chef d'une unique secrétaire. Par exemple, les experts nous ont dit que les deux principales lacunes de Macintosh durant le milieu des années 80 étaient l'incompatibilité de l'imprimante à marguerite et Lotus 1-2-3. Un autre conseil des experts était d'acheter Compaq. Entendez ce que disent les experts, mais ne les écoutez pas toujours.

2. Les utilisateurs ne savent pas vous dire ce qu'ils veulent

L'expression `étude de marché Apple` est un oxymore. Le groupe de discussion chez Apple, c'était le cerveau droit de Steve Jobs parlant au gauche. Si vous demandez aux utilisateurs ce qu'ils veulent, ils vous répondront `mieux, plus rapide, moins cher`. C'est à dire la même chose mais en mieux, surtout pas de changement révolutionnaire. Ils peuvent seulement décrire leurs désirs dans des termes qu'ils connaissent. Pendant l'introduction de Macintosh, les gens voulaient une machine MS-DOS mieux, plus rapide et moins cher. La poule aux œufs d'or des start-ups, c'est de créer des produits que vous voulez utiliser. C'est ce que Steve et Woz ont fait.

3. Franchissez les paliers

Pêche aux glaçons au XIX^e siècle

Ce n'est pas en recréant la même chose en mieux que l'on avance significativement. Les meilleures sociétés d'imprimante à marguerites créaient de nouvelles polices, dans de nouvelles tailles. Apple a franchi un palier en créant l'imprimante laser. Pensez au pêcheur de glaces, aux usines de glaces, et aux compagnies de congélateurs. Glaçon 1.0, Glaçon 2.0 et Glaçon 3.0. Etes vous toujours en train de pécher de la glace en hiver sur un lac gelé ?

4. Un plus gros défi entraîne un meilleur travail

Je vivais dans l'angoisse que Steve me dise que j'étais ou que mon travail était médiocre. En public. Cette peur était un grand défi. La compétition avec IBM et Microsoft était un grand défi. Changer le monde était un grand défi. De tout temps, les employés d'Apple et moi-même avons produit le meilleur travail possible parce que nous avions le devoir de le faire pour relever ces grands défis.

5. Le design ça compte

Steve rendait fous les gens avec ces demandes. Certaines nuances de noirs n'étaient pas assez noirs. Le commun des mortels pense qu'un noir est un noir, et qu'une corbeille est une corbeille. Steve était un perfectionniste au delà même de l'entendement, mais il avait raison. Certaines personnes font attention au design, peut être pas tout le monde, mais les personnes qui comptent oui.

6. Vous ne pouvez pas vous tromper avec de grands graphiques et des grandes polices

Regardez les diapos de Steve. La police est de taille 60. Généralement il y a une grosse capture d'écran ou un graphique. Regardez les diapos des autres conférenciers techniques, même ceux qui ont vu Steve en action. La police est de taille 8, et il n'y a pas de graphique. Tout le monde s'accorde à dire que Steve était le plus grand présentateur de produit au monde. Pourquoi il n'y a pas plus de personne qui le copie ?

7. Changer d'avis est un signe d'intelligence

Quand Apple a livré le premier iPhone, il n'y avait pas d'applications. Steve a décrété que les applications étaient mauvaises parce qu'on ne savait jamais ce qu'elles allaient faire au téléphone. Six mois ont passé puis, comme une évidence, Steve a décidé, ou quelqu'un l'a convaincu, que les applications étaient l'avenir. Apple a parcouru beaucoup de chemin en très peu de temps, entre `aucune application` à `il y a une application pour ça`.

8. Le prix et la valeur sont deux choses différentes

Honte à vous si vous décidez que tout est basé sur le prix. Encore plus si vous êtes sur un marché ou la concurrence ne se joue que sur le prix. Le prix n'est pas la seule chose qui importe. Ce qui est important, au moins pour quelques personnes, c'est la valeur. Et la valeur prend en compte la formation, le support, et la joie intrinsèque que vous procure l'usage des meilleurs outils qui n'ont jamais été crées. Il est évident que personne n’achète un produit Apple pour son prix.

9. Les meilleurs embauchent les encore meilleurs

En fait, Steve pensait que les meilleurs embauchaient les meilleurs, c'est à dire des gens qui sont aussi bon qu'eux. J'ai affiné légèrement cette théorie. Ma théorie dit : les meilleurs embauchent les encore meilleurs. Cependant, les gens moyens embauchent les gens médiocres, afin de se sentir supérieur à eux. Et les médiocres embauchent les mauvais. Si vous commencez à embaucher des gens moyens, préparez vous à subir ce que Steve appelait `l'explosion des clowns`.

10. Les vrais chefs font les présentations

Steve Jobs pouvait présenter iPod, iPad, iPhone et iMac deux ou trois fois par an devant des millions de gens. Pourquoi tant de PDG font appel à leur directeur technique pour faire une démonstration ? Peut être pour montrer une certaine cohésion d'équipe. Peut être pas. Il est plus probable que le PDG ne comprend pas ce que sa compagnie fabrique pour le présenter suffisamment bien. Plutôt pathétique, non ?

11. Les vrais chefs vendent

Malgré son extrême perfectionnisme, Steve vendait des produits. Peut être que le produit n'était pas parfait à chaque fois, mais il était suffisamment bon. La leçon est que Steve ne chipotait pas pour rien, il avait un but : vendre pour achever la domination des marchés existant, ou pour la création de nouveaux marchés. Apple est une société d'ingénierie, pas de recherche. Vous préférez être qui ? Apple ou Xerox PARC ?

12. Le marketing se résume à fournir des produits originaux qui apportent de la valeur

Imaginez une matrice 2x2. L'axe vertical représente l'originalité de votre produit et l'axe horizontal représente sa valeur. En bas à droite : votre produit ajoute de la valeur, mais n'est pas original, vous allez devoir vous battre sur les prix. En haut à gauche : votre produit est original mais n'apporte aucune valeur, vous serez le seul sur un marché qui n'existe pas. En bas à gauche : votre produit n'est pas original, et n'apporte aucune valeur, vous êtes perdu. En haut à droite : votre produit est original et apporte de la valeur, c'est là où vous faites de la marge, de l'argent, et écrivez l'histoire. Par exemple, l'iPod était complètement nouveau et apportait de la valeur, car c'était le seul moyen de télécharger légalement de la musique bon marché des six principaux labels.

Bonus

Il faut avoir la foi pour voir certaines choses. Quand vous franchissez les paliers, défiez ou ignorez les experts, êtes confronté à d'énormes défis, êtes obsédé par le design et concentré sur l'originalité et la valeur, vous devrez convaincre les gens de croire en ce que vous faites pour voir le fruit de vos efforts récompensé. Les gens avaient besoin de croire en Macintosh pour le voir se réaliser. Idem pour l'iPod, l'iPhone et l'iPad. Tout le monde n'aura pas la foi, mais ce n'est pas grave. Pour commencer à changer le monde, il faut d'abord changer quelques esprits. C'est la plus grande leçon que j'ai apprise de Steve Jobs.

Originalement publié sur le site How to Change the World

Guy Kawasaki

Guy Kawasaki est un conseiller spécial de la filiale Motorola de Google. C'est aussi l'auteur de APE, What the Plus!, L'art de l'enchantement, et neuf autres livres. Précédemment, il était l'évangéliste en chef d'Apple. Kawasaki a un BA de Stanford, et un MBA de UCLA, ainsi qu'un titre honorifique de docteur du Babson College.

Qui sont les rockstars du Web ?

Angy Birds, l'un des plus grands succès
commerciaux de l'époque smartphone

Les rockstars du web, ce sont les développeurs, informaticiens, ingénieurs logiciels, consultants informatiques, etc...
Tout ces termes regroupent en fait un seul et même archétype, une personne qui tape des ligne de codes sur son clavier pour penser et créer vos applications, vos Angry Birds, vos Photoshop et vos Gmail.

De plus en plus souvent dans les annonces d'emplois anglo-saxonne on trouve la mention `recherche développeur rockstar`. En effet, on peut établir la même sorte de distinction entre artiste et développeur.

Il y a l'artiste qui joue dans son garage, il y a celui qui fait quelques scènes locales, il y a celui avec une petite renommée nationale, et enfin il y a la rockstar internationale.
Entre l'adolescent qui joue dans son garage et la rockstar, il y a un facteur d'au moins un million sur l'argent qu'il rapporte. C'est la même chose pour les développeurs.

Le développeur moyen rapportera pas grand chose à son entreprise, et il arrive même qu'il fasse perdre de l'argent. Le bon développeur fera gagner en rentabilité, et produira du chiffre. La rockstar développera des applications tellement géniale que le chiffre d'affaires sera susceptible d'être décuplé. Par exemple, l'application interne toute buggée deviendra une application de renommée qui sera téléchargée et vendue à l'internationale.

Ce résultat ne s'obtient pas avec de meilleurs secrétaires, de meilleurs managers, de meilleurs analystes financiers, de meilleurs juristes, de meilleurs responsables qualités. Ce résultat s'obtient grâce à de meilleurs développeurs.

Les entreprises de la Silicon Valley ne s'y trompent pas. Si Google est l'entreprise qui passe le plus d'argent au monde dans le processus de recrutement, c'est bien parce qu'ils ne veulent que les meilleurs, la crème de la crème.
Google reçoit des centaines de milliers de CV par an, il faut passer 5 entretiens avec 5 personnes différentes, chacun étant potentiellement éliminatoire. La moitié des employés chez Google à déjà été éliminé au moins une fois avant d'être embauché.
Google ne veut que les rockstars. Et c'est comme ça que Google est devenu l'entreprise géante que l'on connait aujourd'hui. C'est bien de recruter des rockstars, mais ensuite, comment on les garde ?
La liste des avantages est longue comme le bras : nourriture et boisson à volonté, crèche d'entreprise, salaire élevé, temps libre pour projet personnel...
Le but n'est plu de motiver les employés, mais de les garder. Comparez avec votre entreprise dans laquelle vous travaillez. Non, ne le faites pas en fait, c'est déprimant.

Les ressources humaines n'ont pas encore compris l'importance du rôle de développeur dans l'entreprise. Elles considèrent les développeurs comme des ressources interchangeables. Sauf qu'on ne remplace pas Johnny Hallyday par la fanfare du village. Pourtant c'est ce que font les entreprises tout les jours. Ces entreprises ne jugent pas la qualité d'un développeur à ce qu'il produit, mais aux nombres d'heures qu'il passe au bureau. De plus, le développeur ne rentre pas dans la case production, mais dans la case frais généraux. Au même titre qu'un comptable ou qu'une standardiste, on considère son rôle comme un soutien pour toute l'entreprise, au lieu de voir son rôle de producteur. Un développeur coûte de l'argent et ne rapporte rien. Alors qu'un commercial rapporte de l'argent, et ne coûte rien puisqu'il est payé par prime.

Alors si demain, vous vous demandez pourquoi ce satané logiciel interne ne fonctionne plu, vous saurez que la fanfare du village a encore frappé.

Joël Spolsky

La totalité de ce post n'est qu'une tentative de paraphrase de l'excellent billet Hitting the High Notes du blog de Joël Spolsky.

Joël Spolsky est un programmeur et écrivain américain. Il est l'auteur de Joel on Software (traduit en français), un blog sur le développement logiciel. Il a été le chef de projet de l'équipe Microsoft Excel entre 1991 et 1994, et fonda plus tard sa compagnie installée à New York : Fog Creek Software.
Il est le créateur du célèbre site dédié à l'entraide informatique Stack Overflow.

Inversion des dépendances (SOLID 5/5)

Ce post fait partie de la série S.O.L.I.D.

Cette série s'achève sur le principe d'inversion des dépendances.

Inversion des dépendances... Déjà inversion, on ne l'utilise pas souvent, dépendance pas tellement plus, mais les deux ensemble, c'est un comble.

Est-ce que tu souderais directement ta lampe à la prise électrique du mur ?

Ce principe dit que les hauts modules ne doivent pas dépendre des bas modules, que les deux doivent dépendre des abstractions. Et en plus, les abstractions ne doivent pas dépendre des détails, mais que les détails doivent dépendre des abstractions. Pfiou...

En fait, ça dit d'utiliser des interfaces et des classes abstraites. Le plus possible. Tout en respectant les 4 premiers principes. Cela clôt un peu le puzzle SOLID. Chaque principe s'imbriquant les uns dans les autres.

Imaginons que vous voulez commander une bière. Comme d'habitude, vous allez dans votre bar favori et vous commandez la dite bière. Puis vous avez un algorithme pour la boire. Le plus immédiat serait d'écrire :

public void DrinkBeer(FavoriteBar bar)
{
    Beer beer = bar.OrderBeer();
    this.RaiseElbow();
    this.Drink(beer);
}

Ok, super, vous avez votre méthode pour boire une bière uniquement dans votre bar favori. Donc si demain vous souhaitez tester un nouveau bar, c'est mort. Il vas falloir modifier votre algorithme, et ça c'est mal (principe d'ouvert fermé). Il faut dépendre des abstractions ! Au lieu de prendre en paramètre une classe spécifique, prenons plutôt une abstraction : une interface !

Abstrayons notre bar :

interface IBar
{
    Beer OrderBeer();
}

Champion de France du lever de coude

class FavoriteBar : IBar

Maintenant, on peut commander et boire de n'importe quel bar :

public void DrinkBeer(IBar bar)
{
    Beer beer = bar.OrderBeer();
    this.RaiseElbow();
    this.Drink(beer);
}

Bon, notre interface IBar qui contient juste de quoi boire une bière manque de généricité. Si demain on veut boire un pastis, comment on fait ? Générisons ! Et au passage, on ségrégationne un peu mieux notre interface pour la rendre moins global. Pour cela il suffit de la nommer correctement. Un bar fait plein de choses, mais ici, seule la caractéristique 'commande de boisson' nous intéresse :

interface IOrderableBeverage
{
    Beverage Order(BeverageType type);
}
class FavoriteBar : IOrderableBeverage

public void DrinkBeer(IBar bar)
{
    this.Drink(bar, BeverageType.Beer);
}
public void Drink(IBar bar, BeverageType type)
{
    Beverage beverage = bar.Order(type);
    this.RaiseElbow();
    this.Drink(beverage);
}

C'est beau, ça respecte plein de principe SOLID, on est fier, on est devenu un meilleur programmeur, félicitons-nous ! A votre santé !

Ségrégation des interfaces (SOLID 4/5)

Ce post fait partie de la série S.O.L.I.D.

L'avant dernier principe SOLID est la ségrégation des interfaces. Si le terme séparation est connu, le terme ségrégation l'est un peu moins.

Wiktionnaire nous dit :

Action par laquelle on met quelqu’un ou quelque chose à part, on le sépare d’un tout, d’une masse.

C'est très précis, il faut mettre à part les interfaces.

Tu veux que je branche ça. Où ?

L'idée est que le client qui va utiliser vos interfaces ne se retrouvent pas avec des interfaces à 150 méthodes, parce que la classe sous-jacente contient 150 méthodes. Chaque interface doit avoir un but unique, et l'on retrouve le premier principe de responsabilité unique.

Prenons une pizzeria. Une pizzeria fait des pizzas, les livre, encaisse votre argent, paye ses impôts, paye ses employés, subit un contrôle sanitaire de temps en temps.

Imaginons que vous voulez commander une pizza à une pizzeria qui hérite de l'interface IPizzeria.

Supposons l'interface suivante :

interface IPizzeria
{
    Pizza Order(PizzaType type);
    void Deliver(Pizza pizza, Location address);
    void Pay(decimal dollar);
    void PayTaxes(decimal dollar);
    void PayEmployees(List<Employee> employees);
    void HealthControl();
}

Vous, client, vous souhaitez appeler la pizzeria pour commander la pizza choisi par l'utilisateur :

public Pizza OrderPizza(IPizzeria pizzeria)
{
    PizzaType type = (PizzaType)comboBoxPizzaType.SelectedItem;
    return pizzeria.Order(type);
}

Là tout se passe bien. Mais comme l'interface n'a pas été ségrégationnée, un risque aurait été d'appeler le contrôle sanitaire.

public Pizza OrderPizza(IPizzeria pizzeria)
{
    PizzaType type = (PizzaType)comboBoxPizzaType.SelectedItem;
    pizzeria.HealthControl();
}

Vous imaginez le bazar si à chaque commande client les inspecteurs se pointent ?
Outre le faite de se tromper de méthode, le principe de ségrégation permet un découpage net et précis du code. Certes, votre objet fait plein de choses. Ce n'est pas la peine que le monde entier soit au courant.

Vous client, vous ne devez voir que ce qui vous intéresse de la pizzeria :

interface IOrderablePizza
{
    Pizza Order(PizzaType type);
    void Deliver(Pizza pizza, Location address);
    void Pay(decimal dollar);
}

D'un autre côté, les inspecteurs sanitaires se foutent royalement que vous livrez des pizzas. Ce qui les intéresse, c'est la caractéristique entreprise de la pizzeria :

interface IBusiness
{
    void PayTaxes(decimal dollar);
    void PayEmployees(List<Employee> employees);
    void HealthControl();
}

Notre pizzeria finit par hériter de ces deux caractéristiques : c'est une entreprise (paye des impôts, des employés, subit des contrôles), qui fait des pizzas (cuisine, livraison).

class DaEnzoPizza : IOrderablePizza, IBusiness
{
}

Une femme à découvrir, Barbara Liskov (SOLID 3/5)

Ce post fait partie de la série S.O.L.I.D.

Nous arrivons au numéro 3 des 5 principes SOLID, le bien nommé principe de substitution de Liskov !

Barbara Liskov est une informaticienne ! Oui ça existe. Son principe est le suivant :

Si  est une propriété démontrable pour tout objet  de type , alors  est vraie pour tout objet  de type  tel que  est un sous-type de .

A copier 100 fois. Donc vous aurez compris que c'est le plus violent des cinq principes. Mais c'est pas si compliqué. En résumé, ça dit que si ça marche pour MaClass, ça marche aussi pour MaClassDerivé.

Si ça ressemble à un canard, caquette comme un canard, mais a besoin de piles, tu as probablement la mauvaise abstraction

Ça ne s'applique déjà que dans le cas ou 2 classes existent, et l'une hérite de l'autre.

Imaginons une classe Canard, et créons une sous classe CanardEnPlastique.
Si on décide que Canard peut voler, alors le code suivant est valide :

Canard couin = new Canard();
couin.EnvoleToi();

Par contre le programme suivant lance une Exception CanardEnPlastiqueNeVolePasException :

Canard couin = new CanardEnPlastique();
couin.EnvoleToi();

On ne peut pas substituer un canard en plastique à un vrai canard, c'est trop différent. On ne respecte pas le principe de substitution de Liskov. Pourtant tu l'as déjà fait dans ton code, on l'a tous fait. Et c'est mal. La prochaine fois que tu hérites d'une classe, penses à couin couin. Ne lance pas d'exception quand tu surcharges un comportement. Tout ce que fait la super classe, ta sous classe doit être au pire capable d'autant, c'est le minimum. L'héritage n'est pas fait pour limiter les capacités des classes mères, mais au contraire d'augmenter leurs capacités.

On peut voir ça comme des contraintes. Ce qui rentre dans la sous classe doit être au pire moins contraignant que ce qui peut rentrer dans la super classe. La sous classe doit être moins chiante. Si tu peux rentrer des pommes dans la super classe, la sous classe pourra elle prendre tout les fruits.

Inversement, tout ce qui sort doit être plus contraignant. Si la super classe sort des Girafes, la sous classe pourra sortir des bébés girafes par exemple. Par contre elle pourra pas sortir des éléphants. Si vous aimez le formalisme, l'explication de Wikipédia est beaucoup moins drôle:

• Les préconditions ne peuvent pas être renforcées dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des préconditions plus fortes que celles de sa superclasse.
• Les postconditions ne peuvent pas être affaiblies dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des postconditions plus faibles que celles de sa superclasse.

Gardons en tête qu'une sous-classe doit ajouter des fonctionnalités à la super-classe, et en aucun cas en limiter le comportement.

Sous-classer le canard en lui ajoutant la caractéristique plastique, c'est lui enlever la possibilité de voler. C'est pas SOLID !

L’ovoïde à face centré (SOLID 2/5)

Ce post fait partie de la série S.O.L.I.D.

Dans la série des principes SOLID, voici le numéro 2 : le principe d'ouvert/fermé.
Le nom est très mal choisi, mais c'est ancré dans le marbre, il va falloir faire avec.
La définition nous dit :

Ouvert à l'extension, fermé à la modification

La chirurgie à poumons ouverts n'est pas nécessaire quand on veut mettre un manteau

Quand tu crées une classe, tu dois être capable d'étendre son fonctionnement sans avoir à constamment la modifier. C'est pour ça que l'on parle d'extension. Le plus évident des exemples est le bon vieux fichier de paramétrage. Tu crées ta classe pour qu'elle soit paramétrable.

Exemple : la classe qui génère le rapport Excel doit pouvoir prendre en paramètre des couleurs qui pourront être choisies quand tu créeras une instance de classe. Il ne faut pas qu'à chaque fois que le client souhaite rajouter un bleu un peu moins bleu, il faille aller taper dans le code.

Donc on générise. Il faut que ta classe soit générique, tout le temps, c'est la base.
On n'écrit pas :

NuclearBomb nuclearBomb = new NuclearBomb();
nuclearBomb.LaunchOnBagdad();

Il faut génériser !

Town bagdad = new Town();
NuclearBomb nuclearBomb = new NuclearBomb();
nuclearBomb.Launch(bagdad);

Sinon si demain, on veux rayer de la carte Le Caire, il vas falloir ouvrir le code de le classe NuclearBomb pour ajouter la méthode LaunchOnLeCaire. Et ça ce n'est pas acceptable si l'on veut appliquer les principes SOLID. Surtout que toucher au code d'une bombe nucléaire, c'est très, très dangereux. La moindre erreur, le fil rouge au lieu du fil bleu, et tout explose !
La méthode Launch devient donc générique, elle est applicable à n'importe quel ville, alors que la méthode LaunchOnBagdad n'était pas générique, elle ne s'appliquait qu'a une seule ville. Plus besoin de toucher au code de la bombe, ouf ! L'Oncle Sam va pouvoir dormir sur ces deux oreilles.

C'est pour ça que l'on parle d'ouverture => On veut pouvoir étendre les fonctionnements de ce qui existe, par exemple en créant des sous-classes, ou en héritant d'interface.
Et on parle de fermeture => On veut pouvoir étendre les fonctionnements de ce qui existe, sans toucher au code déjà écrit.

De la solidité que diable ! (SOLID 1/5)

Ce post fait partie de la série S.O.L.I.D.

Aujourd'hui un poste purement informatique, qui te fera passer Kant pour de la lecture de 6e.

Ces dernières années, le développement informatique est devenu plus abouti, plus mature, plus solide, plus SOLID. SOLID, comme le mot convient bien, autant en français qu'en anglais, ça tombe bien. Donc oui, fini les constructions logiciels qui s’effondrent dés qu'on pose un pied dessus. Un ensemble de règles a vu le jour pour faire des constructions logiciels fiables et robustes. Ça a l'air compliqué au départ, mais c'est pas si sorcier, même toi tu vas y arriver.

SOLID est un acronyme de cinq lettres, chacune définissant un principe. Attention c'est hard :

• S = Single responsibility principle
• O = Open/closed principle
• L = Liskov substitution principle
• I = Interface segregation principle
• D = Dependency inversion principle

SOLID, le développement logiciel n'est pas une jeu de Jenga

Donnez moi un S (comme single), le principe de responsabilité unique.

Le principe veut que chaque classe, chaque objet, ne serve qu'à un unique but. Fini les classes qui font des centaines et des centaines de lignes. Quand tu crées ta classe, pose toi la question : à quoi va-t-elle servir. Tu dois avoir une et une seule notion en tête. Je veux modéliser un canard. Je crée la classe Canard. A quoi va-t-elle servir ? A modéliser Canard.

Je vais créer la classe ExcelIO. A quoi va-t-elle servir ? A extraire un fichier excel pour les rapports annuels, et à lire les fichiers d'imports des commerciaux. BIIIIIP, FAUX, ERREUR. Deux notions, deux classes. Demain le rapport annuel changera, pas le fichier d'import. La classe qui sert à lire les fichiers d'import va être modifiée sans raison valable, et c'est une erreur.

On arrive à la notion sœur : un objet doit avoir une et une seule raison de changer.

Ce n'est pas parce que tu peux le faire que tu dois le faire

Les raisons de ce principe, c'est d'éviter les effets de bords. Quand le client viendra t’engueuler parce que ses imports ne fonctionnent plu, alors que seule la fonction du rapport annuel devait changer, tu comprendras ta douleur.

Toucher du code, c'est dangereux, et invariablement, ça crée des bugs, donc autant toucher le moins de code possible lors d'un changement.

L'autre utilité de ce principe, c'est d'avoir des classes plus courtes, plus restreintes, avec moins de code. Donc plus compréhensible par tes collègues, et par le toi du futur.

Fini les classes couteaux suisses, qui démarrent le moteur, remplissent la piscine et font le café.

On les connait bien, ces classes qui accèdent à l'interface utilisateur, parsent les données d'entrée, interrogent la base de données, interprètent les résultats, sortent des rapport avec agrégations des résultats. NON, STOP. Ton fichier .php qui fait tout en même temps, c'est fini.

On parle aussi de `god-like object`, des objets dieux, omniscient qui connaissent tout sur tout. On les appelle souvent Manager. ExcelManager, FormManager, etc... C'est un `code-smell`, en gros, quand tu vois une classe qui s'appelle machinChoseManager, ou quand tu t’apprêtes à la créer, STOP, ça pue. Lève les mains de ton clavier, et réfléchis.

On découpe on découpe on découpe. Chacun ses responsabilités, tu verras, tu me remercieras dans 6 mois.

Consignes du Service Informatique

Voici les consignes du service informatique d'une boite anonyme retrouvées sur le site de citation DansTonChat.

On retrouve les erreurs habituelles que font les utilisateurs envers leurs informaticiens, et l'incompréhension que cela engendre. Même teinté d'ironie, ces consignes sont profondément justes, et une bonne image de ce que l'on peut ressentir face aux utilisateurs.

Voir la citation sur le site original.

Consignes du Service Informatique

1. Quand vous nous appelez pour déplacer votre ordinateur, rappelez-vous toujours de le recouvrir préalablement d'une demie tonne de cartes postales, de photos de bébés, d'animaux empaillés, de fleurs séchées, de trophées de fléchettes et de dessins d'enfants. On n'a pas de vie personnelle et on apprécie grandement de voir la votre exposée ainsi.
2. Quand une personne du service informatique vous dit qu'il arrive de suite, allez prendre un café. De cette façon, vous ne serez pas la quand on aura besoin de votre mot de passe. Ce n'est rien pour nous de retenir 300 mots de passe...
3. Quand vous avez un problème avec votre P.C. à la maison, déposez-le en vrac sur un siège au service informatique, sans surtout indiquer votre nom, votre numéro de téléphone et la description du problème. On adore les énigmes.
4. Quand un membre du personnel informatique vous dit qu'il arrive bientôt, prenez une voix blessante et dites : "Vous voulez dire combien de semaines, par bientôt ?" Ça nous motive.
5. Si l'imprimante n'imprime pas, recommencez l'impression au moins 20 fois. Les travaux d'impression tombent souvent dans des trous noirs.
6. Si l'imprimante n'imprime toujours pas au bout des 20 tentatives, envoyez l'impression à toutes les 68 imprimantes de l'entreprise. L'une d'elles doit marcher.
7. N'apprenez jamais la dénomination correcte pour quoi que ce soit de technique. On sait exactement à quoi vous vous référez par " mon bidule a foire " ou " mon pc plante ".
8. N'utilisez jamais l'aide en ligne pour répondre aux plus simples de vos questions. L'aide en ligne, c'est pour les lopettes.
9. Si le câble de votre souris n'arrête pas de renverser le cadre de la photo de votre chien, soulevez l'ordinateur et fourrez le câble en dessous. Ces câbles ont été conçus pour résister à la pression de 10 kg de matériel informatique.
10. Si la barre d'espacement de votre clavier ne marche plus, accusez la mise à jour du client de messagerie. Les claviers sont en fait très heureux avec une demie tonne de miettes de gâteaux dedans.
11. N'hésitez surtout pas à dire des choses comme "Je comprends rien à toutes ces conneries d'ordinateurs". Ça ne nous gène pas du tout d'entendre que notre domaine d'expertise professionnelle est une connerie.
12. Si vous avez besoin de changer le toner d'encre dans une imprimante, appelez le service informatique. Changer le toner est une tâche extrêmement complexe et les constructeurs recommandent qu'elle soit effectuée par un ingénieur professionnel avec une maîtrise en physique nucléaire.
13. Si votre ordinateur ne s'allume pas, venez vous plaindre à nous avant de vérifier s'il est correctement branché.
14. Quand vous recevez un film de 30 Mo, envoyez-le à tout le monde dans l'entreprise en pièce attachée. On a plein d'espace disque sur ce serveur de messagerie.
15. Quand vous tombez sur une personne du service informatique le samedi au supermarché, posez une question à propos d'ordinateur. On travaille aussi le week-end et les jours fériés.

danstonchat.com

Servez moi de l’HTML

Analysons ce magnifique dessin issu d'un billet du blog Humeurs illustrés d'un enseignant chercheur par Luc Damas, Maître de conférence et professeur d'informatique.

Servez moi de l’HTML

Ce dessin récapitule les différentes phases de service d'un site internet en utilisant la métaphore d'un bar :

• Browser <-> Verre
• HTML <-> Bière
• JavaScript <-> Paille
• PHP <-> Tireuse
• MySQL <-> Fût
• File <-> Perrier

Partons du début. Vous accédez à internet, et un site s'affiche. Le site s'affiche sur votre Browser, aussi appelé navigateur : Chrome, Firefox ou bien Internet Explorer. Le browser c'est votre verre, c'est ce qui permet de contenir la bière que vous allez boire : le texte du blog, l'email du pote, la photo de Facebook. Bien sûr, on est pas toujours d'accord pour boire dans le même verre que les autres. Dans le beaujolais, le vin, c'est dans un verre à ballon, pas dans une flûte de champagne. Chacun à ces préférences pour le choix du verre, mais n'oubliez pas que Internet Explorer, IE, est représenté ici par un verre en plastique troué.

La bière, le contenu, c'est de l'HTML. C'est la base, l’élément fondamental, c'est ce qui remplit le navigateur, et votre verre. Ça contient le texte, les couleurs, la mise en page, etc...

Ajoutons un truc un peu funky, une paille ! Ou une ombrelle, des glaçons, un peu de sirop. C'est le JavaScript. Ce n'est pas du contenu, c'est une amélioration, un truc qui rend la visite des pages web plus agréable, on parle de page web dynamique, ou de web 2.0. Ça permet aussi de rafraîchir la bière quand c'est un glaçon. C'est tout ce qui se met à bouger sur votre écran : animations, menus déroulant, rafraîchissement automatique des pages, chat en live.

Tout ça c'est sur votre table, ça se passe de votre côté, le serveur vous a tout posé là comme il fallait. Mais que se passe-t-il de l'autre côté du bar ? Que se passe-t-il côté serveur ? Tout ce qui ne se passe pas sur votre ordinateur et que vous ne voyez pas.

Nous avons en premier lieu le PHP (la tireuse à bière) ou Java, .Net, Ruby... On appelle ça le langage coté serveur. C'est la moulinette qui sert à servir la bière du fût dans votre verre. C'est le mécanisme qui prend les informations de la base de données pour les transformer en HTML.

Le fût justement sous le comptoir, c'est la base de données. C'est là que sont stockés toutes les données : contenu des messages Facebook, des mails, des articles de journaux. Ça peut être MySQL, Oracle, SQL Server. Vous imaginez la taille du fût pour une entreprise tel que Google !

Enfin, pour les petits à côté, la petite bouteille de Perrier, ou la canette de coca, on a des fichiers (File) stockés sur le serveur, coté bar, qui vont vous être servi à la demande, mais qui ne sont pas stockés en base de données. C'est le cas des vidéos, des images, des animations flash. Dans un bar, le coca et le Perrier ne sont pas stockés dans des fûts uniquement pour des raisons pratiques. Rien n'empêche de stocker des fichiers dans des bases de données, c'est juste pas pratique.

Par exemple, le message de ce blog vous aura servi beaucoup de texte, stocké en base de donnée, dans le fût donc, et 2 images, stockées dans des fichiers, qui vous sont servi à part. Le JavaScript est présent dans les boutons de partage Facebook. Votre browser est majoritairement Chrome selon les statistiques, un peu de Firefox et très peu d'Internet Explorer.

On a bien le demi-pêche avec des cacahuètes et des pistaches, de quoi passer un bon moment !