Azure Native Qumulo Maintenant disponible dans l'UE, au Royaume-Uni et au Canada - En savoir plus

Construire une équipe d'ingénierie plus collaborative et efficace avec TDD et couplage

Rédigé par:

J'ai récemment parlé à un testeur de logiciel et je n'ai pas pu m'empêcher de lui demander son opinion sur développement piloté par les tests (TDD) car c’est une pratique obligatoire chez Qumulo pour nos équipes d’ingénierie.

Pour paraphraser ses sentiments, il dit:

Je pense que les tests unitaires sont importants, mais les développeurs ne pensent pas souvent du point de vue de l'utilisateur lorsqu'ils écrivent leurs tests. Au lieu de cela, ils pensent à la mise en œuvre et à la manière dont ils s'attendent à ce qu'elle fonctionne, ce qui n'est pas souvent le cas.

Son parti pris en tant que testeur n'est pas perdu pour moi, mais je conviens que quelqu'un dont le travail consiste strictement à rédiger des tests fonctionnels peut apporter un état d'esprit bien nécessaire au cycle de publication. Je pense également qu'il est important que les développeurs de fonctionnalités partagent cet état d'esprit, car les ingénieurs logiciels sont les concepteurs d'abord et les codeurs ensuite. Nous devons réfléchir aux cas d'utilisation, à la manière dont les problèmes peuvent mal se produire et à la manière d'atténuer les dégâts lorsque des problèmes se produisent inévitablement..

Chez Qumulo, nous concevons en permanence un processus d’intégration et de croissance pour nos ingénieurs qui renforce ces compétences, qui comprend l’utilisation du TDD pour faciliter ce processus de croissance.

Un ingénieur n’est en réalité qu’un scientifique qui tente de résoudre les problèmes des clients. D'après mon expérience, la contribution la plus précieuse de TDD est la manière dont il facilite la méthode scientifique pour les ingénieurs qui la pratiquent. Lorsque vous écrivez un test unitaire, vous faites une hypothèse que si, et seulement si, Si vous modifiez le code de production, vous satisferez aux propriétés revendiquées par votre dernier test. Ce sont en fait deux hypothèses composées:

  • Le code de production existant ne satisfera pas les propriétés revendiquées par votre nouveau test.
  • Le code de production modifié satisfera aux propriétés revendiquées par votre nouveau test.

Sans TDD, vous pratiquez une mauvaise science en oubliant de réaliser votre expérience sur une population de contrôle. Il se peut que votre test se soit passé sans modifier le code de production, ce qui signifie que votre test contient un bogue ou ne communique aucune nouvelle propriété du code de production.

La base de code de Qumulo est comme un cahier de laboratoire. Nous avons plus de tests 55,000 qui documentent toutes les expériences effectuées sur le code de production. Il communique ce que nous savons sur le code et chaque test n'a que la même valeur que ce qu'il communique au lecteur. Il se peut que notre compréhension des besoins du client ait changé et que, par conséquent, le code et ce que nous en savons devraient évoluer. Il appartient aux ingénieurs de décider si un test est utile, sinon il est supprimé.

En facilitant la méthode scientifique, TDD permet aux ingénieurs de se concentrer sur un problème plus troublant: quels tests manquons-nous? C'est le principal défi du processus de conception, car il oblige les ingénieurs à se mettre dans la tête de leurs clients. Cela les oblige à considérer qui sont nos clients? Comment vont-ils exercer notre code? (Notez que les «clients» peuvent inclure d'autres ingénieurs qui utilisent votre code.)

Et le processus de conception est toujours collaboratif, car il est dangereux d’y aller seul!

"Ce qu'un programmeur peut faire en un mois, deux programmeurs peuvent le faire en deux mois." - Fred Brooks

Je mets les mots de Fred hors du contexte ici, mais si «ce qu'un programmeur peut faire» est d'écrire des bogues, alors la déclaration de Fred prend un nouveau sens: deux programmeurs écrivent autant de bogues en deux mois qu'un programmeur écrit en un. mois! Mais sérieusement, lorsque vous vous entraînez à la TDD, chaque bogue que vous écrivez est en fait un test que vous n’avez pas écrit. Deux programmeurs en paires d’ingénieurs penseront à plus de tests qu'un seul ingénieur. Il a également tendance à produire un code plus propre avec de meilleurs noms de variables et de fonctions. En général, la discipline est plus forte avec chaque personne tenant l'autre responsable.

Nous recommandons donc que paire d'ingénieurs par défautet cela ne s'arrête pas au codage. Chez Qumulo, nous écrivons des user stories, des tâches et résolvons des problèmes sur un tableau blanc par paires. Le jumelage ne réduit pas seulement le nombre de bogues, il diffuse des informations sur les domaines problématiques et (en prime), c'est amusant.

C'est amusant si vous le faites correctement. Alors, comment enseignons-nous à nos ingénieurs à tester et à coupler efficacement?

Nous avons récemment ajouté un événement à notre processus d'intégration appelé TDD and Pairing Workshop. Nous faisons des présentations sur le TDD et le couplage, discutons des avantages et des inconvénients et pratiquons tout ce que nous avons appris en l'appariant sur un kata (petit problème de pratique censé être répété fréquemment). Nous utilisons les styles ping-pong, pilote / navigateur et mobbing pour appliquer un TDD strict et mettre en œuvre une bibliothèque de conversion des chiffres romains en décimales, et inversement.

Les participants se plaignent souvent des mêmes problèmes d’appariement et de TDD:

  • Je suis mal à l'aise avec quelqu'un qui regarde; il est difficile de penser clairement.
  • Je suis souvent coincé dans un désaccord avec mon partenaire et je perds du temps.
  • Je me sentais comme si j'étais juste une machine à écrire à la merci du navigateur; Je n'ai pas suivi le problème que nous étions en train de résoudre.
  • Je sens que mon partenaire est distrait pendant que je fais tout le travail.
  • TDD est inefficace; Je finis par écrire du code inélégant et le réparer plus tard.

Nous avons pratiqué ces aspects de programmation extrême (XP) depuis des années chez Qumulo, nous avons donc résolu ces problèmes et avons proposé les leçons suivantes aux nouveaux employés:

  • Définissez des objectifs et des procédures opérationnels clairs et réalisables pour votre session d'appariement before tu commences.
  • Si vous constatez une baisse de productivité, faites une pause.
  • Si vous n'avez pas beaucoup d'expérience en couplage, cela peut être épuisant. Informez votre partenaire et vous pourrez changer le discours en un événement moins intense.
  • Si vous ne pouvez pas surmonter un désaccord, faites appel à une tierce partie pour la médiation.
  • Si vous perdez le fil, indiquez à votre partenaire que vous souhaitez changer de rôle ou de style pour ralentir le processus. Ce n'est pas bon d'être laissé pour compte.
  • Une partie de TDD écrit le code le plus simple possible à ce moment là.Vous devez souvent identifier une abstraction et un refactor (voir Lieu de transformation prioritaire).

En plus de l'atelier, le jumelage et le TDD sont généralement encouragés par nos équipes d'ingénierie. Chaque équipe dispose d'un coach technique dont le but est de communiquer les normes de codage et d'aider les membres de l'équipe à trouver des conceptions et des factorisations de code pouvant être testées.

Il est facile d’être sceptique à propos de XP si vous ne l’avez pas pratiqué assez longtemps pour en profiter. Nous constatons que le TDD et le jumelage aident les ingénieurs à devenir des scientifiques et des concepteurs compétents qui communiquent plus efficacement et laissent leur ego à la maison. Vous pourriez être tenté de revendiquer la gloire d'avoir créé vous-même un magnifique flocon de code, mais en l'appariant, vous êtes forcé de réaliser que le code est conçu pour que tout le monde puisse le concevoir, le lire et le réutiliser. l'attacher à votre fierté personnelle.

Articles Similaires

Remonter en haut