Aucune startup ne démarre avec un testeur. Puis 2 ans plus tard, cette startup ne peut pas publier une nouvelle fonctionnalité pour son plus gros client à moins qu'elle ne réécrive le tout avec un grand coup. C'est douloureux de revoir ça encore et encore. Il y a des choses simples à faire pour garder la qualité sanitaire de notre logiciel, ainsi vous ne vous retrouverez pas dans cette situation. Tout d'abord, embrassez vos peurs. Les ingénieurs sont des gens courageux, et nous n'admettons pas facilement que nous avons des inquiétudes. Mais nous l'avons fait, et plus tôt nous admettrons et partagerons ces préoccupations, plus tôt nous nous préparerons à y faire face. Comment nous créons des logiciels aujourd'hui Nous sommes tellement pressés que nous sommes toujours en retard. Il n'y a pas de temps pour les tests. Il n'y a pas de temps pour les tests unitaires. Il n'y a pas de temps pour refactoriser. Eh bien, il n'y aura jamais assez de temps pour bien faire les choses pendant que nous continuons à nous saboter en tant qu'équipes d'ingénierie. On nous demande combien de temps cela prendra, et nous continuons d'exclure les tests unitaires, les tests manuels et même les tests et refactorisations d'API de nos estimations. Nous construisons donc un logiciel comme celui-ci : Rapide et sale Pas rapide, toujours sale Chemin diagonal rapide et heureux testé Tout le reste est considéré comme un cas limite. (Il n'y a pas de cas marginal.) Peu d'entre nous sont encore plus courageux pour dire non au rapide ou au sale et créer un logiciel rapide et stable. Ce que vous devez retirer de vos estimations, c'est la portée, pas la qualité. Que savez-vous de la qualité de ce composant sur lequel vous travaillez ? Vous savez que c'est fragile, mais vous ne voulez pas y toucher car c'est très fragile. Vous l'avez fait il y a longtemps, vous y touchez à peine, ça devrait marcher. Vous ne savez pas que c'est fragile. Il n'y a pas de tests et personne pour tester et exposer à quel point il est réellement fragile. Êtes-vous heureux de traiter tous les jours avec ce logiciel sale ? Êtes-vous heureux de faire des compromis avec la qualité de votre travail tous les jours, sachant que c'est loin d'être bon ? Faire face à "nous n'avons pas le temps de nettoyer" et être toujours en retard parce que c'est sale et que vous ne pouvez pas continuer sans le nettoyer. vous êtes à votre prochain entretien d'embauche. De quoi allez-vous vous vanter dans votre travail actuel ? Que vous pouvez performer sous pression et faire des corrections tard dans la nuit ? Ils vous aimeront pour cela, mais ils vous demanderont aussi pourquoi vous n'avez rien fait à ce sujet. Peut-être que ce n'était pas votre travail. Imaginez que Il y avait des chefs d'équipe et des responsables techniques pour prendre ces décisions. Si ça ne tenait qu'à toi, tu aurais fait quelque chose. Vous leur avez dit que le code devait être refactorisé et que vous deviez prévoir du temps pour le service technique à chaque rétro, et personne n'a écouté. Eh bien, devinez quoi - vous n'avez pas besoin de permission. La qualité de votre travail ne dépend que de vous. Personne ne peut vous forcer à écrire du code merdique. La pression du temps est une excuse à court terme. Les solutions rapides et sales retardent l'ensemble du projet et coûtent plus cher que si vous le faites correctement du premier coup. Vous ne le réparerez jamais plus tard Êtes-vous prêt à faire cette différence ? Alors, voici ce qu'il faut faire : se discipliner. Je suis désolé, mais il n'y a pas d'autre solution. Et cela devrait être à tous les niveaux. Quelles devraient être vos premières étapes pour construire un code de meilleure qualité ? Mettre en œuvre la journalisation et les alertes Il existe des tonnes d'outils de journalisation et d'alerte. C'est la première chose à faire. Votre logiciel plante et vous n'en êtes absolument pas conscient. Trouvez une solution qui vous permet de créer facilement des tickets à partir des alertes d'exception et de les marquer comme "connues" ou de les regrouper une fois qu'elles sont signalées. Créez une routine d'équipe pour surveiller et signaler les alertes Si vous pensez que c'est ennuyeux, permettez-moi de vous demander : êtes-vous profondément dans la zone pendant toute votre journée de travail ? Après toutes les réunions et le lourd travail de programmation, vous devez relâcher un peu votre concentration. Eh bien, parcourir le canal des alertes est bien meilleur que de naviguer sur n'importe quel autre canal. Cliquez simplement sur le bouton "Signaler un ticket" ou sur le bouton "Marquer comme connu". Et si vous étiez intrigué, vous en répareriez probablement un ou deux. Voici le plus gros argument - nous pouvons corriger quelques-uns, mais nous écrivons des tests que quelqu'un doit confirmer, nous devons déployer, et cela génère plus de travail imprévu pour l'équipe. Le Premier ministre nous criera que nous ne travaillons pas sur les éléments hautement prioritaires, mais sur de petites alertes plaquées or. L'équipe avec tous les rôles "M" en convient. Publiez une règle empirique - "Si cela semble petit et à faible risque, et qu'il n'y a absolument aucun autre travail en cours, allez-y et corrigez-le. Nous pouvons gérer une ou deux petites alertes corrigées "hors de portée" par Sprint , ainsi que ceux prévus." Voilà, très simple. Commencer à nettoyer les journaux et les alertes un par un En plus des correctifs occasionnels, planifiez correctement le nettoyage. Notez que par planification, j'entends allouer du temps quotidien/hebdomadaire pour les corriger . Vous perdrez plus de temps à évaluer leur priorité qu'à corriger les 5 premiers. Alors, commencez simplement à corriger. , quelle que soit leur gravité ou leur priorité Assurez-vous qu'il y a une alerte pour chaque développeur, ou si vous mobbez la plupart du temps, définissez un créneau horaire quotidien pour les alertes. Et je le ferais dès le matin parce que sinon, tu ne le feras jamais. Encore une fois, ce n'est pas une nouvelle fonctionnalité, et il peut sembler qu'elle prend le temps de vos priorités critiques, mais vos priorités critiques sont déjà en retard à cause de ces problèmes cachés. Vous êtes déjà en retard ! Supprimez toutes les instructions Try-Catch vides et laissez-le planter ! Bien que les alertes et la journalisation exposent beaucoup de choses, elles ne pourront pas enregistrer ce que vous cachez. Alors arrêtez de balayer vos problèmes sous le tapis. Ce qui s'est écrasé il y a 2 ans, et vous ne saviez pas pourquoi est complètement différent aujourd'hui. Laissez-le planter et réparez-le. Il ne plantera probablement même pas de la même manière, ou ne plante même pas, donc d'une manière ou d'une autre, votre code sera en meilleure forme sans ceux-ci. Commencez à écrire des tests unitaires dès maintenant Je suis sérieux. Vous travaillez sur du code en ce moment. Ensuite, rien ne vous empêche d'écrire un test unitaire. Oh je vois! Il n'y a pas d'infrastructure prête pour les tests unitaires, n'est-ce pas ? Allez! Vous allez de toute façon retarder cette fonctionnalité en herbe. Vous n'avez pas besoin de plus d'une journée pour configurer le framework de test unitaire et votre CI pour exécuter les tests. Fais-le c'est tout. Démarrer TDD pour les corrections de bogues "Nous ne savons pas quel est le problème et comment nous allons le résoudre. Nous ne pouvons pas écrire de tests pour du code qui n'existe pas encore." Cher développeur, le but des tests est de vérifier une hypothèse. C'est valable pour les tests en général, pas seulement pour les tests de logiciels. Donc, ce dont vous avez besoin pour écrire un test n'est pas le code. Vous avez besoin du comportement et du résultat attendus. Maintenant, si les user stories sont vagues et peu claires et que vous n'êtes pas prêt à commencer à écrire des tests par rapport aux user stories, j'ai une solution pour cela aussi, mais avant cela - commencez à écrire le code test-first pour les bogues. Il y a un composant de la description du bogue appelé "Résultat attendu", et les étapes à reproduire sont votre cas de test. Vous avez donc déjà le cas test devant vous. Maintenant, codez-le d'abord avant de commencer à coder le correctif. Le développement piloté par les tests consiste à écrire un test qui valide que vous avez fait le bon travail, et non que vous l'avez bien fait. Les tests unitaires vérifient si vous avez bien fait les choses. Dessiner une feuille de route de couverture L'automatisation des tests et la dette technologique ont des destins tragiques similaires - ils ne sont jamais commencés parce que "nous ne pouvons jamais tout couvrir, nous ne pouvons jamais tout nettoyer, c'est trop de frais généraux. Nous n'avons pas le temps pour cela". Écoutez-moi : vous n'êtes pas obligé de tout automatiser ! Mais vous devez absolument automatiser vos éléments critiques - cas d'utilisation hautement prioritaires, infrastructure critique et fonctionnalités de base. Appelez ça comme vous voulez, mais l'entreprise dépend de 20 % de votre code et de votre infrastructure, et vos clients utilisent 20 % de vos fonctionnalités. Vous voyez où je veux en venir. Vous n'avez même pas besoin de commencer à écrire des tests automatisés pour ces fonctionnalités dès maintenant. Ce que vous devez d'abord faire, c'est les prioriser. Rassemblez-vous en équipe devant vos diagrammes d'architecture de haut et de bas niveau. Il n'y en a pas, n'est-ce pas ? Ou celles qui existent sont une photo d'un tableau blanc prise il y a 2,5 ans ? Je sais. Oui, vous devez passer une demi-journée et les mettre à jour. La bonne nouvelle est qu'il existe des outils amusants pour vous aider, vous n'aurez donc pas besoin de le maintenir manuellement. Fais quelques recherches. Vous êtes une équipe de R&D, après tout, n'est-ce pas ? ! Ne visez pas une couverture complète - visez plutôt un risque faible et une confiance élevée Tout en schématisant votre architecture et votre infrastructure à jour, ajoutez des notes ou des cercles, ou mettez en gras ou peignez en rouge tous les endroits qui sont : Essentiel à la mission de votre entreprise et de vos logiciels Vous avez désespérément besoin d'être refactorisé, sinon vous reporterez sans cesse cette autre fonctionnalité essentielle à la mission. Casser constamment et manger votre temps pour les réparer est à peu près vain car ils se casseront à nouveau dans quelques jours. Lorsque les dessins sont prêts, asseyez-vous avec votre équipe et réfléchissez à ce qui doit être testé pour tous ces composants encerclés. Ne tombez pas dans le piège du "c'est trop ! Il faut arrêter tout autre travail pour couvrir tout ça !" Vous n'êtes pas obligé de couvrir tout cela à la fois. Mais vous avez besoin d'un plan. Maintenant, ouvrez un autre tableau et commencez à écrire vos objectifs de test. Exemples: Couvrez toutes les demandes d'API d'extraction de données pour le succès et l'échec afin que vous sachiez que vous n'envoyez pas de mauvaises demandes, et si cela échoue, c'est à cause du fournisseur. Décrivez le parcours utilisateur critique. Décomposez-le en unités. Ecrire les tests unitaires. Lorsque la pyramide de test a été inventée, une unité signifiait un composant, pas une méthode, elle couvrait donc la fonctionnalité, pas les méthodes et les classes. Identifiez les embouteillages et décidez comment vous allez les démêler. Prévoyez de le faire correctement. Votre code rapide et sale restera sale avec des tests sales. J'ai intentionnellement utilisé une carte de couverture et non la pyramide de test car... à ce stade, lorsque vous n'avez pas de tests en place, manuels ou automatisés, vous n'êtes pas prêt pour la pyramide. De nombreuses équipes ont la fausse impression qu'elles doivent d'abord atteindre une couverture de test unitaire de 96 %, puis passer aux tests d'intégration, etc. Le problème avec la couverture des tests unitaires modernes est que nous testons les méthodes et les classes, pas les fonctionnalités. Encore plus d'équipes commencent par l'automatisation de l'interface utilisateur, ce qui est tout aussi faux. C'est en fait la pire chose que vous puissiez faire, et c'est voué à l'échec. Ne partez donc pas du haut ou du bas de la pyramide, mais construisez plutôt une carte des risques. Certaines fonctionnalités peuvent nécessiter des tests d'intégration approfondis, d'autres fonctionnalités peuvent nécessiter des tests d'interface utilisateur approfondis, et la partie suivante peut en effet être une fonctionnalité essentielle dont tout dépend (un autre drapeau rouge, cependant), et vous devez la couvrir de haut en bas entièrement. Ou c'est un service de collecte de données, et vous devez vous concentrer sur les performances des API, par exemple. Créez une carte de vos points chauds logiciels nécessitant des tests intensifs. Réfléchissez ensuite à la manière dont vous pouvez automatiser ces tests. Vous ne pouvez pas progresser dans les sables mouvants et vous seul pouvez vous en sortir Finissons-en - il n'y a pas de test, le code est en mauvais état et vous n'avez pas le temps. Vous n'arrêtez pas de faire des compromis parce que "vous n'avez pas le temps". Vous n'êtes pas entièrement satisfait, ou du moins vous êtes assez ignorant - ils paient, c'est leur décision, et ce n'est pas votre décision. S'ils ne sont pas satisfaits, vous passerez à l'entreprise suivante. Eh bien, les choses ont beaucoup changé l'année dernière, n'est-ce pas ? ! Vous devez être un développeur exceptionnel pour rester embauché. Les entreprises ont appris qu'elles pouvaient jeter des gens quelle que soit leur contribution. Pourtant, il y a des ingénieurs qu'une entreprise fera tout pour garder. Pour en faire partie, vous devez conduire le changement et prouver constamment que l'entreprise dépend de personnes comme vous. Tout le monde peut écrire des logiciels de merde, mais les très bons non seulement écrivent d'excellents logiciels avec joie, mais inspirent également les autres et diffusent la culture de la qualité du code. Vous ne pouvez pas progresser dans les sables mouvants, et vous seul pouvez vous en sortir.

Read My Stories

Say "Hi!"

Buy Me a Coffee

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

Vous ne le réparerez jamais plus tard - Comment sortir votre équipe des sables mouvants

Trop long; Pour lire

Hris Koleva

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Vous ne le réparerez jamais plus tard - Comment sortir votre équipe des sables mouvants

Trop long; Pour lire

Hris Koleva

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES