Last week Pyxis hosted an intensive three days immersion into Greg Young’s Applied DDD course. This course is amazingly packed with tips and tricks on how to come up with an architecture that delivers business value customers have come to expect from their investments in software systems. Powered by Greg’s energetic tone, this course challenged my assumptions of how software should be designed and I would recommend it to anyone interested in architecture innovations surrounding Domain Driven Design. Following is an overview of the topics we’ve tackled during the training.

DDD recap

The first day was spent refreshing some of the fundamental but often misunderstood concepts of Domain Driven Design. We were reminded that Strategic Design is essential while embarking on a Domain Driven Design project as we must make sure that the value we get out from it is well worth the effort. Notions such as Bounded Contexts and Core Domain allow highly knowledgeable teams to focus on value added development work while leaving less crucial aspects of the software to others.

Another topic that stroke a chord with me was Greg’s presentation of Aggregates and the role the play in well crafted software systems. Aggregates exist to provide transaction boundaries around the behaviors of domain objects. Aggregate roots provide the sole entry point to this grouping of domain behaviors and encapsulate validation logic as well as invariant consistency inside the aggregate.

CQRS

We spent the second day learning about Command Query Responsibility Segregation and Event Sourcing. CQRS is different then Command Query Separation (Bertrand Meyer) which advocates that methods that change state should be separated from functions that return value. CQRS takes the same principle and applies it to the whole architecture. In this style of design some objects (write model) represents the commands the domain respond to and other objects (read model) handles the queries and their results. Having separate models for these concerns brings a lot of benefits that I will bring up in later posts.

The write model

It’s common OO knowledge that objects should be designed around behaviors in a domain. Having a dedicated write model consisting of aggregates that define transaction boundaries around the behaviors in the domain focuses work on the most valuable part of the system. This is the place to maximize the return on the work of your most skilled developers aided by domain experts.

The read model

The query side doesn’t have a domain as it’s mostly straightforward boilerplate code. The preferred implementation of a read model is having request DTOs going through a thin query layer that projects directly off of a data source. This is way simpler that using the domain model to do the same. This way pre-fetched paths and optimizing ORMs queries are avoided.

Event Sourcing

Event sourcing can be seen as a way to “standardize” thus reduce the cost of implementing separated read and write models. The basic idea is that all domain can be modeled as receiving commands that and producing associated events. These events can be stored as a log of what happened in the system and also be used to update the read model.

While exposing concurrency issues and ways to handle them Greg showed us a merging algorithm that’s quite simple and clever. Probably, the only piece of code Greg would ever write with a Goto statement as you can see in the picture.

Fine tuning the architecture

The third day was spent analyzing the properties of this architecture and how it could be fine tuned to produce low latency, high availability and high reliability systems. Most notably CQRS architecture can used to get around CAP theorem issues which states that you can’t guarantee all three Consistency, Availability and Partitionability in one system. Look here for another treatment on how to get around CAP.

All these architecture talks made me realize that using DDD and CQRS is a lot of work. And it’s no wonder that they should be applied to core domains. Now most companies I’ve worked with deal with multiple domains such as Sales, Security, Insurance, etc… And it would have been difficult to single out the one that constitutes their core domain. But every company must have a core domain otherwise it would not have a competitive advantage. Turns out a lot of companies derive their competitive advantage from their business process that integrate all of the domains they deal with. This is the place their core domain reside and that’s where Sagas help.

Pyxis source of high quality technical learning

All in all, these three days were packed with useful technical knowledge and eye opening discussions with an expert in his craft. The participants enjoyed the learning experience in Pyxis’ agile environment where they got a close up look at our facilities supporting agile teams. Pyxis is proud to have sponsored this event and is dedicated to bringing high quality technical training to the public.

Other technical trainings :

• Professional Scrum Developer (.NET)
• Agile Modeling
• Domain-Driven Design (DDD)
• Test-Driven Development (TDD)
• Usability Practices
• Executable Specifications with GreenPepper

I had a blast meeting new people and sharing experiences writing software. I especially liked Barry Gervin’s keynote on successful product management and Todd Anglin’s talk on HTML5.

As for me, I did and introductory talk on Scrum and Visual Studio 2010 briefly touching on some of the content of the Professional Scrum Developer course. The training has already started in several countries around the globe: Brazil, Australia and US. I’ll be teaching the Montreal edition that’s coming in June 7th. It’s going to be awesome!

About the Professional Scrum Developer Course

The Scrum Developer course is a unique and intensive five-day experience for software developers. The course guides teams on how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.

Course attendees are prepared to take an assessment at course completion and then become Certified Professional Scrum Developers.

Introduction

In our quest to produce quality software and our relentless use of automated unit tests in our development activities, we’ve come to realize they possess other virtues as well. One of those being they stand as a documentation of the system being developed. I’ve taught this idea in several agile and TDD courses. In this blog I want to give you an example of how that may be. I’m purposely not discussing executable specifications and Behaviour Driven Development as it would make this blog too long. My goal is to show how using some convention and Visual Studio 2010 can go a long way in cranking up your unit tests another notch.

Documentation of API usage

One clever use of unit tests is for learning a new API or even a new language. Writing several assertions to validate our understanding and assumptions about an API usage is very rewarding as the feedback is rapid and progress towards a goal is constantly measured. These learning tests may be kept around to document the assumptions made that constitute the basis of our solution. Here is an example of a learning test for the Character.IsWhiteSpace() method of the BCL.


[TestMethod]
[Description(@"White spaces are the following characters: ' ', '\t', '\n', '\r'")]
public void May_be_a_white_space()
{
  Assert.IsTrue(char.IsWhiteSpace(' '));
  Assert.IsTrue(char.IsWhiteSpace('\n'));
  Assert.IsTrue(char.IsWhiteSpace('\t'));
  Assert.IsTrue(char.IsWhiteSpace('\r'));

  Assert.IsFalse(char.IsWhiteSpace('A'));
  Assert.IsFalse(char.IsWhiteSpace('+'));
}


A test can also document how to use the classes we create in our solutions. The following is an example of such a test. In our chess software, this unit test documents the way of obtaining a chess piece which is to call the NewPiece() factory method and passing it a color (either Color.White or Color.Black) and a Kind (such as Kind.Pawn) as arguments.


[TestMethod]
[Description("A chess piece consists of a kind and a color that are specified when the piece is created")]
public void Should_retain_its_color()
{
  Piece pawn = Piece.NewPiece(Color.Black, Kind.Pawn);
  Assert.IsTrue(pawn.IsBlack);
  Assert.IsFalse(pawn.IsWhite);

  pawn = Piece.NewPiece(Color.White, Kind.Pawn);
  Assert.IsTrue(pawn.IsWhite);
  Assert.IsFalse(pawn.IsBlack);
}


Documentation of behaviours

Unit tests document behaviours of our code. Test classes should be given names that provide context for all the test methods they contain.


[TestClass]
public class When_displaying_a_board
{
  [TestMethod]
  public void A_black_queen_should_show_as_Q()
  {
    …
  }
  …
}


Test methods should also be named in such a way that the behaviour they validate is evident.


[TestMethod]
[Description("The board is displayed on 8 lines with blacks pieces on line 8 and 7 and white pieces on lines 1 and 2")]
public void It_should_show_all_pieces_in_their_initial_position()
{
  Assert.AreEqual(
    "RNBQKBNR".Line() +
    "PPPPPPPP".Line() +
    "........".Line() +
    "........".Line() +
    "........".Line() +
    "........".Line() +
    "pppppppp".Line() +
    "rnbqkbnr".Line(),
    board.ToString()
  );
}


Notice that, instead of writing comments, I’m using the Description attribute to tie the behaviour being tested with some requirement or specification of the system. Personally, I’m not doing anything fancy with these descriptions, but you can imagine using a pattern that would provide more traceability in your environment as in the following.


[TestMethod]
[Description("US 234: Black pawns are shown as P, white pawns are shown as p")]
public void A_white_pawn_should_show_as_p()
{
  Piece whitePawn = Piece.NewPiece(
      Color.White,
      Kind.Pawn);
  Assert.AreEqual("p", whitePawn.ToString());
}


Documentation of design specifications

Now comes the fun part! Because of the thought we’ve put in selecting meaningful names when the tests are executed in Visual Studio we get a result screen that looks like this.

Notice how combining our test class and method names reads like a phrase that documents the design of our software. If we group the results by Description, we get a list of all the requirements of our software.

If we expand one of the requirements, we see all the tests that validate it so we can trace back to the code that implements it.

Conclusion

I hope I’ve convinced you that tests can serve as documentation using simple tricks, conventions and tooling you may already have at your disposal. Because this documentation is embedded in code it has a lot more chance of being maintained as the code evolves. These techniques require agreement amongst team members but they foster good practices of choosing explicit names and tying development work with planning activities for traceability purposes.

A new concept for the modern IDE, Code Bubbles allows developers to see and work different fragments of code as one unit. Debugging sessions can be associated with those units save and retrieved later for continued work. Quite impressive! It’s really a departure from the IDEs we’ve been using so far. Of course, this is not mainstream yet. Nevertheless, I would like to try something like that and it would probably be interesting to have the equivalent in the .Net space.

I have to wonder though, what the impact will be on Object Oriented Programming and encapsulation if developers are lead to think of their code as fragments of functionality scattered in their code base…

Dernièrement mes collègues et moi exécutions le Kata FizzBuzz dans le cadre de notre Dojo pratiques d’ingénierie. L’objectif était de pratiquer le développement piloté par les tests. Je dois avouer que ce fut fort amusant et la solution à laquelle nous sommes arrivés est tout à fait adéquate et présente un modèle objet élégant qui résoud le problème.

La séquence FizzBuzz est générée par la méthode CountTo de la classe FizzBuzz. Cette dernière utilise un ensemble de règles qui vérifient si elles s’appliquent et transforment, le cas échéant, l’entier question soit en “Fizz”, “Buzz” ou “FizzBuzzz”.

class FizzBuzz
{
    private readonly IRule[] _rules = new IRule[] {
        new FizzBuzzRule(),
        new BuzzRule(),
        new FizzRule()
    };

    private string[] RespondWith(List result)
    {
        return result.ToArray();
    }
}

La classe FizzRule est un exemple d’implémentation d’une rèlge.

class FizzRule : IRule
{
    public bool Applies(int number)
    {
        return ShouldSayFizz(number);
    }

}


Plus tard, je me suis demandé de quoi aurait l’air la solution si j’utilisais les fonctionnalités du langage C# 3.0 telles que LINQ, les expressions lambda et les méthodes d’extension. Avec notre batterie de tests comme garde-fou je me suis lancé dans une session de refactorisation au bout de laquelle je suis arrivé à la solution que je présente plus loin.

Les premières pistes que je choisis d’explorer sont les méthodes que Resharper suggère de changer en méthodes statiques. En fait, les méthodes statiques me font toujours penser à des méthodes utilitaires qui en général sont très réutilisables. C’est le cas par exemple des méthodes IsDivisibleByThree et ContainsThree de la classe FizzRule plus haut. Je les rassemble donc dans la classe IntExtensions après avoir introduit un peu de généricité pour qu’elles soient utilisables également dans la classe BuzzRule.

public static class IntExtensions
{
    public static bool Contains(this int n, int number)
    {
        return n.ToString().Contains(number.ToString());
    }

    public static bool IsDivisibleBy(this int number, int dividend)
    {
        return number % dividend == 0;
    }
}

Avec ces modifications, la méthode ShouldSayFizz se lit comme suit:

private static bool ShouldSayFizz(int n)
{
    return n.IsDivisibleBy(3) || n.Contains(3);
}
Je suis content car la lisibilité du code n’en souffre pas. Je m’attaque de la même façon à la méthode NumbersUpTo de la classe FizzBuzz. J’en fais une méthode d’extension que je rajoute à la classe IntExtensions. Je prends le soin de renommer la méthode FirstNumbers pour une meilleure lisibilité du code client qui se lira

foreach(int number in n.FirstNumbers()) { … }

Cela me rappelle mon cours d’analyse et la série des n premiers nombres entiers… En fouillant un peu dans MSDN, je retrouve comment générer une suite d’entiers grâce à la classe Ennumerable et je modifie mon implémentation en conséquence. J’obtiens le résultat suivant

public static class IntExtensions
{
    public static IEnumerable FirstNumbers(this int n)
    {
        return Enumerable.Range(1, n);
    }

    public static bool IsDivisibleBy(this int number, int dividend)
    {
        return number % dividend == 0;
    }
}

Avec ces méthodes utilitaires hors de la classe FizzRule, la responsabilité de celle-ci devient plus évidente et je la simplifie pour arriver au résultat suivant

class FizzRule : IRule
{
    public const string Fizz = "fizz";
    private const int Three = 3;

    public string Apply(int number)
    {
        return Fizz;
    }
}

Une bonne chose de faite! Je tourne mon attention vers la classe FizzBuzz. Même si j’ai sorti la génération des nombres entiers hors de cette classe, elle a encore trop de responsabilités: maintenir la liste des règles FizzBuzz, appliquer les règles qui conviennent, formater le résultat. C’est une violation évidente du principe de responsabilité unique (Single Responsibility Principle) de l’oncle Bob. Je décide donc séparer tout ce qui touche à la transformation FizzBuzz dans une classe à part. Les règles et tranformations FizzBuzz sont maintenant rendues dans la classe FizzzBuzzExtensions. J’ai changé l’implémentation pour utiliser LINQ étant donné que le résultat est plus compacte et tout de même très lisible.

static class FizzBuzzExtensions
{
    internal static IEnumerable AsFizzBuzzSequence (this IEnumerable sequence)
    {
        return sequence.Select(numeral => Transform(numeral));
    }

    private static readonly IRule[] Rules = new IRule[] {
        new FizzBuzzRule(),
        new BuzzRule(),
        new FizzRule(),
        new NumberRule()
    };
}

L’astuce d’encapsuler cette fonctionnalité en arrière d’une méthode d’extension facilite grandement la lecture de la classe FizzBuzz qui devient

class FizzBuzz
{
    public string[] CountTo(int n)
    {
        return RespondWith(n.FirstNumbers().AsFizzBuzzSequence());
    }

    internal static string[] RespondWith(IEnumerable result)
    {
        return result.ToArray();
    }
}

Séparer ainsi les responsabilités dans différentes classes a grandement augmenté la clareté du design. De plus l’utilisation de LINQ et des méthodes d’extension fait en sorte que le code est très compacte quoique très expressif. À vous d’en jugez. Voyez-vous d’autres pistes d’améliorations ?

Following is a conversation I had with a new Scum Master that had me thinking about how coaching works. It’s not about telling people what to do but allowing them to figure out what needs to bo done. One powerful tool to do just that is changing perspectives. Reliving the facts as they happened but from a different angle may generate insights that open new opportunities for the coachee. Below is the conversation as I remember it. I hope it generates some insights for you as well.

SM: So what do you think about the sprint planning the other day ?

Coach: Well one thing I noticed, and I did mention it on the spot, the team was about to bend some process improvement rules they agreed on implementing during the last retrospective. Your role as a Scrum Master is to make sure that the team follows its own process so that they may inspect and adapt it if need be. If the team partially implements the process in some cases and fully in some others, than interpretation of the results is more difficult and it will be harder to see what to improve next. You want to be careful when introducing changes to a process so that you know what you will be inspecting in the end.

SM: Well you are right. Sticking to our decision not to include big or unclear stories in the sprint made us realize that we were accepting to tackle underspecified functionality. No wonder our estimates were off and we were not able to complete all the stories in the sprint.

Coach: Good. But what about you ? What do you think about the sprint planning meeting ?

SM: Well, one thing that bugs me is that team members don’t participate in the process.

Coach: Oh? What do you mean ?

SM: I mean they don’t seem to care or are not motivated. For instance, in our Scrum Masters group we thought it would be a good idea to let developers take turn at the Scrum Master’s role in the daily meeting so that they realize what we are dealing with. When I asked my team if one of them would like to take my place I had to wait for a long time before someone reluctantly offered to conduct the daily.

Coach: So you want them to feel what it’s like to wear your shoes ?

SM: It’s not that. It’s just that team members are not getting involved. You witnessed what happened at the sprint planning meeting. When I asked them if they were able to commit on delivering the sprint backlog, I didn’t get an answer.

Coach: Well your organisation has a culture in which developers have been told what to do, when and how to do things. The change to self organisation is not going to happen overnight.

SM: I know. That’s why I want them to get involved in the process but they don’t want to get onboard.

Coach: And why do you think the don’t want to get onboard ?

SM: I don’t know. And that’s why I’m asking you this because I’m running out of ideas.

Coach: So… What are you doing that’s impeding them from getting involved in the process ?

SM: I’m not sure I understand the question… What do you mean ?

Coach: When you are not getting the response you’re expecting from others it’s often useful to consider that you are the one causing them to act the way they do. This empowers you to make some changes instead of waiting for others to change their behaviour.

SM: I’m not following you at all…

Coach: Ok. So let’s go back to that sprint planning meeting. Remember how the room was laid out and where everyone was sitting. You remember ?

SM: Yeah…

Coach: Let’s say you take John’s place. What do you see ?

SM: I’m really not sure where you want to go with this… But the only thing I see is that the monitor is too far away and its difficult to read.

Coach: Well that’s something to consider. And what are you doing in the meantime ?

SM: I’m updating the backlog and moving stuff around.

Coach: And how do you think John is perceiving this given the organisational culture ?

SM: I see… So we should probably use index cards that team members will be able to play with and update themselves.

Coach: Good! That way you solve two problems. By giving the team access to the sprint backlog you allow them to grasp more fully and own its content. They’ll probably feel more comfortable committing to it at the end.

SM (not really listening anymore): I can even update the backlog in the tool afterwards so that the flow is not interrupted. Thank you. That’s a great idea!

Coach: Well you know it wasn’t my idea. It’s yours. You just had to change your perspective on things.

SM (already leaving): Good. I’ll let you know how it turns out. Talk to you soon.

Coach (to himself): I’m not really sure what he saw exactly, but changing his perspective really allowed him to find new ideas on how to tackle this issue. This coaching stuff really works… I should blog this…

Lors d’une journée portes ouvertes organisée par Pyxis pour rencontrer des candidats potentiels, plusieurs d’entre eux ont manifesté leur intérêt pour les méthodes Agiles dont la popularité ne cesse de grandir. Toutefois, quand nous leur avons présenté les fondements des méthodes Agiles − à savoir qu’une équipe Agile valorise plus les personnes et les interactions que les processus et outils, un logiciel fonctionnel qu’une documentation exhaustive, une collaboration avec le client que la négociation d’un contrat, une adaptation au changement que le respect d’un plan préétabli −, nous avons semblé prendre à contre-pied les façons de faire élaborées pour contrer le manque de professionnalisme causant la déroute d’un bon nombre de projets informatiques qu’un scepticisme très sain les a poussés à poser quelques questions pertinentes. L’une d’entre elles était la suivante : comment, sans processus et documentation, peut-on espérer que les composants développés par différents membres d’une équipe s’arrimeront correctement entre eux?

Ce n’est certes pas la question la plus importante lorsque l’on pense au développement logiciel en mode Agile, toutefois s’y attarder quelques instants nous révèle certaines caractéristiques fondamentales de nos pratiques que nous avons tendance à négliger à force de les appliquer machinalement. Faire cet exercice est intéressant car, en prétendant faire table rase des façons de faire traditionnelles, nous devons par la même occasion indiquer comment les méthodes alternatives proposées abordent les problématiques auxquelles sont confronté les méthodes traditionnelles. Sans aucune prétention méthodologique, nous allons tout d’abord nous intéresser à la manière traditionnelle d’assurer la cohérence des différents composants d’un logiciel pour ensuite montrer comment, à partir des valeurs du manifeste Agile mentionné plus haut (c.-à-d. fondements des méthodes Agiles), une équipe Agile réussit à atteindre le même objectif. Nous laisserons au lecteur le soin de juger de l’efficacité de chacune des approches.

Méthodes traditionnelles

Dans le but d’assurer la cohérence du logiciel développé, les méthodes traditionnelles s’appuient sur un processus rigoureux dont chacune des étapes utilise les résultats fournis par l’étape précédente et complète entièrement toutes les activités prévues pour valider les résultats qui seront fournis à l’étape subséquente. C’est l’approche classique des méthodes dites en cascade. L’expérience ayant montré que les coûts associés à la détection et à la correction des erreurs grandissent avec le degré d’implantation du logiciel, ces méthodes tentent d’en minimiser les impacts en précisant dans le moindre détail le travail à réaliser avant de procéder à l’étape suivante. Ainsi, en début de projet, tous les éléments requis sont recueillis, analysés et documentés dans le but de circonscrire le système. Par la suite, un design élaboré est conçu et validé théoriquement par rapport à l’ensemble des éléments requis. C’est généralement à cette étape que l’équipe s’attaque à l’arrimage des différents composants du logiciel. Ce design est alors expliqué dans un document d’architecture qui servira de référence pour les prochaines étapes d’implémentation, de tests et de déploiement. Ainsi, l’étape de design élaboré joue un rôle clé dans ce type de processus car beaucoup d’efforts intellectuels sont déployés pour arriver à l’architecture la plus complète, la plus cohérente et la mieux documentée possible. Le document d’architecture joue également un rôle crucial en étant le principal outil sur lequel l’équipe s’appuie pour s’assurer de la cohérence du logiciel.

Voilà pour les méthodes traditionnelles. Maintenant, comment les méthodes Agiles font-elles pour s’assurer de la cohérence du logiciel? D’entrée de jeu, rappelons que le rejet de processus, d’outils et de documentation comme nous le percevons à la lecture du manifeste Agile semble être une recette pour une tour de Babel. Effectivement, sans ces moyens de contrôle, comment espérer garder la cohérence?

Méthodes Agiles

Lorsqu’on leur pose cette question, les experts Agiles nuancent presque systématiquement leurs propos en disant que les méthodes Agiles n’excluent pas tout processus et toute documentation mais plutôt privilégient d’autres moyens tels l’interaction entre les différents partis et un logiciel fonctionnel. À mon sens, cette réponse, quoique juste, laisse beaucoup à désirer car elle ne fait qu’éviter la question. Nous ne savons toujours pas comment ces interactions assurent l’arrimage des différents modules qui composent le logiciel sur lequel les équipes Agiles mettent tant l’accent. Et si les méthodes Agiles s’en remettent de toute façon à des processus et à de la documentation lorsque le besoin se fait sentir, alors pourquoi tout cet engouement pour ces soi-disant nouvelles approches? Devant l’insistance des sceptiques, les experts fournissent souvent en guise de réponse la réplique suivante : les équipes Agiles misent beaucoup sur la communication face à face.

Communication face à face

En général, les membres d’une équipe Agile se rencontrent fréquemment pour faire le point sur l’avancement du projet. Dans le cadre de SCRUM par exemple, la mêlée quotidienne fournie l’occasion idéale pour que les problèmes d’incohérence soient exposés et les personnes concernées avisées. Ces dernières pourront par la suite s’attaquer à la résolution du problème de la manière qui convient. De plus, les fins d’itération fournissent une autre occasion à l’équipe de démontrer ce qui à été accompli et de réorienter les activités de développement en se basant sur ce qui a été appris. Précisons que ces occasions utilisent l’un des canaux de communication les plus riches, à savoir l’échange face à face qui, contrairement à la documentation écrite, favorise la participation de tous les membres de l’équipe. Par ailleurs, les développeurs d’une équipe agile improvisent fréquemment des séances de modélisation autour d’un tableau qui enrichit d’avantage la communication en permettant la visualisation des modèles évoqués. Cette communication est constante tout au long du projet et garde une certaine cohésion au sein de l’équipe.

Modélisation Agile

Pourtant, il y a un hic. Si l’échange face à face est le canal de communication le plus riche, il est aussi le plus volatile. Ce qui est convenu lors de ces rencontres, s’il n’est pas pérennisé dans un document quelconque, risque de ne pas survivre au-delà de la mémoire ou du départ des participants qui y étaient présents. De plus, en absence totale de documentation, l’arrivée de nouveaux membres dans l’équipe exige la reprise de ces conversations qui à la longue deviennent ennuyeuses. À cet égard, les principes de la modélisation Agile fournissent des pistes de solution quant à la production, à la conservation et à la mise à jour des modèles élaborés lors de ces rencontres. Et là, il faut tout de même faire attention de ne pas retomber dans les mêmes pièges des méthodes traditionnelles à savoir que le document est roi et unique détenteur de vérité.

Mais ne sommes-nous pas retournés à la case départ? Si nous faisons abstraction des autres avantages des méthodes Agiles et que nous nous concentrons uniquement sur la façon d’assurer la cohérence du logiciel, nous retrouvons-nous seulement avec plus de communication face à face et une manière plus légère de documenter? Est-ce suffisant pour garder le tout cohérent? À mon avis, c’est loin d’être certain et, heureusement, c’est là que les pratiques d’ingénierie Agiles viennent à la rescousse.

Pratiques d’ingénierie Agiles

En valorisant plus un logiciel fonctionnel qu’une documentation exhaustive, les équipes Agiles déploient beaucoup d’efforts pour s’assurer que tel est bien le cas en adoptant les pratiques d’ingénierie ci-dessous.

Tests automatisés

Habituellement écrits par les développeurs, ces tests vérifient que le code se comporte tel qu’il était prévu. On parle de la stratégie « tester en premier » lorsque les tests sont écrits avant le code qu’ils sont supposés valider. Cette stratégie est privilégiée pour les tests unitaires, qui vérifient le bon fonctionnement du code en isolation des systèmes externes tels qu’un serveur d’applications ou une base de données. Lorsque les tests sont écrits après le code, on parle de la stratégie « tester en dernier » qui est plus appropriée pour les tests fonctionnels ou d’intégration. Dans les deux cas, le fait que ces tests soient automatisés donne la possibilité à l’équipe de s’assurer de l’intégrité du logiciel à n’importe quel moment, et ce, à faible coût. De plus, cette batterie de tests constitue un filet de sécurité protégeant contre d’éventuelles défectuosités qui risquent d’être introduites par des modifications insouciantes apportées pour implémenter de nouvelles fonctionnalités requises. Par ailleurs, les tests automatisés, surtout lorsqu’ils sont écrits en premier, constituent une documentation toujours à jour du logiciel puisqu’en quelque sorte ils en spécifient le comportement. Finalement, on encourage chaque développeur à fournir avec ses modifications l’ensemble des tests validant leur comportement.

Intégration continue

Afin de minimiser les coûts d’assemblage du logiciel, les équipes Agiles ont l’habitude d’en automatiser complètement le processus. Pour profiter au maximum de cette automatisation, les tests de développeurs mentionnés plus haut sont également inclus dans ce processus de telle sorte qu’avec une ligne de commande il est possible de s’assurer de l’intégrité du logiciel avant de soumettre les modifications au dépôt central de code source. Toutefois, cela ne s’arrête pas là. Ce processus est exécuté sur un serveur d’intégration à chaque fois que des modifications sont soumises au dépôt de code source afin de valider l’intégrité du logiciel dans un environnement qui se rapproche de celui dans lequel il sera déployé. Par la suite, un indicateur de réussite est transmis aux membres de l’équipe qui sont ainsi informés en permanence de l’état de santé du logiciel. L’équipe a alors les outils en place pour s’engager à toujours maintenir le système en bonne santé en vérifiant le résultat du processus d’assemblage avant de soumettre les modifications au dépôt central et en corrigeant immédiatement les problèmes d’intégration qui sont révélés sur le serveur d’intégration. L’ensemble de ces pratiques constituent le mode d’intégration continue.

Propriété collective du code

Dans une équipe qui met en oeuvre les tests automatisés de développeurs et l’intégration continue, il arrive souvent qu’un développeur fasse échouer un test qu’il n’a pas écrit. Une modification est donc requise soit au test, soit au code associé à ce test car l’un ou l’autre ne correspond plus aux nouvelles règles d’affaires codifiées par les modifications. Ce test qui échoue a un impact sur l’échéance du projet car le développeur ne peut pas intégrer ces modifications au dépôt central étant donné qu’elles vont faire échouer le processus d’assemblage automatisé. Pour minimiser l’impact, les équipes Agiles pratiquent la propriété collective du code, qui permet à un développeur de modifier n’importe quelle partie du code même s’il n’en est pas l’auteur. Bien sûr, la batterie de tests existante rend possible cette appropriation du code d’autrui, et le développeur est encouragé à rajouter autant de tests qu’il faut pour préciser et valider sa compréhension du code en question.

La programmation en binôme

Une pratique Agile qui aide beaucoup à la propriété collective du code est la programmation en binôme. Cette pratique veut qu’il y ait toujours deux développeurs à travailler sur une partie du code. Par exemple, le développeur ayant fait échouer un test qu’il n’a pas écrit peut se faire accompagner par l’auteur original du code pour s’assurer que la logique initiale ne soit pas complètement dénaturée si ce n’est pas nécessaire. Cette pratique favorise également la dissémination de la connaissance du logiciel puisque les paires formées ne sont pas statiques. Chaque développeur a donc la possibilité d’apprendre plusieurs parties du code en compagnie de ceux qui les ont conçues tout en enrichissant les fonctionnalités du logiciel.

Conclusion

La synergie existant entre ces pratiques décuple leurs effets sur la production de code de qualité et, exception faite de la programmation en binôme, il est rare de voir une équipe Agile adopter l’une d’elles sans les autres. La raison en est fort simple : l’ensemble de ces pratiques permet de livrer de nouvelles fonctionnalités itération après itération tout en s’assurant de la bonne santé du logiciel. Dans le cas qui nous intéresse, une équipe Agile investirait sans doute dans l’écriture de plusieurs tests d’intégration qui démontreraient le bon comportement des différents modules. Ces tests seraient inclus dans un processus d’assemblage automatisé de façon à révéler toute anomalie au niveau de l’intégration des modules. Ce processus d’assemblage serait exécuté en mode d’intégration continue réduisant ainsi au minimum le temps de réaction de l’équipe qui s’engagerait à toujours maintenir le logiciel en bonne santé. Chaque membre de l’équipe aurait le droit de corriger toute partie défectueuse du logiciel et pourrait compter sur l’aide d’un coéquipier pour le faire. Alors, la prochaine fois qu’on vous demandera comment une équipe Agile, sans documentation et ni processus lourd, s’assure de la cohérence des modules développés par différents membres de l’équipe, vous pourrez répondre : tout simplement en s’assurant en permanence que les modules fonctionnent bien entre eux.