mercredi 24 juillet 2013

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

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.

lundi 22 juillet 2013

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.

mercredi 17 juillet 2013

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é !



lundi 15 juillet 2013

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
{
}

vendredi 12 juillet 2013

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 q(x) est une propriété démontrable pour tout objet x de type T, alors q(y) est vraie pour tout objet y de type S tel que S est un sous-type de T.

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 !

mercredi 10 juillet 2013

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.


mardi 9 juillet 2013

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

vendredi 5 juillet 2013

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