Les idées révolutionnaires, c'est bien. Les réalisations révolutionnaires, c'est mieux

Quand je dis que je suis dans l'informatique, j'ai souvent ce genre de réaction. "Oh de toute façon aujourd'hui, il suffit d'avoir une bonne idée, et en se faisant racheter par Google, on devient millionnaire".

Facile.

Mince alors, il me manquerait des idées pour devenir millionnaire ? Passons sur le fait que des milliers de développeurs créent des applications tout les jours, et que 1 application tout les 3 mois qui se fait racheter, c'est peu. Beaucoup de candidats et très peu d'élus.

Concentrons nous sur cette histoire d'idée. Prenons WhatsApp, application rachetée 4 milliards par Facebook. Wahou, quel splendide idée ont-ils eu ? 4 milliards ! Ça doit être une sacrée bonne idée !!

Attention, ceci est une révélation incroyable sur les fonctionnalités fantastiques et révolutionnaires de l'application WhatsApp: 

/!\   WhatsApp permet d'envoyer des messages via un mobile en passant par internet   /!\

Incroyable, Formidable, Génial, Bravo !

En fait de nouvelles idées il n'y a pas. MSN ! ICQ ! GTalk ! Même Facebook !  Des chats via le net, ça a déjà existé, mais avec un mobile, c'était compliqué.

WhatsApp a amené une interface utilisateur simple, une application qui marche, pas de pub, gratuit. Le minimum de fioritures, pour un maximum de résultat.

Ce ne sont pas les idées révolutionnaires qui font gagner de l'argent. Prenez un truc qui existe déjà, faites le mieux, et gagner vos parts de marché, c'est tout !

Titanic, film aux multiples oscars. Bateau qui coule, lutte des classes, histoire d'amour, que des thèmes hyper abordés par des centaines de films. Avatar, un Pocahontas en 3D, rien de nouveau. La trilogie Batman de Christopher Nolan, combien de film de Batman ont déjà existé ? Et pourtant, cet trilogie à rapporté des milliards de dollars aux producteurs.

Ce ne sont pas les idées qui rapporte de l'argent, les chercheurs ne croulent pas sous l'argent. La réalisation, c'est tout ce qui compte. Choisissez une technologie qui déchire, à la pointe, avec des ingénieurs géniaux, mettez le prix dans votre recrutement, prenez une application qui fonctionne avec un public mais que vous trouvez lente/lourde/pas intuitive, ou qui n'existe pas sur mobile, et faite mieux.

Comment fonctionnent les crypto-monnaies ?

Depuis que de nombreux sites internet acceptent des paiements en Bitcoin, et que ce dernier est devenu plus cher que l'or à l'unité, vous avez surement du entendre parlé des crypto-monnaies.

Le principe n'est pas très compliqué. Imaginez vous que votre porte monnaie ressemble à une urne transparente, les mêmes que les jours d'élections.
Maintenant imaginez un champ d'urnes. Que dis-je, plusieurs milliers d'hectares d'urnes, toutes transparentes. Chacune est numérotée pour pouvoir la retrouver. Vous avez le droit de venir poser votre propre urne dans le champ. Tout le monde voit les urnes de tout le monde, et donc aussi ce qu'il y a dedans.

Votre urne est remplie de pièces et de billets. Votre urne est fermée par un cadenas, et vous êtes le seul à posséder la clé. Par contre, n'importe qui peut y mettre de l'argent. Si vous désirez vous faire payer par quelqu'un, il suffit de lui donner le numéro de l'urne qui est à vous, et l'acheteur viendra y mettre l'argent.
Inversement, si vous désirez payer quelqu'un, il vous suffit de vous rendre à votre urne, de l'ouvrir avec votre clé, de prendre l'argent et d'aller la mettre dans l'urne du vendeur.

Par contre, tout le monde voit ce que tout le monde fait. Et oui, on a du vous dire que les crypto-monnaies c'était le mal parce que c'était 100% anonyme. Pas du tout ! L'argent est très facile à suivre d'une urne à l'autre. Pour peu que l'on découvre l'identité d'une seule personne dans le réseau par un jeu de déduction, alors on pourra en identifier du monde. Il est fort probable que la NSA aient déjà identifié quelques acheteurs du marché noir à l'époque de Silk road (site fermé par le FBI où l'on pouvait acheter de la drogue et des armes au marché noir avec des Bitcoins).

Bitcoin

Voilà pour le principe des échanges. Maintenant, passons à comment est générée cette monnaie ? C'est un peu comme du voyeurisme sur une plage naturiste. Les personnes qui veulent gagner de l'argent virtuel doivent se positionner tout en haut de la dune pour voir toutes les urnes. Et là il faut épier tout ce que tout le monde fait. On appelle ça de la validation, mais bon, c'est plutôt du voyeurisme. Bref, il faut épier les mouvements d'argent et les consigner dans un grand carnet. C'est un grand carnet où l'on retrouve tout les mouvements d'argent d'urne à urne (le carnet qui intéresse beaucoup la NSA). Ce carnet est géré par tout le monde et tout le monde y a accès.

Il n'y a par contre qu'une seule personne qui peut écrire dans le carnet toutes les 10 minutes. Cette personne écrit toutes les transactions qu'elle a vu pendant ces 10 minutes. Pour son dur labeur, cette personne gagne 50 pièces, youhou !

Comment choisit-on cette personne ? Et bien c'est la première à avoir résolu un problème informatique. Le but est de trouver une solution à un problème qui ne sert à rien, un espèce de puzzle. Tout le monde peu jouer, mais il faut avoir un gros ordinateur pour avoir une chance de gagner.

La difficulté du problème s'ajuste en temps réel pour que en moyenne il faille 10 minutes pour le résoudre. Ainsi plus il y a de joueurs, plus le problème est compliqué (plus le puzzle est grand).

On appelle ça `miner`, un peu comme nos ancêtres qui allaient creuser des puits de charbon.

Donc on donne au vainqueur 50 pièces, et toutes les transactions qu'il a écrites dans le carnet sont considérées validées, et les urnes peuvent accepter les pièces. On recommence alors un nouveau puzzle qui aura lui aussi un prix de 50 pièces.

Entre le moment où vous payez le vendeur, et le moment où le vendeur a reçu l'argent, il peut se passer plus ou moins 10 minutes, ce qui en fait un système relativement rapide par rapport à des virements bancaires qui peuvent prendre 24 ou 48 heures. C'est le principale avantage, la rapidité de transfert sans aucun besoin de banque centralisée. Comme les transactions sont vérifiées par tout le monde, et que toutes les urnes sont transparentes, il n'y a quasiment aucune chance de piratage du système. Il faudrait qu'une seule personne arrive à remporter le jeu plusieurs fois de suite pour pourrir suffisamment le grand carnet de compte et y inscrire n'importe quoi. Mais c'est peu probable vu que la plupart des joueurs sont honnêtes.

Au niveau des risques, vous pouvez perdre votre numéro d'urne, et là... dommage. Mais comme généralement votre numéro d'urne est publique, vous aurez toujours un moyen de la retrouver.

Ce qui arrive le plus souvent, c'est de perdre la clé de l'urne. C'est ce qui est arrivé James Howells qui possède une urne de 7500 pièces. Problème, sa clé était sur son disque dur, qu'il a jeté aux ordures. James Howells est donc le malheureux possesseur d'une urne qui vaut plusieurs millions d'euros, mais qu'il ne pourra jamais ouvrir (le cadenas de l'urne est du genre solide, voir très très très solide).
On peut aussi vous voler la clé de votre cadenas, et là malheureusement, aucun recours. Le voleur pourra ouvrir votre urne et prendre l'argent pour le mettre dans une autre urne. Vous pourrez toujours essayer de tracer votre argent d'urne à urne sans jamais pouvoir le récupérer ! (Essayez de demander de l'aide à la NSA !)

Dogecoin

Il existe de nombreuses autres crypto-monnaies avec de petites différences. Les 3 principales sont Bitcoin, Litecoin et Dogecoin. Par exemple, Bitcoin écrit dans le carnet toutes les 10 minutes alors que Dogecoin écrit dedans toutes les minutes.
Il faut aussi préciser qu'il ne sera pas produit plus de 21 millions de bitcoins, et 100 milliard de dogecoins; la récompense pour avoir écrit dans le carnet diminuant progressivement au fur et à mesure que la monnaie est produite, jusqu'à atteindre 0 (en l'an 2140 pour Bitcoin). Dans ce cas les mineurs seront récompensés par des frais de transaction.

Lexique de correspondance entre la vulgarisation de l'article et ce que l'on retrouve officiellement :

• Une écriture dans le carnet de toutes les transactions en cours : block
• Le total de toutes les écritures dans le carnet : blockchain
• Une urne : portefeuille ou wallet
• Le numéro d'une urne : adresse
• La clé du cadenas d'urne : clé privée
• Un voyeur : mineur ou nœud du réseau
• Le puzzle à résoudre : preuve de travail ou proof of work
• Les 50 pièces gagnées pour avoir trouvé la solution du puzzle : récompense, incentive

Références :

• How the Bitcoin protocol actually works by Michael Nielsen
• Crypto-monnaie sur Wikipedia

Vidéo de présentation :

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.

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).

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 !

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 !