Note de lecture : Beyond Requirements, par Kent J. McDonald

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Spécifier, avec un vrai mindset agile

De prime abord, le titre fait penser au mariage du veau et du cochon. Mais très vite, on comprends qu’il n’en est rien, bien au contraire. Car ce volume va au-delà de la compilation de pratiques d’analyse agile, nous allons voir cela.

L’ouvrage est de taille moyenne avec ses 230 pages structurées en 3 parties pour un total de 15 chapitres. La première partie « Ideas » est forte de 75 pages sur 6 chapitres. Ici, on parle surtout de culture agile, certes centrée sur l’analyse mais sans entrer en profondeur dans les pratiques. Dans le premier chapitre « guiding principles », Kent McDonald nous distille ce qu’il a condensé en 7 principes directeurs sur lesquels s’appuient ses manières de raisonner et de prendre des décisions. Par la manière dont ces principes sont pensés et exposés, nous voyons rapidement que l’auteur est un agiliste de très haut niveau. Peut-être est-ce la 15ème fois que l’on vous assène des principes fondateurs ? Ne manquez pas ceux-cis. Au second chapitre, on entre plus spécifiquement dans le domaine de l’analyse. Et ce sont les concepts structurant de l’analyse agile qui sont développés ici. La référence au BABOK (Business Analysis Body of Knowledge) est certes austère, mais les 6 concepts évoqués ici serviront de cadre au reste de l’ouvrage. Il aborde aussi 2 piliers importants de l’approche produit moderne : outcome versus output et la dualité discovery / delivery.

Signe de l’influence de l’approche produit dans son cadre de spécification agile, l’auteur rend hommage au Lean Startup au chapitre 3. L’auteur ne se contente pas de paraphraser Eric Ries : il projette les concepts de l’approche au monde de l’entreprise. Un bel exercice. La prise de décision, sujet du chapitre 4 semble être un des thèmes favoris de l’auteur. Au menu de celui-ci, nous avons tout d’abord les mécanismes de la prise de décision elle-même, bien décomposés. Kent McDonald semble apprécier Chris Matts, c’est sans doute pourquoi nous avons un coup de projecteur sur les « real options ». C’est un bon teaser à « Commitment » ! Enfin, c’est un plaisir pour moi de voir que les biais cognitifs qui entachent si grandement les processus de décision ne sont pas oubliés.

Continuer à lire « Note de lecture : Beyond Requirements, par Kent J. McDonald » →

Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Des conseils simples, avisés et … pragmatiques, pour bien commencer avec les tests unitaires.

Dans la veine des « starter kits » écrits par les « pragmatic programmers », voici un opuscule consacré aux tests unitaires en général et à JUnit en particulier. L’objectif est très clair : mettre le pied à l’étrier de manière pragmatique, sans s’encombrer de beaucoup de théorie. De fait le livre est court, avec 125 pages (hors annexes), mais quand même découpé en 9 chapitres, chacun étant donc court.
Le premier chapitre est une prose introductive au « pourquoi » des tests. Il s’étend largement sur les contre-arguments à leur écriture, et permet de balayer les objections les plus courantes. Toujours une bonne chose de faite. Au second chapitre, nous pratiquons l’équivalent du très classique « hello world ». C’est minimal et le chapitre est très court. Ce n’est pas le cas du chapitre 3 qui nous accoutume aux autres éléments utilisés classiquement lors de l’écriture de tests unitaires : setup, tear down, test suite et assertions en tout genre. Nous sommes armés pour écrire des tests plutôt standard mais qui répondent aux besoins courants.

A partir du chapitre 4, il est davantage question d’écrire de bons tests et une bonne couverture de test. Les auteurs proposent l’acronyme Right-BICEP. Tout d’abord il s’agit de définir ce qu’est un résultat juste, puis d’appliquer les règles du BICEP (que je ne vais pas développer ici). Toutefois le « B » pour boundary va être l’objet plus spécifiquement du chapitre 5 où il va être développé selon un autre acronyme, le CORRECT. Les conditions aux limites sont souvent source d’erreur, les auteurs font un bon travail à bien cerner l’ennemi. Le chapitre 6 est consacré aux Mock objects. Ce chapitre est juste une introduction au sujet, utilisant EasyMock, mais elle est consistante. Elle marque aussi la temporalité du livre, car l’exemple choisi est le mock d’une servlet !

Le chapitre 7 va aborder les propriétés d’un bon test et c’est l’occasion d’un nouvel acronyme : A-TRIP. Car si un test doit être Automatique, il doit aussi complet (Thorough) en testant ce qui peut casser, Répétable en remettant le système en conditions initiales en fin d’exécution, Indépendant en ne supposant pas de séquence d’exécution et enfin Professionnel ! Cette dernière propriété est énoncée de manière bien curieuse. Les auteurs veulent simplement dire que le code du test doit respecter les mêmes qualités de conception et d’implémentation que le code de production. Il n’y a guère de code au chapitre 8. Celui-ci est consacré à l’organisation du code de test et au cycle de développement. Rien que de très classique ici, puisque l’on organise le code façon Maven et que l’on préconise le test en continu sans toutefois aborder le TDD. Le livre se referme sur un chapitre 9 consacré à la conception, plus précisément aux implications du test unitaire sur la conception, ce que les auteurs appellent le « test-driven design ».

Continuer à lire « Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas » →

Note de lecture : The Incremental Commitment Spiral Model, par Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner

Le par addinquydans Notes de lectureLaisser un commentaire

Note 3 : Se retrouver à lire un livre que l’on n’a pas envie de lire…

Et ainsi donc, le développement itératif et incrémental est désormais acquis au développement agile ! Tout le développement itératif et incrémental ? Non ! Un village résiste encore et toujours : il s’appelle « spirale de Boehm ». Cet ouvrage est peut-être son chant du cygne, l’avenir nous le dira.

L’ouvrage que nous allons explorer nous présente l’ultime version du modèle en spirale. Il compte environ 250 pages découpés en 16 chapitres, eux-mêmes structurées en 4 parties. Si ces caractéristiques laissent présager une lecture pas trop longue et bien rythmée, c’est sans compter sur l’austérité de la prose ! Il est temps de s’y attaquer. L’introduction permet aux auteurs de positionner le « incremental commitment spiral model » que nous nommerons maintenant ICSM sur le même créneau des méthodes adaptatives que les approches agiles qui sont d’ailleurs citées. Elle ne cherche pas à s’y opposer, mais à se positionner différemment en s’appuyant sur 4 principes sur lesquels nous reviendront. Le but est de se tailler une place dans les environnements plus classiques et « legacy » qui sont quand même prêts à accueillir un cycle itératif. En prime, ce chapitre 0 nous propose une belle vue actualisée du cycle en spirale : l’ouvrage aura ainsi au moins une valeur archéologique !

La première partie compte 4 chapitres sur 80 pages. Ils vont détailler les 4 principes de l’ICSM que nous avons mentionné. Le premier chapitre aborde la question de la valeur pour les parties prenantes. Il s’appuie sur les leçons tirées de 2 histoires, notamment de la conception d’un équipement hospitalier. Ce principe est adossé au « success critical stakeholder » ou SCS. Ce principe est un mélange de modernité (la mesure du succès est le succès du SCS) et de choses plus anciennes avec une approche en phases qui rappelle étrangement Unified Process ! On n’échappe d’ailleurs pas à une matrice critères de succès / parties prenantes ! Au second chapitre, on aborde la notion d’engagement incrémental : c’est le cône d’incertitude qui est mis à l’honneur ici. Cette fois encore le propos est illustré de deux histoires, un succès et un échec, le succès étant le projet TRW débuté en 1978 qui fut à l’origine du cycle en spirale ! Le chapitre fait apparaitre l’approche comme très technocratique et la prose est plutôt lourde. Le volet intéressant de ce chapitre est la comparaison de modèles incrémentaux allant du « prespecified » au « evolutionary concurrent ».

Le 3ème principe que nous découvrons au chapitre 3 est le « concurrent multidiscipline engineering ». Nous avons aussi droit à deux histoires, celle illustrant le succès étant le développement d’un drone. Le propos est alambiqué et assez lourd. Il s’éclaire vers la fin du chapitre quand l’auteur nous déclare que l’utilisateur peut rarement spécifier clairement ce qu’il veut au début du projet et qu’il nous faut donc mener de front l’affinage des besoins, la conception et le développement. Il s’agit bien du fonctionnement multidisciplinaire que nous connaissons en agile. Il est simplement exprimé de manière obscure ici. Le dernier principe est celui des décisions basées sur les risques, le sujet du chapitre 4. Le propos se concentre sur la valeur apportée par les études de faisabilité. L’auteur met aussi en perspective l’approche de Walker Royce intégrée à Unified Process comme étant un progrès par rapport au cycle en spiral initial ! Globalement la coloration « pré-agile » y est assez évidente.

Continuer à lire « Note de lecture : The Incremental Commitment Spiral Model, par Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner » →

Note de lecture : Application Security Program Handbook, par Derek Fisher

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pour nous guider dans la mise en place de la cybersécurité.

Il faut commencer par ouvrir ce livre pour en comprendre le titre. Il s’agit bien de sécuriser les applications, mais plutôt sous l’angle de la gouvernance et de la mise en place de cette sécurisation. Dit ainsi, cela n’a rien d’attrayant et le texte aurait pu être terriblement rébarbatif. Il n’en est rien, et nous allons voir pourquoi.

L’ouvrage est parfaitement rythmé : il compte 260 structuré en 3 parties, chacune d’entre elle comptant 3 chapitres. La première partie sert à camper le décor, elle sert à nous permettre d’appréhender ce qu’est la sécurisation d’une application. Le chapitre 1 réponds au « pourquoi » de la sécurisation, mais en réalité va bien plus loin. Tout d’abord en introduisant le fameux « security program » qui est la raison d’être du livre, mais surtout en introduisant le securisation pipeline qui est l’apport majeur du texte et défend une approche « shift left » qui parlera bien aux agilistes.

Le second chapitre « understanding the problem” adresse deux sujets majeurs, le premier sera mon préféré, j’ai parlé de la triade CIA : confidentialité, intégrité, disponibilité (availability). L’auteur rentre en profondeur sur chacun de ces thèmes, détaillant la manière de les adresser. Un excellent boulot. Le second thème traite des risques : si j’ai aimé la classification et la présentation des types d’attaquants, la gestion des risques elle-même, s’appuyant sur le NIST, est plus austère. Le dernier chapitre de cette première partie est consacré aux composants de la sécurisation des applications. Tout d’abord on y trouve une excellente introduction à la modélisation des menaces, puis un panorama des outils d’analyse et enfin une évocation des différents types de test. Bref, ce chapitre est une petite mine d’or !

Continuer à lire « Note de lecture : Application Security Program Handbook, par Derek Fisher » →

Note de lecture : Effective Software Testing, par Mauricio Aniche

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Une stratégie de tests gravitant hélas uniquement autour des tests unitaires, mais faisant un excellent travail pour en systématiser l’approche.

En matière d’ingénierie logicielle moderne, la littérature sur les tests tend à se concentrer sur les tests unitaires et les tests d’acceptation. Les ouvrages qui englobent les pratiques de manières plus larges ciblent surtout l’aspect méthodologique. C’est donc avec intérêt que j’aborde ce texte qui se focalisent sur les différents types de tests que l’on peut mettre en œuvre au niveau des équipes de réalisation. Et nous allons le voir, cela ne se limite pas aux deux types de tests que nous venons d’évoquer.

Avec 274 pages hors annexes, cela reste un ouvrage de taille raisonnable. Il est structuré en 10 chapitres. Le premier chapitre annonce la couleur : les développeurs qui testent versus ceux qui ne testent pas. L’idée est ici d’avoir un tour d’horizon des types de tests qui vont être abordés et de l’aspect méthode et automatisation qui, même si on ne parle pas d’agilité, restent dans la même idée. Mon désaccord principal, sur ce chapitre et sur le livre, est d’utiliser la pyramide de tests comme boussole, une idée absolument dysfonctionnelle. Bien sûr, l’auteur met l’accent sur les petits tests qui s’exécutent rapidement (donc les tests unitaires), je ne saurais lui reprocher. Mais les autres tests sont pour lui : les tests d’intégration (quels tests d’intégration ?), les tests système et les tests manuels et c’est tout ! Pas de tests fonctionnels ou au moins de tests d’acceptation. C’est une vue erronée du paysage des tests, mais cela ne veut pas dire que l’ouvrage n’a pas d’intérêt.

En fait le chapitre 2 aborde le « specification-based testing ». Mais pas au sens des tests d’acceptation. Il s’agit ici de mettre en place des tests unitaires pour tester les règles de gestion à bas niveau. L’auteur y propose une démarche très systématique en 7 étapes allant des premiers tests passants aux tests aux limites puis « créatifs » sans oublier l’automatisation ! C’est de fait une approche très disciplinée des tests unitaires, peut-être trop, mais cela reste une très bonne source d’inspiration. Le texte ne s’arrête pas là puisqu’il aborde le traitement des bugs. Le propos est largement adossé à de très nombreux exemples en Java. Mais à mon avis l’illustration a travers de règles de validation sur une chaine de caractère n’est pas assez significatif d’un véritable projet.

Continuer à lire « Note de lecture : Effective Software Testing, par Mauricio Aniche » →

Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pour s’initier sérieusement au continuous delivery

Cette série « grokking », c’est un peu le « pour les nuls » de Manning. Et tout comme cette série, ce n’est pas nul du tout. L’ouvrage rentre en profondeur dans le sujet, avec simplicité et pragmatisme, mais certainement pas avec simplisme. Comme nous le verrons, il s’avère même étonnant, en plus d’être abondamment illustré. Cela nous explique les 360 pages de cet ouvrage (hors annexes). Aussi, si la lecture est aisée, elle demande quand même un certain temps !

Le livre, justement, parlons-en. Il est structuré en 4 parties pour un total de 13 chapitres. La première d’entre-elles est une introduction sur 2 chapitres et un peu plus de 30 pages. Comme on peut s’y attendre, le premier chapitre est purement introductif, définissant le concept et ses concepts adjacents et lui donnant une perspective historique. C’est en fait une bonne idée, tellement il peut y avoir de subtilité entre les concepts et le texte ne fait pas l’impasse dessus. Il est précis et concret. C’est un bon chapitre. Le second chapitre s’inscrit en parfaite continuité pour décrire un pipeline de base en s’appuyant sur un cas d’étude, en l’occurrence des photos de chat. L’auteur nous prends par la main pour construire progressivement ce qui est un pipeline CI, finalement loin d’être basique. Tout ce fait progressivement en expliquant les concepts tels que guichet et transformation, progressivement. Seules les notifications par Webhook sont un peu spécifiques dans le paysage.

La partie 2 couvre les mises en œuvre nécessaires pour conserver un logiciel dans un état délivrable tout le temps. Elle pèse 5 chapitres sur 140 pages. Le chapitre 3 adresse la gestion de version et la startup de Sacha et Sarah va nous aider à y voir plus clair. Le texte fait le choix d’utiliser Github comme exemple. Il en fallait bien un, et il parait raisonnable. Cela permet de se familiariser avec les concepts de push et pull request. Le texte ne s’arrête pas là, il fait la transition avec le pipeline, et pourquoi pas dans le cloud ? Il adresse aussi la gestion de configuration en gestion de version en imaginant la connexion à une base de données également dans le cloud. Les auteurs vont plus loin que la gestion de version sensu-stricto. C’est un choix de l’auteure que nous retrouverons régulièrement.

Continuer à lire « Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci » →

Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pour capturer et écrire plus efficacement des exigences.

Le moins que l’on puisse dire est que ce livre ne date pas d’hier ! Il attire toutefois l’attention par au moins deux aspects : le premier est la cosignature de Gerald Weinberg. Le second se situe dans le titre car il y est question non pas de gérer, de collecter ou de capturer des exigences, mais de les explorer. C’est sans doute pour cela qu’il va être moins questions de processus que de pratiques centrées sur l’humain et l’aspect psychologique de cette exploration. Par certains côtés, on y côtoie l’agilité avant l’heure !

L’ouvrage en lui-même n’est pas anodin : il totalise près de 300 pages structurés en 25 chapitres, eux-mêmes regroupés en 5 parties. Toutefois l’ensemble se lit bien. La première partie compte un peu moins de 50 pages pour 4 chapitres et son thème attire tout de suite l’attention, car il y est question de négocier une compréhension commune ! Le premier chapitre prend le contrepied des méthodologies, mais en fait c’est des notations qu’il s’agit. Et les auteurs, à l’aide d’exemples très simples mettent en évidence à la fois la difficulté sous-estimée de compréhension des notations et introduisent la notion d’ambiguïté des exigences, qui sera particulièrement le sujet du second chapitre. Ce second chapitre est plutôt court et va se limiter à définir cette notion d’ambiguïté dans le domaine du recueil des besoins, et ses conséquences. Mais ce thème reviendra au long de l’ouvrage.

D’ambiguïtés, il est toujours question au chapitre 3, qui va adresser les sources d’ambiguïté : observation, interprétations dans lesquelles le facteur humain vient s’insérer. Les recherches de Daniel Kahneman n’étaient pas encore popularisées mais elles auraient pu être citées ici. Les auteurs mettent néanmoins en relief ces biais au travers d’exercices pratiqués en séminaire. Pour refermer cette première partie, les auteurs s’attaquent à la pratique des questions directes au travers d’arbres de décision. Sans citer les biais cognitifs, ils mettent en question le postulat sous-jacent : la nécessité de s’adresser à des « êtres humains parfaits ». S’ils ne sont pas opposés à leur emploi, le verdict est que cette pratique ne suffit pas.

Continuer à lire « Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg » →

Note de lecture : Making Sense of Cybersecurity, par Thomas Kranz

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; La cybersécurité pour les nuls, mais sans être nulle. Une lecture riche et passionnante à lire.

La cybersécurité, ce n’est pas nécessairement très facile de comprendre ce que c’est. Même une fois cette étape passée, il s’agit d’appréhender ce que cela recouvre et comment cela se décline en termes de mise en œuvre. Le présent ouvrage a pour objectif de s’attaquer à cette tâche pour le moins ardue, et à ma grande surprise il le fait bien, avec un propos accessible sans être débilitant et même avec une pointe d’humour. Bien sûr, comme le texte est émaillé d’anecdotes issues de l’expérience de l’auteur tout cela devient bien plus vivant.

Le livre lui-même est de taille moyenne, avec ses 256 pages. Il est structuré en 12 chapitres, dont 2 d’introduction suivi de 2 parties. Le premier chapitre « cybersécurity and hackers » commence en douceur pour nous faire prendre conscience des enjeux de la cybersécurité. En commençant par l’histoire du château de Warwick, il nous entraine vers les défis de la défense du système d’information. Le style de l’auteur coule tout seul et préfigure le reste de l’ouvrage. Le second chapitre nous assène dans le titre que la cybersécurité est le problème de tout le monde. L’auteur nous y présente son mantra qu’il répètera au fil des chapitres : la mise en œuvre des mesures doit être adaptée, proportionnelle à la menace et soutenable dans le temps. Elle se met en œuvre au travers de 3 questions simples : Quels assets possédez-vous ? Qui peut vouloir vous attaquer ? Quelles défenses mettez-vous en œuvre ? Au travers de ce discours épuré, l’auteur nous montre une autre de ces qualités, celle de présenter un discours clair, simple et pertinent.

La première partie, même si elle n’a pas de titre, est consacrée aux attaques. Elle comporte 5 chapitres sur 125 pages. Elle s’ouvra sur un chapitre 3 sobrement intitulé « comprendre les hackers ». L’auteur a choisi la classification white hat, grey hat et black hat. Son but est de nous faire comprendre l’état d’esprit des hackers. Il le fait en nous dressant de courtes biographies et quelques exemples. Avec la concision qui le caractérise, il résume la démarche du hacker : comment est-ce que cela fonctionne ? Comment je peux le casser ? Qu’est-ce que je peux lui faire faire d’autre ? Qu’est-ce que cela signifie comme possibilités pour moi ? Le chapitre 4 est consacré aux attaques externes. Il s’ouvre sur la boucle OODA (observe, orient, decide, act) et sa déclinaison en 4 questions que nous avons vu précédemment. Mais tout cela va mieux en le faisant. Ainsi l’auteur décline la manière d’opérer d’abord sur une infrastructure domestique, puis sur une architecture d’entreprise. Le chapitre ne serait pas complet sans un panorama des différentes attaques, que ce soient des classiques de l’OWASP, du mobile, du Wifi, etc. A chaque fois cela est expliqué avec clarté et une dose de légèreté qui nous ferait presque oublier que nous apprenons des choses au fil des pages.

Continuer à lire « Note de lecture : Making Sense of Cybersecurity, par Thomas Kranz » →

Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Malheureusement bien pauvre sur la substance même de cette collaboration !

J’ai été attiré par ce titre, aussi bien par le thème aussi original qu’important dans les pratiques d’identification du besoin, que par des recommandations tierces. La littérature adressant la manière de collecter, structurer et formaliser les exigences est très importante. Nombre de ces ouvrages sont d’ailleurs excellents ! Mais les textes traitant des interactions entre personnes pour les faire émerger est beaucoup plus réduite. Le présent ouvrage est peut-être le seul entièrement dédié à ce sujet ! Le texte n’est pas récent, il date du début des années 2000 alors que l’agilité en était à ses débuts. Aussi n’y trouverons-nous aucune référence à ce mouvement, même si de nombreuses idées sont convergentes.

Le livre lui-même comprends près de 280 pages. Il est structuré en 3 parties pour un total de 12 chapitres. La première partie nous promet un tour d’horizon des ateliers de définition des exigences, sur 3 chapitres pour environ 65 pages. Elle s’ouvre sur un très classique « getting started », en guise de premier chapitre. Il a pour but de cadrer la suite du sujet, tout d’abord en définissant les différents types et niveaux d’exigences. Ensuite en clarifiant la notion d’ateliers, ceux abordés ici s’inspirent du Join Application Design (JAD) qui nous conduisent à considérer différents types d’ateliers en fonction de leurs finalités. Le chapitre fait bien le travail, on y voit bien plus clair en l’ayant terminé.

Au chapitre 2, nous allons rentrer plus en profondeur sur ce que nous cherchons obtenir des ateliers, donc les artéfacts. Pour ceux qui ne sont pas familiers de la littérature sur la gestion des exigences, ce sera sans doute une découverte de voir le nombre et la variété de ces artéfacts. Bien que l’on ne rentre pas encore dans le cœur du sujet, le propos est intéressant et bien construit. Cette première partie se clôt sur l’aspect préparatoire des ateliers : l’espace, les invitations, l’état d’esprit avec lequel il faut venir. C’est un peu verbeux et enfonce parfois les portes, mais cela reste bien fait.

Continuer à lire « Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener » →

Note de lecture : Pragmatic Version Control, using Git, par Travis Swicegood

Le par addinquydans Notes de lectureLaisser un commentaire

Note 4 ; Informatif, mais pas passionnant.

Git, depuis son apparition est rapidement devenu le standard de fait de la gestion de version. Après avoir commis la gestion de version pragmatique avec CVS puis Subversion au début des années 2000, il devenait évident de proposer l’ouvrage équivalent pour Git. Équivalent il l’est car, comme nous allons le voir, il s’agit essentiellement d’une transposition du même texte au monde Git.

Le livre est plutôt court, avec 150 pages, mais découpé en petits chapitres, puisqu’il en compte 11, regroupés en 3 parties. La première partie est consacrée à l’installation et à la mise en œuvre initiale de Git. Le premier chapitre, c’est le tour du propriétaire. On y retrouve les concepts de base de la gestion de version, correctement actualisés par rapport à Git, mais sans exposer ses particularités outre mesure. Un bon chapitre pour les débutants sur la gestion de version, mais qui apporte peu pour les autres. Le second chapitre évoque l’installation et la configuration de base de Git. C’est vraiment du pas à pas pour différents systèmes d’exploitation, pas la peine de s’attarder. Avec le 3ème chapitre qui referme cette première partie, cela devient plus sérieux : il s’agit de créer un projet. En fait, on y fait même plus que cela : on y ajoute des fichiers et opérons quelques commandes de base. Le livre commence vraiment avec ce chapitre.

La seconde partie évoque l’utilisation de Git au quotidien. C’est la partie la plus importante de l’ouvrage, avec 6 chapitres sur 90 pages. Le chapitre 4 ouvre le bal avec les commandes de base, en allant plus loin que ce que nous avons vu au chapitre 3, c’est à dire créer de nouvelles versions, des branches, supprimer et renommer. Bref, tout ce que l’on peut faire individuellement sur un fichier. C’est bien écrit et décomposé : le débutant trouvera son bonheur pour bien débuter. La gestion des branches est un sujet qui arrive très vite, et c’est abordé au chapitre 5. De mon point de vue, sans couvrir toutes les possibilités, on va plus loin que les besoins quotidiens, avec le cherry picking et le renommage de branches. Le « merge manuel » est même abordé ! Étonnement, il n’y a pas trace du rebase !

Continuer à lire « Note de lecture : Pragmatic Version Control, using Git, par Travis Swicegood » →