Note de lecture : Object-Oriented SSADM, par Keith Robinson & Graham Berrisford

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une vision d’un autre temps….

Je sais ce que vous allez me dire : « quel intérêt en 2012 de faire une note de lecture sur un vieux clou âgé de 18 ans et de toute façon obsolète ? ». L’histoire, mes amis, ceci est l’histoire. Cet ouvrage de 500 pages évoquant une méthode désormais délaissée fait partie de l’histoire des méthodes objet.

SSADM est une approche que l’on pourrait qualifier de « hautement structurée », voir même Tayloriste ! Elle s’appuie sur 3 schémas directeurs :

  • L’Internal Design : qui définit le schéma physique de la base de données, ainsi que les PDIs (process data interfaces).
  • L’External Design : Il comprend les définitions de format de données en I/O et les interfaces et dialogues utilisateurs
  • Le Conceptual Design : Définit les règles métier, le modèle comportemental de l’application et le modèle logique des données.

Les parties 2 à 5 de ce livre viennent étayer cette vision quelque peu complexe de la modélisation des systèmes d’information.

  • La seconde partie du texte « Le besoin d’avoir plus que la modélisation de données » nous présente les concepts classiques de la modélisation orientée objet, bien qu’avec des qualités pédagogiques assez moyennes, pour nous emmener vers la modélisation dynamique, plutôt pauvre d’ailleurs avec SSADM. Bref, ce n’est pas encore ici que l’on va crier au génie.
  • La troisième partie modestement appelée « Le besoin d’avoir plus que la modélisation OO » couvre les concepts classiques de la modélisation OO (encapsulation, héritage, etc..) pour terminer avec les besoins liés aux « grands » systèmes d’information. Chapitre peu convaincant au demeurant. Au suivant, donc.
  • La quatrième partie est consacrée au modèle conceptuel (c’est aussi la plus importante du livre). On y détaille donc finalement la notation SSADM dédiée à cet aspect. On y aborde la réutilisation (quelle blague !) et certains patterns liés à l’entity data modeling qui constitue des règles d’usage de SSADM, même si leur bien-fondé reste en partie assez mystérieux pour moi. L’event modeling qui y est abordé offre certaines perspectives mais me parait aussi assez difficile d’emploi en l’état.
  • La cinquième partie est dédiée à l’external design. Assez curieusement, c’est ici que je trouve le plus d’éléments intéressants, liés à l’utilisation de techniques « RAD » ou d’event-driven interfaces, bien que les notations soient parfois ardues.
  • La sixième partie est quand à elle consacrée aux autres discussions comme les besoins concernant les ateliers de modélisation ou la réutilisation (encore ?) à l’échelle de l’entreprise.

On ne peut reprocher à cet ouvrage le traitement de SSADM, ce qui lui vaut sa note. C’est à SSADM lui-même que l’on peut reprocher des choses : cette vision du développement logiciel appartient à une autre époque, pour autant que cela ait été applicable à une époque donnée ? Ce découpage en tâche avec un formalisme si peu adapté à l’esprit humain ne semble guère convenir. Toutes ces méthodes datant de la fin des années 80 nous packageaient ensemble notation et approche structurée. Qui plus est, ici, cette approche ne s’adapte qu’à des cas identifiés d’architectures logicielles.

Bref, dans le genre, je préfère Bertrand Meyer.

ObjectOriented-SSADM

Référence complète : Object-Oriented SSADM – Keith Robinson & Graham Berrisford – Prentice Hall 1994 – ISBN : 0-13-3094444-8

Object Oriented Ssadm


http://www.goodreads.com/book/add_to_books_widget_frame/0133094448?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

En finir avec le backlog ?

Le par addinquydans ArticlesLaisser un commentaire

Second volet de mon feuilleton “en finir avec…”. Ma victime du jour est le backlog.

Je rapelle mon mot d’avertissement : J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.

C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !

De la roadmap au backlog

Lors du premier opus, nous avons vu les conséquences d’une roadmap gérée en tant que portefeuille de projet: plan, stock, frein au changement, etc… Mais ce qui est vrai à grande échelle peut-il l’être à une échelle moindre ? Car le backlog ressemble au portefeuille de projet à plus petite échelle.

Nous considérons naturellement la backlog, brique fondamentale de Scrum, comme un outil agile indispensable. Qui penserait à le remettre en cause ?

Pourtant, dévié de sa bonne utilisation il peut avoir des conséquences néfastes.

Pourtant il peut servir à déguiser les anciennes pratiques.

Pourtant les conséquences évoquées ci-dessus ne sont pas seulement des travers d’usages, elles prennent naissance dans la nature intrinsèque du backlog. C’est un peu abstrait pour l’instant. On va illustrer tout ça.

Je veux un backlog complet

Tout d’abord, c’est quoi un backlog ?

“The backlog represent everything that anyone interested in the product or process has thought is needed or would be a good idea in the product” (1)

En clair toutes les idées qui pourraient s’avérer bonnes sont aptes à y figurer. Cela soulève plusieurs points :

  1. Est-ce que seuls les éléments qui vont être effectivement réalisés doivent figurer dans le backlog ?
  2. Le backlog doit-il comprendre initialialement tout ce qui sera réalisé ?
  3. A-t-on le droit de changer le backlog, et surtout d’y ajouter des choses passée la “phase initiale” ? Vous aurez noté les guillemets.

Ce sont de fausses questions car Scrum y répond. Pourtant j’y reviens car c’est déjà une source de travers.

Le backlog contient des éléments qui vont être effectivement réalisés

Scrum répond “non” à cette question. Il s’agit juste d’une liste de fonctionalités candidates.

D’un autre côté, Scrum nous invite à lister ce que les différents acteurs ont en tête à un moment donné. A créer du stock, aurais-je envie de dire (vous voyez certainement où je veux en venir), mais je reviendrais plus tard sur ce point.

Là où le bât blesse, c’est que ce backlog en son état initial correspond à un périmètre produit. Et le client souhaite souvent avoir une estimation de ce périmètre. En soi, aucun mal à cela. Sauf que le périmètre se transforme souvent en engagement, surtout quand le client n’est pas réellement agile. A partir de ce point, je vous souhaite bonne chance dans le monde merveilleux du suivi budgétaire. Je ne prend même pas la peine d’évoquer l’antagonisme entre le mode “suivi budgétaire” et la gestion du changement …

Le backlog initial est complet

Là aussi Scrum répond clairement “non”.

Sauf que là aussi, si ce backlog sert d’estimation initiale du projet, il vaut mieux ne pas être trop à côté de la plaque. Certes on pourra toujours troquer une fonctionnalité contre une autre… Mais qu’en est-il si les premières étapes du projet mettent en lumière de nouvelles idées, des aspects du fonctionnel qui onté été occulté ? Ou simplement des oublis ? A l’extrême on devrait être en mesure de “pivoter” comme l’on dit en language Lean Startup et c’est un des aspects que l’approche agile en général et Scrum en particulier permettent.

Mais ce backlog que l’on construit à l’avance à souvent tendance à se transformer en carcan.

Notre client pas très agile va arguer “faites des ajustements, mais il faut avoir une idée claire de là où l’on va au départ”. Eh bien non, ce n’est pas obligé. C’est certainement un confort si l’on peut, mais Scrum nous donne la flexibilité qu’il faut le cas échéant. On a quand même donné le bâton pour nous faire batttre avec ce foutu backlog…

Le backlog ne peut pas être changé

Là aussi Scrum est clair : “oui on peut le changer”. C’est même l’essence du processus de tirer profit du feedback pour le faire évoluer !

Oui, mais …

On a constitué cette (longue) liste, un processus coûteux en temps et en énergie. Cela va nous freiner dans une certaine mesure pour opérer des changements qui seront eux-même coûteux dans leur introduction mais aussi dans la remise en cause des items existants !

Bien sûr ce frein sera encore plus important dans le cas d’un changement radical. Il pourra même se transformer en blocage : “remettre en cause ? Alors que l’on a là une liste de fonctionnalités bien établies ?”

Je veux un backlog détaillé

Le backlog “complet” ne suffit même pas toujours pour démarrer un projet, surtout si l’on souhaite utiliser ce backlog pour effectuer une estimation comme je l’ai indiqué plus haut. Il nous faut alors savoir ce qu’il y a derrière chaque item afin d’avoir une idée valable de la complexité de celle-ci ! Vous l’avez probablement remarqué : on a déjà quitté Scrum depuis un certain temps. Mais qu’importe, on parle de backlog ! Tout va bien !

Cette affaire de backlog détaillé m’inspire trois choses.

Détailler

Détailler ou au moins rentrer dans le coeur de chaque fonctionnalité c’est échafauder le système alors que l’on a rien commencé, que rien ne peut nous aider à soutenir notre reflexion ou etayer nos hypothèses. J’ai fait référence au “lean startup” plus haut. Eux nous suggèrent de ne pas oublier que justement ce que nous appelons “expression des besoins” sont en fait des hypothèses. Personnellement, cela me rapelle une citation du “Mythical Man-Month”, elle s’adresse au developpeur mais pourrait aussi concerner celui qui construit le backlog : “Le programmeur, comme le poète, manie des abstractions voisines de la pensée pure. Il construit des cathédrales dans les airs, à partir de l’air lui-même, par le pouvoir de son imagination” (2). Construire des cathédrales dans les airs avec de l’air, c’est pas facile…

Faire mûrir

Ma seconde réflexion va vers ce que l’on apelle parfois le “mûrissement du backlog”. Vous avez peut-être déjà entendu cette expression : “il faut que ça mûrisse” ? Voilà qui nous invite à une petite pause bucolique.

frui-murSmall

Il y a bien sûr un concept derrière ça : c’est que quand une idée est seulement une ébauche, le simple passage du temps va permettre de rafiner l’idée qui tombera alors toute seule tel un fruit mûr ! C’est pas beau ? J’ai bien entendu de gros doutes sur ce processus spontané. Mes seules certitudes à ce propos sont:

  • Si on ne fait rien, il ne se passe rien.
  • La seule conséquence inéluctable du passage du temps, c’est la génération d’un délais.

Il existe des techniques, actives celles-ci, pour développer des idées à l’état d’ébauches :

  • Le brainstorming
  • L’expérimentation, que ce soit sur la base d’un prototype ou non.

On retrouve ces techniques dans les processus de développement orientées vers l’innovations comme le Design Thinking. Mais pour ça, il faut lâcher le backlog 5 minutes …

Backlog a.k.a. “cahier des charges”

Finalement, ce backlog complet et détaillé portait autrefois un nom: le cahier des charges. Par un effet pervers, nous avons reconstitué ici sous une forme certes différente, ce que nous voulions abandonner dans les anciennes approches. Il ne reste plus qu’à en confier la confection à une MOA (auquel on aura donné un autre nom) et on aura fait le tour !

Bien sûr Scrum ne dit pas du tout d’en arriver là. Mais il est tellement facile de glisser progressivement pour en revenir à ce que l’on faisait avant. Tout en se donnant bonne conscience, souvent même de bonne foi, car on apelle cela “backlog”.

L’effet de bord de ce backlog “complet et détaillé” est le délai que cela nécessaire pour en arriver là.

Une phase d’analyse ?

Scrum a poussé le concept d’itération zéro, pour amorcer un projet. Mais pour débuter avec un backlog complet et détaillé, cela ne suffit pas. Aussi voit-on le product owner ou l’équipe PO commencer un travail qui n’est pas seulement exploratoire mais un travail de fond en avance de phase afin que l’équipe de développement puisse débuter son oeuvre avec une matière première solide.

C’est la négation même de l’approche agile dont le fondement est le cycle court et le feedback. C’est en fait la réincarnation de la phase d’analyse !

L’autre conséquence de cette phase d’analyse, outre le délai, est la création d’un stock. J’en ai parlé plus haut et j’ai l’air d’insister, mais en terme “lean”, le stock est assimilé à du gâchis: c’est du travail dont on ne sait s’il va être utilisé et demande une charge d’entretien : relecture, réévaluation régulerière, etc…

Old files

Ma liberté de penser !

Vous finissez un sprint et allez commencer le suivant. Il est temps de choisir les prochains items de backlog à développer.

Qu’est-ce qui importe vraiment ?

Sont-ce les prochains items de backlog selon la priorité qui leur a été attribuée ? Pas vraiment, ou du moins pas comme ça.

Ce qui importe vraiment c’est ce que nous avons appris à la lumière du sprint écoulé : approfondir des fonctionnalités sur lesquelles nous avons travaillé, se diriger vers une direction complètement différente et parfois oui, prendre des items du backlog tel que nous l’avions dressé.

Mais par rapport à ce focus sur le feedback et l’apprentissage le backlog agit régulièrement comme un frein ou plutôt comme un gros élastic que nous aurions dans le dos, qui nous ramène inoxorablement vers la voie que nous avions tracé au départ.

Qu’est-ce qui empêche d’utiliser le backlog pour prendre en compte l’apprentissage et le feedback ? Absolument rien. En fait, il est fait pour ça. Comment l’utilisons-nous dans les faits ? Je vous laisse le soin d’y répondre.

Dans un projet agile, ce qui s’interpose entre vous et le feedback est un problème. Ne laissez pas le backlog devenir un problème, ne le laissez pas entraver votre liberté de penser. Un backlog n’est pas un cahier des charges.

A quoi ça sert vraiment ?

J’ai l’air de dire jusqu’à présent que le backlog est l’oeuvre du malin. Donc est-ce utile ? Voilà un point sur lequel nous allons pouvoir répondre aisément.

S’assurer que l’on fait les choses les plus importantes

Imaginez que vous avez un backlog de 50 items alors que vous n’allez pouvoir en traiter que 3 dans la prochaine itération. A quoi servent donc les 47 autres ? Eh bien essentiellement à s’assurer que l’un des 3 items importants ne se trouve pas parmi ces 47 autres !

Donner de la perspective

Certes, quand on fait un projet hautement innovant, voir de la R&D, construire un backlog a peu ou pas de sens. On est d’ailleurs là en dehors de la zone de Scrum. Mais lorsque cela est possible, en fait assez souvent, avoir du contexte donc une idée de ce qui est considéré comme le périmètre du projet à un instant donné, aide à la réflexion et est plus stimulant pour l’équipe.

Quelle(s) alternative(s) ?

Elles sont essentiellement déterminées (ou limitées) par notre créativité. J’en propose 3. Et je vais tricher un peu.

Arrêtez ça

Ce n’est pas une alternative mais un conseil : ne faites pas le backlog “complet et détaillé”. C’est mal. Arrêtez de faire ça, simplement.

Pas de backlog

Si on n’a plus de backlog, on ne fit plus du Scrum, n’est-ce pas ? Mais certains projets à forte composante exploratoire ne se prêtent pas à cela. Nous sommes alors dans le cas où la backlog va générer plus d’entrave que d’aide. Il est peut-être temps de sortir de Scrum. D’autres approches agiles s’accomodent de l’absence de backlog :

  • Extreme Programming parle juste de User Stories (on s’occupera de leur cas dans un épisode futur) à traiter et ne fige même pas celles-ci pour l’itération en cours. Toutefois XP n’est pas hostile à la présence d’un stock de stories.
  • Kanban n’a pas de backlog, mais des files d’attente. Et celles-ci ont des capacité déterminées et limitées. On a bien du stock dans une certaine mesure, mais celui-ci est limité et contrôlé.
  • Lean Startup ne parle ni de backlog ni de stock de features. En fait, cette approche s’oppose intrinsèquement à ces notions car le focus est ici uniquement sur l’apprentissage scientifique qui est fondamentalement antagoniste avec la présence d’un “stock d’hypothèses”.

Le backlog à géométrie variable

C’est mon préféré. C’est aussi un compromis entre les avantages (donner de la perspective, identifier les fonctionnalités candidates) et les inconvénients (créer du stock, générer de la charge et du délais). Fort heureusement, c’est aussi ce qui est préconisé par de nombreux auteurs, dont Claude Aubry (3).

Dans cette approche on limite le découpage fin des stories et leur détail qu’aux fonctionnalités classées les plus prioritaires. Je ne vais pas entrer dans le détail ici, ce n’est pas le but de ce post. Vous en trouverez la description ailleurs.

Alors le backlog, c’est mal ?

J’utilise des backlogs et j’aime bien ça. Je serais donc bien en peine de dire que c’est mal.

Mais ce n’est pas non plus de la magie. Le backlog est un outil. Mais aussi bénéfique soit-il un outil porte en lui-même les germes de ses propres travers. Je me limiterais à deux conclusions:

  • Ne dénaturez pas le backlog et la façon dont il doit être utilisé.
  • Soyez conscients des inconvénients. Ils joueront contre vous si vous les ignorez.

Références

(1) Agile Software Development with Scrum, Ken Schwaber & Mike Beedle, Prentice Hall 2002 ; p. 33

(2) The Mythical Man-Month anniversary eat, Frederik Brooks, Addison Wesley 1995

(3) Scrum Le guide pratique de la méthode agile la plus populaire 2nd édition ; Claude Aubry ; Dunod 2011 ; p. 67

Note de lecture : Effective Java, second edition, par Joshua Bloch

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Il fait honneur à la lignée « effective »

Le titre du livre ne laisse guère planer le mystère : il se veut le pendant Java du désormais célèbre « Effective C++ » de Scott Meyers. Eh bien, on peut l’avouer, le contrat est plutôt bien rempli. Il expose 57 items au long de 232 pages découpés en 10 chapitres. La présence d’un tel ouvrage afin de stigmatiser les bons usages du langage était sans nul doute nécessaire, car si Java  (au contraire du C++) passe pour un langage facile, il n’en est de ce fait que plus aisé (et d’ailleurs plus fréquent) de mal l’utiliser !

Le style du texte est sensiblement différent de celui de Scott Meyers. D’abord on n’y retrouve pas la pointe d’humour qui fait le charme de l’ouvrage C++. Il focalise également un peu moins sur le code de bas niveau, même si nombre d’items sont spécifiquement dédiés à ces aspects. Enfin, l’auteur qui fut « chief architecte » d’une bonne partie des librairies Java oriente souvent son propos par rapport à une vision développement de librairies, alors que c’est un biais somme toute marginal, par rapport au développement d’applications !

Malgré ces petits reproches, il ne fait nul doute que ce livre est un incontournable de toute bibliothèque Java un tant soit peu sérieuse, ne serait-ce que pour utiliser correctement les redéfinitions des méthodes dérivées de la classe Object, comprendre convenablement les « nested classes », certains principes de bases inhérents aux exceptions ou à la sérialisation. Le chapitre consacré aux threads est évidemment plus ardu et également moins pointu que le livre de Doug Lea consacré à ce sujet (et qui fait toujours référence).

Parmi les choses que j’apprécie particulièrement dans le texte : le style très clair, même narratif dirais-je car l’auteur nous guide réellement dans l’explication de l’item tel un conteur. Des fragments de code illustrent le texte et sont particulièrement bien pesés : avec assez de contexte pour donner du sens mais assez concis pour ne pas noyer le lecteur ni être ennuyeux. Globalement j’aime le style très « punchy » avec lequel l’auteur aborde chaque problématique pour nous faire tomber des nues sur tel ou tel comportement du langage, qu’il soit justifié ou non.

Cette seconde édition compte 300 pages pour 68 items. Vous aurez vite fait le calcul sur la taille moyenne de chaque item en nombre de pages ! De toute façon, c’est une lecture à laquelle on prend plaisir tout en apprenant.

Le texte fait de nombreuses références au manuel de référence du langage qui est un complément indispensable à ce livre.

effective-java-2edt

Référence complète : Effective Java, second edition – Joshua Bloch – Addison Wesley / Java Series 2001 – ISBN : 0-201-31005-8

Effective Java(tm) Programming Language Guide


http://www.goodreads.com/book/add_to_books_widget_frame/0201310058?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Pattern Language of Program Design, James Coplien & Douglas Schmidt edt

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Pour les “accros” des patterns, exclusivement.

Le mouvement des “Design Patterns” a donné naissance aux conférences PLOP d’abord (aux Etats-Unis, à l’université d’Urbana Champain, Illinois), puis EuroPLOP (Kloster Irsee, Allemagne). Ce volume regroupe une sélection des papiers soumis par les participants à la première conférence PLOP. C’était alors le début de cette conférence, en conséquence la sélection n’est pas sévère, les patterns soumis peu ou pas “compétitifs”, souvent très généraux, plus centrés sur les concepts (ce que l’on qualifie parfois d’approche Alexandrienne) que sur le design. Enfin, une place importante est prise par les patterns “organisationnels”.

Sans rentrer dans les détails, voici une idée générale de la structure de cette compilation :

La première partie « frameworks et composants » regroupe des patterns et patterns languages de niveau très conceptuels pour architecturer des applications.

La seconde partie « systems and distributed processing » regroupe des patterns à caractères architecturaux. C’est l’une des plus intéressante du livre.

Dans la troisième partie « business objects » on retrouvera des patterns et pattern language liés à des domaines métier.

La quatrième partie « process and organization » regroupe exclusivement des patterns languages. C’est celle qui m’a le moins accroché.

La cinquième partie « design patterns and catalogs » est dédiée aux papiers ayant trait à l’étude des patterns : catégorisation, mise en évidence, documentation. C’est intéressant dans le principe, mais hélas ennuyeux dans les faits.

La sixième partie « architecture and communication » promettait d’être intéressante, mais le traitement des patterns qui y figurent est trop littéraire à mon goût pour présenter un réel intérêt. Le « POSA book » adressera cela beaucoup mieux !

La septième partie « object usage and style » ne donne pas tellement lieu à commentaire, si ce n’est que les patterns qui y figurent ne resteront pas dans les annales.

La dernière partie « events and events handlers » a je pense été créée car plusieurs patterns apparaissaient dans cette catégorie.

Certains patterns se détachent du lot, par exemple :

  • Half-object + protocol de Gerard Meszaros
  • Master-Slave pattern de Frank Buschmann
  • Reactor de Doug Schmidt
  • Le CHECKS pattern language de Ward Cunningham qui est l’un des rares pattern language de cette édition à mériter le détour.
  • Dans les patterns organisationnels, une petite curiosité : le « Lifecycle and Refactoring Patterns that Support » qui est en fait une prémice du futur « Refactoring » paru en 1999.

Certes la substance utile est plus importante que celle que j’ai cité. Mais beaucoup des patterns et surtout des patterns languages sont plus des essais à l’intérêt académique que de la matière exploitable. Pour qui veut se plonger dans l’étude des Patterns, ce volume a un intérêt ne serait-ce qu’historique. C’est mon cas. Mais pour beaucoup, ce volume sera à la fois trop aride et pas assez pourvu de matière exploitable en regard de ses 550 pages.

En vérifiant sur Amazon, j’ai la surprise de constater que ce livre est toujours disponible 17 après sa parution ! Je ne le recommande toutefois qu’exclusivement aux aficionados des patterns ! 

PLOPD

Référence complète : Pattern Language of Program Design – James Coplien & Douglas Schmidt edt – Addison Wesley / Software Patterns series 1995 – ISBN: 0-201-60734-4

Pattern Languages of Program Design


http://www.goodreads.com/book/add_to_books_widget_frame/0201607344?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : C++ Coding Standards, par Herb Sutter & Andrei Alexandrescu

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; N’écrivez plus vos règles de développement sur vos projets C++ !

Quand j’ai besoin de mettre en place des règles de développement en C++, j’ai l’habitude de ressortir mon mètre linéaire d’ouvrages sur le C++, ainsi que mon édition quasi complète de C++ report, et de m’efforcer de dégager nombre de règles impératives, expliquées et détaillées, en fournissant nombre de références bibliographiques. Travail harassant (bien que passionnant), si il en est ! Bien sûr, avec les ans, j’ai amélioré la chose, et je ne repars plus de zéro, mais …. Mais voilà, CE livre est arrivé et a fort heureusement rendu mes efforts obsolètes !

Le livre de Sutter et Alexandrescu couvre plutôt efficacement les grandes lignes des choses à ne pas faire (mais en excluant les choses vraiment trop basiques). 101 règles, c’est plutôt solide, mais on pourrait aussi trouver cela insuffisant. Je pense, moi, que c’est un bon compromis. Si certains aspects doivent être mieux couverts dans votre projet, ou si le niveau de l’équipe nécessite des règles plus basiques pour blinder le développement, ajoutez-les à ce matériel de référence ! Agissez de même pour illustrer les points de l’ouvrage avec des exemples issus de votre domaine de travail. Mais le gros de la matière est là et bien là.

Pour rapport aux ouvrages de Meyers ou de Sutter, celui-ci se positionne différemment : au lieu de développer les items de façon pédagogique, on se contente de développer chaque item sur 1 ou 2 pages (parfois 3), avec des explications claires, mais sans le développement en profondeur de Sutter, ni l’approche pédagogique de Meyers. L’efficacité est privilégiée, et c’est très bien adapté à la finalité de ce livre (manuel devrai-je dire).

Les règles sont rangés sous plusieurs volets qui forment autant de chapitres :

  • D’abord des règles organisationnelles : gestion de version, niveau de warnings, etc… Les bases pourrait-on dire.
  • Des règles de conception, qui ne sont pas spécifiques au C++. Elles recoupent ce que l’on pourra trouver dans le « Designing Object-Oriented C++ Applications » de Robert Martin.
  • Le style de codage : usage des constantes, déclarations des variables, etc..
  • L’usage de fonctions et d’opérateurs.
  • Les règles d’usage et d’implémentation de l’héritage. Cela paraît curieux mais il y a effectivement beaucoup de subtilités possibles en C++.
  • Constructeurs, destructeurs et opérateurs de copie.
  • Utilisation des namespaces.
  • Utilisation des templates.
  • Gestion des exceptions.
  • L’utilisation de la STL couvre deux chapitres, pour les conteneurs d’abord puis pour les algorithmes.
  • Utilisation des opérateurs de cast modernes.

Si vous avez de la bouteille en C++, vous n’apprendrez rien. En fait, le but n’est pas d’enseigner des choses, mais de poser un socle solide de règles pour construire des développements en C++. Je recommande chaudement, bien entendu.

c++-coding-standard

Référence complète : C++ Coding Standards: 101 rules, guidelines, and best practices – Herb Sutter & Andrei Alexandrescu – Addison Wesley / C++ in depth series 2004 – ISBN: 0-321-11358-6

C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

http://www.goodreads.com/book/add_to_books_widget_frame/0321113586?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on