WizBlog

Allez je prends dans l'ordre où ça sort de enveloppe

• Eva Joly : des lunettes, oui elle va en avoir besoin pour voir où va l'écologie avec le score qu'ils vont avoir ...
• Marine Le pen : sourire crispé, fond bleu, bigre ça doit être l'affiche la moins expressive de toute ^^
• Nicolas Sarkozy : au fond l'océan, quel visionnaire : il a déjà pris le large !
• Jean-Luc Mélenchon : rien à dire, c'est rouge communiste :)
• Philippe Poutou : ça doit être le seul naturel, mal rasé, au naturel.
• Nathalie Artaud : travailleur, travailleuse
• Jacques Cheminade : un fond d'usine... mais attendez 3 candidats, non 4 candidats contre le grand capital ! Va falloir m'expliquer...
• François Bayrou : costard cravate, un beau sourire, un regard sur sa gauche : il a raison c'est de là qu'il a ses meilleurs chances pour se rallier :)
• Nicolas Dupont-Aignan : deuxième page "libérons-nous de l'Europe des banquiers"... et de 5, mais bordel 50% de candidats anti-banque et pas foutu de se mettre d'accord.
• François Hollande : un fond de paysage verdoyant : ça doit être l'accord secret avec les écologistes pour les législatives, malheureusement il a tout faux, les accords seront rouge avec le Front de Gauche.

Excellent repas, Patron très sympa ! En plus pas trop cher, excellent qualité/prix !

Ragno d'oro

Via silla, 26 - roma

www.ragnodoro.org

Joyeux anniversaire le timer UNIX !!!! 1300000000 secondes !

(http://www.unixtimestamp.com/index.php)

En 2009, le monde a dépensé 1 531 milliards de dollars dans l'armement. Si l'on considère que pour envoyé un kilo en orbite géostationnaire autour de la terre il faut dépenser 20 000 dollars, alors on peut envoyer chaque année près de 76000 tonnes de matériel dans l'espace. Cette capacité permettrait de lancer un porte-avion par an dans l'espace avec plusieurs milliers de personnes à bord ! Avec cela nous pourrions coloniser l'espace, que l'on arrête donc de construire des bateaux et des avions qui ne servent à rien et tentons notre chance dans l'espace. De plus cette industrialisation massive permettrait de faire chuter le prix du kilo envoyé dans l'espace et donc d'accélérer le mouvement. Mieux vaut se concentrer sur la colonisation du système solaire plutôt que sur d'illusoire conquête sur Terre.

Comme vous avez pu le constater les stations sont à secs et ce n'est pas près de s'arrêter. Ceci pour plusieurs raisons simples :

• l'ensemble des réservoirs des véhicules français est supérieur au stock des stations services. Vous faites moins souvent le plein que les stations services et les stations services sont une industrie et ont ce qu'il faut pas 5 fois le nécessaire.
• l'ensemble des français veulent faire le plein et le vide des réservoirs est supérieurs aux stocks des stations services. Et ils vont le faire tous les jours tout le temps dès qu'ils verront une station avec de l'essence, ce sera sans fin jusqu'à ce que les stocks et les réservoirs soient à nouveau à un niveau confortable
• les capacités d'approvisionnement ne sont pas disproportionné et sont équivalentes à la consommation. Encore une fois c'est une industrie et même un business. Donc avec les blocages, la capacité va aller sous la demande et donc créer un manque encore plus grand !

Voilà un fichier Excel, le même en version OOO, où j'ai posé mes réflexions, on peut voir les choses suivantes

• Si les capacités d'approvisionnement sont diminuées de 10%
  • il faudra plus de 50 jours pour que l'ensemble du pays soient à sec (ça laisse de la marge)
  • Au bout de 10 jours, 0.5% du pays sera à sec
• Si les capacités d'approvisionnement sont diminuées de 25%
  • il faudra 35 jours pour que l'ensemble du pays soient à sec
  • Au bout de 5 jours, 2% du pays ne pourra plus faire le plein
  • Au bout de 10 jours, 10% du pays ne pourra plus faire le plein
• Si les capacités d'approvisionnement sont diminuées de 75% il ne faudra que 15 jours pour que l'ensemble du pays soient à sec
  • il faudra 15 jours pour que l'ensemble du pays soient à sec
  • Au bout de 5 jours, 59% du pays ne pourra plus faire le plein
  • Au bout de 10 jours, 75% du pays ne pourra plus faire le plein

Le retour à la normale si les capacités d'approvisionnement sont diminuées de 10% sur 10 jours sera de 5 jours ce qui est tout de même conséquent.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 40 - ne faire qu'une chose

UNE FONCTION DOIT FAIRE UNE SEULE CHOSE. ELLE DOIT LA FAIRE BIEN ET NE FAIRE QU’ELLE.

Page 45 - nombre d'argument doit être le plus faible possible

Idéalement, le nombre d’arguments d’une fonction devrait être égal à zéro (niladique). Ensuite viennent les fonctions à un argument (monadique, ou unaire), puis à deux arguments (diadique). Les fonctions à trois arguments (triadique) doivent être évitées autant que possible. Les fonctions qui prennent plus de trois arguments (polyadique) exige une très bonne raison ou ne doivent jamais être employées.

Page 55 - écrire un logiciel comme un article

L’écriture d’un logiciel ressemble à n’importe quelle autre sorte d’écriture. Lorsque nous écrivons un article, nous commençons par coucher nos idées, puis nous les triturons jusqu’à obtenir une lecture fluide. Le premier bouillon est souvent maladroit et mal organisé. Par conséquent, nous travaillons le texte, le restructurons et le remanions jusqu’à ce qu’il se lise comme nous le souhaitons.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 60 - pour pallier notre incapacité

Les commentaires sont bien employés lorsqu’ils pallient notre incapacité à exprimer nos intentions par le code. Notez que j’emploie le mot incapacité, car les commentaires masquent toujours nos échecs. Nous en avons besoin car nous ne parvenons pas toujours à nous exprimer sans eux, mais nous ne devons pas être fiers de les utiliser.

Page 70 - Commentaires obligés

La règle stipulant que chaque fonction doit disposer d’une documentation Javadoc est totalement stupide, tout comme celle obligeant à commenter chaque variable. Les commentaires de ce type ne font qu’encombrer le code, propager des mensonges et conduire à une confusion et à une désorganisation générales.

Page 78 - Documentation Javadoc dans du code non public

Si la documentation Javadoc est très utile pour des API publiques, elle est à condamner pour le code privé. La génération des pages Javadoc pour les classes et des fonctions internes au système se révèle généralement inutile et la solennité supplémentaire des commentaires Javadoc n’apporte rien d’autre que du superflu et une distraction.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

page 15 - auteur

Le champ @author de Javadoc indique qui nous sommes : les auteurs. Les auteurs ont pour caractéristique d’avoir des lecteurs. Les auteurs ont pour responsabilité de bien communiquer avec leurs lecteurs. La prochaine fois que vous écrirez une ligne de code, n’oubliez pas que vous êtes un auteur qui écrit pour des lecteurs qui jugeront votre travail.

Page 84 - présentation uniforme

Vous devez faire attention à ce que votre code soit parfaitement présenté. Vous devez choisir un ensemble de règles simples qui guident cette mise en forme et les appliquer systématiquement. Si vous travaillez au sein d’une équipe, tous les membres doivent se mettre d’accord sur un ensemble de règles de mise en forme et s’y conformer. Un outil automatique qui applique ces règles de mise en forme à votre place pourra vous y aider.

Page 93 - rangement vertical

En général, nous préférons que les dépendances d’appel de fonctions se fassent vers le bas. Autrement dit, une fonction appelée doit se trouver en dessous d’une fonction qui l’appelle2. Cela crée un agréable flux descendant dans le module du code source, en allant des fonctions de haut niveau vers les fonctions de bas niveau.

Page 148 - Organiser une classe

Selon la convention standard en Java, une classe doit débuter par une liste des variables. Les constantes statiques publiques, si elles existent, viennent en premier. Suivent ensuite les variables statiques privées, puis les variables d’instance privées. Les bonnes raisons d’ajouter des variables publiques sont rares. Les fonctions publiques doivent suivre la liste des variables. En général, nous plaçons les fonctions privées invoquées par une fonction publique immédiatement après celleci. Cette approche est conforme à la règle de décroissance et permet de lire le programme comme un article de journal.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 105 - différence entre structures et objets

Les objets cachent leurs données derrière des abstractions et fournissent des fonctions qui manipulent ces données. Les structures de données exposent directement leurs données et ne fournissent aucune fonction significative. Ces deux concepts sont virtuellement opposés. La différence peut sembler évidente, mais ses implications sont profondes.

Page 107 - la dichotomie fondamentale entre les objets et les structures de données

la dichotomie fondamentale entre les objets et les structures de données :

Un code procédural (un code qui utilise des structures de données) facilite
l’ajout de nouvelles fonctions sans modifier les structures de données existantes.
Un code orienté objet facilite l’ajout de nouvelles classes sans modifier
les fonctions existantes.

L’inverse est également vrai :

Un code procédural complexifie l’ajout de nouvelles structures de données
car toutes les fonctions doivent être modifiées. Un code orienté objet
complexifie l’ajout de nouvelles fonctions car toutes les classes doivent être
modifiées.

Par conséquent, ce qui est difficile pour l’orienté objet est facile pour le procédural, tandis que ce qui est difficile pour le procédural est facile pour l’orienté objet !

Page 109 - structures hybride

Cette confusion conduit parfois à des structures hybrides malheureuses qui sont pour moitié des objets et pour moitié des structures de données.

...

Avec de tels hybrides, il est difficile d’ajouter non seulement de nouvelles fonctions, mais également de nouvelles structures de données. Ils représentent le pire des deux mondes. Vous devez absolument éviter d’en créer. Ils sont signes d’une conception confuse dans laquelle les auteurs ne sont pas certains ou, pire, ne savent pas s’ils doivent protéger les fonctions ou les types.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 130 - tests d'apprentissage

Les tests d’apprentissage ne coûtent finalement rien. Nous devions apprendre l’API, et l’écriture de ces tests nous a permis d’obtenir ces connaissances facilement et en toute indépendance. Les tests d’apprentissage étaient des expériences précises qui nous ont aidés à améliorer notre compréhension.

Page 135 - Les trois lois du TDD (Test Driven Development)

Première loi. Vous ne devez pas écrire un code de production tant que vous n’avez pas écrit un test unitaire d’échec.

Deuxième loi. Vous devez uniquement écrire le test unitaire suffisant pour échouer ; l’impossibilité de compiler est un échec.

Troisième loi. Vous devez uniquement écrire le code de production suffisant pour réussir le test d’échec courant.

...

Si nous travaillons de cette manière, nous écrivons des dizaines de tests par jour, des centaines de tests par mois et des milliers de tests par an.

Page 136 - code de test est important

le code de test est aussi important que le code de production.

Page 144 - créer un langage de test

... J’essaie habituellement de créer un langage de test spécifique au domaine qui la prend en charge ...

Page 145 - F.I.R.S.T. (Matériel pédagogique d’Object Mentor.)

Les tests propres suivent cinq autres règles qui forment l’acronyme précédent :

Fast (rapide). Les tests doivent être rapides. Lorsque des tests s’exécutent lentement, il est peu probable qu’ils soient lancés fréquemment. Lorsque les tests ne sont pas exécutés très souvent, il est impossible de trouver les problèmes suffisamment tôt pour les corriger facilement. Vous n’êtes pas aussi libre de nettoyer le code, et il finit par se dégrader.

Independent (indépendant). Les tests ne doivent pas dépendre les uns des autres. Un test ne doit pas établir les conditions d’exécution du test suivant. Vous devez être en mesure d’exécuter chaque test indépendamment et dans l’ordre que vous voulez. Lorsque des tests dépendent l’un de l’autre, le premier qui échoue provoque une cascade d’échecs en aval rendant difficile le diagnostic et masquant les défauts en aval.

Repeatable (reproductible). Les tests doivent pouvoir être reproduits dans n’importe quel environnement. Vous devez être en mesure d’exécuter les tests dans l’environnement de production, dans l’environnement de contrôle de qualité et sur votre portable pendant que vous êtes dans le train sans connexion réseau. Si vos tests ne sont pas reproductibles dans n’importe quel environnement, vous aurez toujours une excuse pour leur échec. Vous serez également incapable de les exécuter lorsque l’environnement n’est pas disponible.

Self-Validating (auto validant). Les tests doivent avoir un résultat binaire : ils réussissent ou ils échouent. Vous ne devez pas avoir à consulter un fichier de journalisation ou comparer manuellement deux fichiers texte différents pour savoir si les tests ont réussi. Si les tests ne sont pas auto validants, l’échec peut alors devenir subjectif et l’exécution des tests peut exiger une longue évaluation manuelle.

Timely (au moment opportun). Les tests doivent être écrits au moment opportun. Les tests unitaires doivent être écrits juste avant le code de production qui permet de les réussir. Si vous écrivez les tests après le code de production, vous constaterez qu’il sera difficile de tester ce code. Vous pourriez décider qu’un code de production est trop complexe à tester. Vous pourriez ne pas concevoir le code de production pour qu’il puisse être testé.

Page 184 - conception "simple"

Selon Kent, une conception est "simple" lorsqu’elle respecte les quatre règles suivantes, données par ordre d’importance :

• elle réussit tous les tests ;
• elle ne contient aucune redondance ;
• elle exprime les intentions du programmeur ;
• elle réduit le nombre de classes et de méthodes.

Nuance page 189

Cependant, n’oubliez pas que cette règle est la dernière des quatre règles de conception simple et qu’elle est donc la moins prioritaire. Par conséquent, même s’il est important de réduire au maximum le nombre de classes et de fonctions, il est plus important d’avoir des tests, de supprimer la redondance et d’améliorer l’expressivité.

Page 188 - soigner votre travail

Vous devez donc soigner votre travail. Passez un peu de temps sur chaque fonction et chaque classe. Choisissez de meilleurs noms, décomposez les longues fonctions en fonctions plus courtes et, de manière générale, prenez soin de ce que vous créez. L’attention est une ressource précieuse.

Page 195 - Concurrence

• Le code lié à la concurrence possède son propre cycle de développement, de changement

et de réglage.

• Le code lié à la concurrence présente ses propres défis, qui sont différents, et

souvent plus complexes, de ceux du code non liés à la concurrence.

• Les causes de dysfonctionnement du code concurrent mal écrit suffisent amplement

à compliquer son écriture, sans même prendre en compte la complexité du code de l’application elle-même.

Recommandation : gardez le code lié à la concurrence séparé de tout autre code.

Page 203 - ne considérez pas les dysfonctionnements du système comme des cas uniques.

Recommandation : ne considérez pas les dysfonctionnements du système comme des cas uniques.

Page 268 - un code qui fonctionne n'est pas suffisant

Il ne suffit pas que le code fonctionne. Un code opérationnel masque souvent des dysfonctionnements. Les programmeurs qui se satisfont d’un code simplement opérationnel ne sont pas de véritables professionnels. Ils craignent sans doute de ne pas avoir suffisamment de temps pour améliorer la structure et la conception de leur code, mais je ne suis pas d’accord. Rien n’a un effet aussi négatif sur un projet de développement que du mauvais code. Les plannings erronés peuvent être refaits, les exigences imprécises peuvent être réétudiées, une mauvaise dynamique d’équipe peut être reconstruite. En revanche, le mauvais code pourrit et fermente, puis se transforme en un fardeau qui mène l’équipe à sa perte. J’ai rencontré de nombreuses équipes réduites à progresser péniblement car, dans leur hâte, elles avaient créé un véritable tas de code malveillant qui avait pris les rênes de leur destinée.

Le mauvais code peut évidemment être nettoyé. Toutefois, cette opération est très onéreuse. Plus le code se dégrade, plus les modules s’immiscent les uns dans les autres, en créant de nombreuses dépendances cachées et embrouillées. Retrouver et rompre les anciennes dépendances est une tâche longue et ardue. À l’opposé, conserver un code propre se révèle relativement facile. Si, le matin, vous mettez la pagaille dans un module, il est facile de le nettoyer dans l’après-midi. Mieux encore, si vous avez créé un désordre cinq minutes plus tôt, il est très facile de tout ranger immédiatement.

La solution consiste donc à conserver en permanence un code aussi propre et aussi simple que possible. Ne laissez jamais la gangrène s’installer.

Page 356 - verrouillage côté serveur est à privilégier

Voici les raisons de préférer, en général, le verrouillage côté serveur :

• Le code redondant est réduit. Le verrouillage côté client impose à chaque client de

verrouiller correctement le serveur. En plaçant le code de verrouillage dans le serveur, les clients peuvent employer l’objet sans avoir à écrire du code de verrouillage supplémentaire.

• Les performances peuvent être améliorées. Vous pouvez remplacer un serveur sûr

vis-à-vis des threads par un serveur non sûr vis-à-vis des threads dans le cadre d’un déploiement monothread, en évitant ainsi tous les surcoûts.

• Les possibilités d’erreur sont diminuées. Il suffit qu’un seul programmeur oublie de

verrouiller pour conduire au dysfonctionnement du système.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 24 - utiliser des fabriques statiques

Lorsque des constructeurs sont surchargés, nous devons utiliser des méthodes de fabrique statiques avec des noms qui décrivent les arguments. Par exemple, Complex fulcrumPoint = Complex.FromRealNumber(23.0); est généralement préférable à Complex fulcrumPoint = new Complex(23.0); Pour imposer l’emploi de ces méthodes de fabrique, les constructeurs correspondants doivent être rendus privés.

Page 43-44 - les instructions switch ne doivent apparaitre qu'une fois

Voici ma règle générale concernant les instructions switch : elles peuvent être tolérées uniquement lorsqu’elles apparaissent une seule fois, sont employées pour créer des objets polymorphes et sont cachées derrière une relation d’héritage, de manière que le reste du système ne puisse pas les voir (FABRIQUE ABSTRAITE GOF). Bien entendu, chaque cas est unique et il m’arrive parfois de ne pas respecter certaines parties de cette règle.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 24 - les programmeurs sont des personnes intelligentes

En général, les programmeurs sont des personnes plutôt intelligentes. Parfois, les personnes intelligentes aiment exhiber leur intelligence en montrant leur capacité de jonglage mental. En effet, si vous pouvez mémoriser sans faillir le fait que r est la version en minuscule de l’URL dans laquelle l’hôte et le schéma ont été supprimés, alors, vous devez certainement être très intelligent.

Page 29 - Ne pas faire le malin

Si les noms sont trop astucieux, ils ne seront mémorisés que par les personnes qui possèdent le même sens de l’humour que l’auteur, et uniquement aussi longtemps qu’elles se souviendront de la blague. Sauront-elles déterminer le rôle de la fonction HolyHandGrenade (littéralement, SainteGrenadeAMain) ? Si, pour certains, cela peut sembler malin, il est sans doute préférable de retenir le nom Delete Items dans ce cas. Mieux vaut privilégier la clarté à l’humour.

Dans le code, les jeux d’esprit prennent souvent la forme d’expression familière ou d’argot. Par exemple, nous déconseillons l’emploi du nom whack() (littéralement, pan()) à la place de kill(). De même, les blagues liées à une culture doivent être évitées, comme eatMyShorts() (en référence à Bart Simpson) pour abort().

Dites ce que vous pensez. Pensez ce que vous dites.

Page 59 - Ne commentez pas le mauvais code, récrivez-le.

Ne commentez pas le mauvais code, récrivez-le.
— Brian W. Kernighan et P. J. Plaugher [KP78, p. 144]

Page 83-84 - la qualité du code est un avant goût de la qualité du projet

Si quelqu’un soulève le voile, nous voulons qu’il soit impressionné par l’élégance, la cohérence et l’attention portée aux détails dans ce qu’il voit. Nous voulons qu’il soit frappé par l’ordre. Nous voulons qu’il s’étonne lorsqu’il parcourt les modules. Nous voulons qu’il perçoive le travail de professionnels. S’il voit à la place une quantité de code embrouillé qui semble avoir été écrit par une bande de marins soûls, il en conclura certainement que le même je-m’en-foutisme sous-tend chaque autre aspect du projet.

Page 135 - Garder des tests propres

Il y a quelques années, on m’avait demandé de diriger une équipe qui avait expressément décidé que son code de test ne devait pas présenter le même niveau de qualité que son code de production. Elle acceptait que toutes ses règles de codage soient transgressées dans les tests unitaires. Le mot d’ordre était "vite fait mal fait". Il était inutile de bien nommer les variables, il était inutile d’écrire des fonctions de tests courtes et descriptives. Le code de test n’avait pas besoin d’être parfaitement conçu et consciencieusement cloisonné. Tant que le code de test fonctionnait et tant qu’il couvrait le code de production, il affichait une qualité suffisante.

Cependant, cette équipe n’avait pas compris que les tests grossiers étaient équivalents, sinon pires, à aucun test. En effet, les tests doivent évoluer avec le code de production. Plus les tests sont négligés, plus il est difficile de les modifier. Plus le code de test est embrouillé, plus le temps nécessaire à l’ajout de nouveaux tests dépassera celui nécessaire à écrire le nouveau code de production. Si vous modifiez le code de production, les anciens tests commencent à échouer et, en raison du code de test désordonné, il est plus difficile de les faire réussir à nouveau. Les tests deviennent alors un handicap de plus en plus important.

De version en version, le coût de maintenance de la suite de tests développée par mon équipe ne faisait qu’augmenter. Elle a fini par devenir l’unique sujet de grief chez les développeurs. Lorsque les managers ont demandé aux développeurs pourquoi leurs estimations étaient si grandes, ils ont accusé les tests. Finalement, ils ont été obligés d’abandonner l’intégralité de la suite de tests.

Cependant, sans une suite de tests, ils n’avaient plus la possibilité de vérifier que les modifications de la base de code ne remettaient pas en cause le fonctionnement. Sans les tests, ils ne pouvaient plus savoir si des modifications apportées à une partie du système ne créaient pas des dysfonctionnements dans d’autres parties. Par conséquent, leur taux d’échec a commencé à augmenter. En raison de cette recrudescence de défauts involontaires, ils ont commencé à craindre les modifications. Ils ont arrêté de nettoyer le code de production car ils avaient peur que les changements fassent plus de mal que de bien. Le code de production a commencé à se dégrader. Pour finir, ils n’avaient plus de tests, le code de production était embrouillé et criblé de bogues, les clients étaient mécontents et les développeurs avaient le sentiment que leurs efforts sur les tests étaient la raison de leur échec.

En un sens, ils n’avaient pas tort. Les tests ont bien été à l’origine de leur échec, mais uniquement pour avoir choisi d’accepter des tests négligés. S’ils avaient décidé de garder des tests propres, leur travail sur les tests ne les aurait pas conduits à l’échec. Je peux l’affirmer sans faillir car j’ai intégré et encadré de nombreuses équipes couronnées de succès qui employaient des tests unitaires propres.

La morale de cette histoire est simple : le code de test est aussi important que le code de production. Il ne représente pas un travail de seconde zone. Il exige réflexion, conception et soin. Il doit rester aussi propre que le code de production.

Un code qui fonctionne n'est pas suffisant

Page 151

Cependant, nous sommes trop nombreux à penser que le travail est terminé lorsque le programme fonctionne. Nous laissons tomber notre deuxième préoccupation, c’est-à-dire l’organisation et la propreté. Nous passons directement au problème suivant au lieu de revenir en arrière et de décomposer les classes surchargées en entités découplées possédant une seule responsabilité.

Page 217

La plupart des programmeurs novices, comme la plupart des élèves sortis du collège, ne suivent pas parfaitement ce conseil. Ils pensent que l’objectif premier est d’obtenir un programme opérationnel. Dès que c’est le cas, ils passent à la tâche suivante, en laissant le programme "opérationnel" dans l’état qui lui a permis de fonctionner. La plupart des programmeurs expérimentés savent que cela s’apparente à un suicide professionnel.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

Page 22 - Appelez un chat un chat

Pour faire référence à des groupes de comptes, vous pouvez choisir accountList uniquement s’il s’agit bien d’une liste (List). Le mot liste possède un sens précis pour les programmeurs. Si le conteneur qui stocke les comptes n’est pas un List, le nom pourrait conduire à de fausses conclusions2. Ainsi, accountGroup, bunchOfAccounts ou simplement accounts sont mieux adaptés.

Page 24 - Nom des classes

Le préfixe I, si classique dans les listings anciens, représente, au mieux, une distraction et, au pire, trop d’informations. Je ne souhaite pas que les utilisateurs sachent qu’ils passent par une interface. Je veux simplement qu’ils sachent qu’il existe un ShapeFactory. Par conséquent, si je dois codifier l’interface ou l’implémentation, j’opte pour l’implémentation. Il est préférable de la nommer ShapeFactoryImp, voire l’horrible CShapeFactory, que de codifier l’interface.

...

Pour les classes et les objets, nous devons choisir des noms ou des groupes nominaux comme Customer, WikiPage, Account ou AddressParser. Il est préférable d’éviter les termes Manager, Processor, Data ou Info dans le nom d’une classe. Un nom de classe ne doit pas être un verbe.

...

Page 29 - Standard de nommage

Pour les méthodes, nous devons choisir des verbes ou des groupes verbaux comme postPayment, deletePage ou save. Les accesseurs, les mutateurs et les prédicats

doivent être nommés d’après leur valeur et préfixés par get, set ou is conformément au standard JavaBean5.

Page 34 - ne pas craindre de renommer

Les gens ont également peur de renommer les choses, de crainte que d’autres développeurs soulèvent des objections. Nous ne partageons pas cette crainte et sommes plutôt reconnaissants lorsque les noms changent (en mieux). La plupart du temps, nous ne mémorisons pas réellement les noms des classes et des méthodes. Nous employons les outils modernes pour prendre en charge ces détails et pouvoir nous focaliser sur un code qui doit se lire aussi facilement que des paragraphes et des phrases, tout au moins comme des tableaux et des structures de données (une phrase n’est pas vraiment le meilleur moyen d’afficher des données). Vous surprendrez probablement quelqu’un si vous changez des noms, mais pas plus que par n’importe quelle autre amélioration du code. Ne le laissez pas vous empêcher de suivre votre voie.

Page 150 - attention à ne pas rendre ambigus

les noms de classes qui comprennent des mots ambigus, comme Processor, Manager ou Super, font souvent allusion à un cumul regrettable de responsabilités.

J'ai lu le livre Coder proprement de Robert C. Martin Lien PDF, et c'est un excellent ouvrage pour avoir la réponse à : "qu'est ce que bien coder ?" ou "pourquoi un informaticien fait de l'artisanat plutôt que du travail à la chaîne ?". En tout cas, je le recommande à tous développeur, et même à toute personne gérant un projet informatique.

Je vais faire une suite de billet qui seront les extraits qui m'ont paru capitale dans le livre.

Extrait du livre Coder proprement de Robert C. Martin Lien PDF

page 6

Quid des exigences ? Quid des échéances ? Quid des directeurs stupides et des types inutiles du marketing ? Ne portent-ils pas une certaine faute ?

Non. Les directeurs et les responsables marketing nous demandent les informations dont ils ont besoin pour définir leurs promesses et leurs engagements. Et, même s’ils ne nous interrogent pas, nous ne devons pas éviter de leur dire ce que nous pensons. Les utilisateurs se tournent vers nous pour valider la manière dont les exigences se retrouveront dans le système. Les chefs de projet comptent sur nous pour respecter les échéances. Nous sommes totalement complices du planning du projet et partageons une grande part de responsabilité dans les échecs ; en particulier si ces échecs sont liés à du mauvais code !

"Mais, attendez !, dites-vous. Si je ne fais pas ce que mon chef demande, je serai licencié." Probablement pas. La plupart des directeurs veulent connaître la vérité, même s’ils ne le montrent pas. La plupart des directeurs veulent du bon code, même lorsqu’ils sont obsédés par les échéances. Ils peuvent défendre avec passion le planning et les exigences, mais c’est leur travail. Le vôtre consiste à défendre le code avec une passion équivalente.

Pour replacer ce point de vue, que penseriez-vous si vous étiez chirurgien et que l’un de vos patients vous demandait d’arrêter de vous laver les mains avant l’intervention car cela prend trop de temps ? Le patient est évidemment le chef, mais le chirurgien doit absolument refuser de se conformer à sa demande. En effet, il connaît mieux que le patient les risques de maladie et d’infection. Il ne serait pas professionnel (sans parler de criminel) que le chirurgien suive le patient.

Il en va de même pour les programmeurs qui se plient aux volontés des directeurs qui ne comprennent pas les risques liés au désordre.