🔒 😰 🤶 Dompter la bête: code hérité, tests et vous 👨🏽‍💻 👰🏻 👵🏼

Le code hérité est un «ancien» code, dont l'âge peut être à la fois de 2 mois et 10 ans. Souvent, les développeurs ont écrit à ce sujet, ce dont l'entreprise se souvient vaguement. Peut-être qu'ils n'existaient pas du tout, et le code hérité est né avec l'Univers pendant le Big Bang. Depuis lors, les exigences ont changé à plusieurs reprises, le code a été corrigé dans le mode «c'était nécessaire hier», et personne n'a écrit la documentation, comme les tests. Le code hérité est déroutant et fragile, il ne montre ni le début ni la fin. Comment l'approcher?

Ci-après des clichés de la série "Rick et Morty". Auteurs Justin Royland et Dan Harmon.

Vous devez le consulter avec des tests, mais préparez-vous à la douleur. Les problèmes commenceront déjà à partir du moment où vous décidez d'entreprendre un tel projet. Vous devez comprendre pourquoi vous souhaitez le faire, convaincre la direction d'approuver les tests du code hérité et aider vos collègues. Après cela, des questions se posent, par où commencer l'étude, quels tests exécuter en premier et comment ne pas tout casser? Mais l'essentiel est de ne pas tomber dans le désespoir quand on se rend compte qu'il n'y a pas de fin au travail.

Kirill Borisov 12 ans dans l'industrie, au fil des ans, il a parcouru un long chemin dans les béquilles, le code cassé et les cadres pourris des anciens systèmes: des systèmes comptables monolithiques aux microservices d'autorisation. Le voyage lui a valu de l'expérience et des histoires qu'il partagera sous forme de précieux conseils.

J'ai un rêve - un jour, travailler sur un nouveau projet. Tout ira bien dès le début et aussi frais que la première neige: tests, architecture et sens. Mais ce n'est qu'un rêve, car depuis 10 ans, je vends mon talent pour de l'argent et je passe d'un projet hérité à un autre.

Pendant ce temps, je n'ai plus de nerfs, mais je peux sauver le vôtre en partageant mon expérience d'interaction avec l'héritage. Je vais vous dire comment apprivoiser la bête (code hérité): travailler avec le code et les gens, implémenter les tests, si cela doit être fait et comment les développeurs s'y rapportent.

Ce qui ne sera pas ici:

Conseils pour la rédaction des tests. De nombreux livres, articles et vidéos diverses couvrent cette question.
Méthodologies de discussion. BDD, TDD, ATDD - le tout à votre discrétion.
Tout cela peut violer la NDA. Les gens ont une longue mémoire et les avocats ont les bras longs.

Qu'est-ce que le code hérité

Il existe de nombreuses définitions. Je crois que c'est un code " assez ancien " de 2 mois à 10 ans. Le code hérité est déroutant et fragile, mais comme un serpent géant dévore sa queue.

C'est ce qui ne vous permet pas de commencer à le tester sereinement. Tous les développeurs, des débutants aux plus expérimentés, lorsqu'ils arrivent à un projet hérité, saisissent une lance de tests et se précipitent pour tuer ce monstre. La lance se brise et avec elle les gens. En conséquence, il reste un développeur sans signes de vie, qui travaille sur un projet hérité depuis des décennies.

Est-il possible de vaincre cette bête? Oui, mais une préparation est nécessaire.

Entraînement

La lutte contre la bête n'est pas aussi importante que la phase préparatoire. Il commence par trois questions pour soi.

"Pourquoi est-ce que je fais cela?" Sérieusement, pourquoi? Après tout, il n'y a que deux options.

, , , .
, .

Voulez-vous travailler pour le confort des autres ou pour votre propre gloire? Si pour ce dernier, alors avec le premier succès l'intérêt se dissipera, vous disparaîtrez, tout disparaîtra. Vous passerez à autre chose, et les restes pourris de vos efforts obstrueront le projet pour longtemps.

"Est-ce que je sais ce que je fais?" Si vous avez écrit des tests, vous savez. Sinon, avant de vous précipiter sur le monstre, maîtrisez les bases: écrivez 3-4 tests, couvrez une petite partie du code, remplissez votre main et ressentez la puissance.

"Ai-je le temps pour ça?" C'est formidable d'intervenir dans le code avec de bonnes impulsions et de l'améliorer, en travaillant pour l'avenir. Mais il n'y a peut-être pas de temps pour cela lorsque le présent brûle. Si c'est le cas, alors le projet a besoin de vous, pas d'une image lumineuse de l'avenir.

Lorsque vous répondez à toutes les questions par l'affirmative, passez à l'étape suivante.

Reconnaissance

Examinez la structure du projet . Avez-vous une idée de la structure du projet, des composants et du principe de travail? Sûrement oui, mais peut-être que cela ne coïncide pas avec la réalité. Il est important de comprendre à quoi vous devez faire face avant de commencer à travailler. Consacrez du temps à parcourir le projet et à l'étudier en profondeur.

Faites un diagramme de dépendance . Aucun projet ne vit dans le vide. Bases de données, services externes, bibliothèques - tout cela peut être utilisé dans le projet.

Qu'est-ce qui vous a été fait? Vous n'êtes peut-être pas le premier à combattre la bête. Examinez les pratiques des «ancêtres» qui ont brûlé et quitté le projet.

Après la reconnaissance, nous passons aux hostilités.

Combattez avec l'organisation

Le premier tour est un combat avec votre organisation. L'essentiel est votre manager, patron direct.

Manager . Il n'est pas aussi effrayant qu'il n'y paraît. C'est une personne ordinaire avec des besoins ordinaires: livrer le projet à temps et sans problèmes inutiles, obtenir de l'argent et des bonus pour lui et vivre.

Le chef n'est pas contre vos engagements. Il est contre vous qui vous précipitez vers le projet avec des cris: «Des tests! Des tests! Tests! " Si vous le faites, il vous considérera comme la personne qui passe son temps et ralentit le reste.

Montrez l'avantage. Le manager parle la langue du bien, du temps et de l'argent. Comprenez qu'ils sont motivés par le désir de clore le projet à temps et d'obtenir plus de résultats pour moins de ressources.

Le test ne doit pas être soumis comme ceci:

- Oh, ce sera cool!

Nos idées devraient être promues comme suit:

- Au cours du dernier trimestre, nous avons eu 50 plantages qui pourraient être corrigés au stade du développement de produit. Vous pouvez le corriger à l'aide de tests. Ils confirmeront que les changements n'ont pas changé la fonctionnalité, si nous ne nous y attendons pas. Nous économiserons les heures passées à résoudre ces problèmes et réduirons le montant de la pénalité qui a été payée en raison d'un système défectueux.

Dire "optimisation, argent, gain de temps", vous parlez la langue du manager. Quand il entend ces mots, il est imprégné de l'idée. Il ne voit pas en vous le prochain programmeur enragé passionné par les nouvelles technologies, mais une personne qui souhaite améliorer le produit. Il n'approuvera pas toutes vos idées à la fois, mais il est très susceptible de proposer Proof Of Concept.

La preuve de concept augmente les chances.Fournissez au gestionnaire un morceau de code isolé distinct, un sous-système couvert par des tests, démarre et s'exécute. Cela peut être fait si vous prenez l'un des bogues douloureux qui apparaît à une certaine fréquence et essayez de l'attraper et de le corriger avec un test. PoC confirmera vos intentions, montrera que vous avez un plan et que votre travail porte ses fruits.

Ne promets pas grand-chose. Pour le manager, les chiffres sont importants: quels sont les résultats, le timing et par quelles forces. Mais le manager est une créature avide de résultats. Ne promettez pas trop dès le départ. Si vous vous engagez à résoudre tous les problèmes en même temps, le gestionnaire ira aux autorités avec cela. Les autorités diront: "Génial!", Mais réduiront le financement et les délais dans l'espoir que nous remettrons le système beaucoup plus tôt.

Lorsque nous sommes d'accord avec le manager, nous nous tournons vers ceux avec qui nous devons travailler tous les jours.

Collègues

Ils n'aiment pas le changement. Un collègue typique d'un projet hérité typique est une personne qui a perdu confiance en la vie et en l'avenir. Il n'est pas enclin à changer et s'est résigné au destin: "Je suis là pour toujours, il n'y a pas moyen de sortir du marais". Le problème est que vous commencez à remuer de l'eau dans ce marais. Vous exigez qu'il écrive et passe des tests, mais il veut faire son travail, terminer la tâche et rentrer chez lui.

Engagez vos collègues avec des avantages - expliquez pourquoi ils se sentiront mieux. Par exemple, ils passent constamment du temps et des efforts, restant après le travail pour guérir certains bugs. Appuyez dessus: «Si vous ne déployez pas un code cassé pour la production, vous n'aurez pas à passer du temps à le réparer. Nous allons écrire des tests, nous attraperons un tel code, il se cassera moins. "

Faites preuve de patience et d'empathie.Vous communiquez avec les gens - demandez pourquoi ils sont préoccupés par votre idée? Suggérez de trouver un terrain d'entente pour vous comprendre. C'est la principale tactique pour travailler avec les gens: ne vous querellez pas, ne vous heurtez pas le front, soyez plus amical.

Vous pourriez être empêché de présenter l'idée avant la réunion des collègues lors du prochain stand-up de l'équipe. Le mécanisme de la «pensée de groupe» fonctionne dans l'équipe: personne ne veut prendre de décision, tout le monde se regarde et voit que personne ne brûle d'enthousiasme.

Il y a une sale astuce pour résoudre ce problème. Malheureusement, dans ma vie, je l'ai utilisé plus d'une fois.

Diviser pour régner. Rendez-vous chez l'un de vos collègues au déjeuner ou dans le coin et dites: «Toute l'équipe est déjà inscrite, vous êtes la seule à ralentir le processus. Peut-être pouvons-nous trouver une langue commune? »

Après avoir parcouru tout cela tour à tour, vous signez tout le monde. Tout le monde aura honte d'admettre qu'il pensait que tout le monde s'était déjà inscrit. C'est déshonorant et terrible, mais ça marche. Utilisez cette technique de manière responsable et en dernier recours. N'oubliez pas - vous devez toujours travailler avec ces personnes.

Lorsque nous avons réglé avec nos collègues, nous attendons une autre bête gourmande.

Combattez avec la voiture

C'est l'astuce du code appelé produit. Commençons par les bases.

Démontez la poubelle. Il est nécessaire de tester afin qu'avec un impact minimal sur le système pour obtenir un résultat vérifiable. Mais tout système hérité est plein de données: elles ont été ajoutées pendant des années depuis le lancement et affectent le comportement du système. Par conséquent, il est nécessaire de tester "à partir de zéro".

Préparez un «système sphérique dans le vide»: videz les sources de données, effectuez le minimum de configurations que le système lance, désactivez tous les «hacks» et «fonctionnalités» possibles. Faites démarrer le système. S'il démarre, vous disposez de l'ensemble de données minimum nécessaire au fonctionnement. C'est déjà un bon point de départ - une "table rase".

En utilisant certains effets mesurables, par exemple, en appuyant sur un certain bouton, vous obtiendrez un résultat de travail mesurable. Avec cela, vous pouvez passer à l'étape suivante.

Démêlez les données. Tout projet hérité fonctionne sur le principe «doit être livré hier». Tout ce que vous avez fait à l'université ou lu dans des livres ne fonctionne pas ici. Lorsque vous commencez à tester, vous rencontrerez, par exemple, une dépendance cyclique, impossible à recréer dans le programme, mais nécessaire au fonctionnement.

Commencez par «l'objet principal». Pour gérer la forêt de dépendances, essayez de penser à quel objet est le principal. Par exemple, pour le système de comptabilité d'entrepôt, l'objet principal est la «boîte». Un objet "étagère" lui est associé, et un objet "ligne" est associé à une "étagère".

Recréez le minimum requis.Si vous examinez les liens entre les objets et approfondissez l'arborescence des dépendances, vous pouvez déterminer le minimum de données nécessaire pour les objets dépendants. Vous devez le recréer pour que le système fonctionne et puisse fonctionner pour tester vos fonctionnalités.

N'ayez pas peur de changer de liens. Vous devrez peut-être retrousser vos manches et plonger profondément dans ce gâchis: supprimer et modifier les liens, changer la structure de la base de données. Vous êtes venu pour améliorer le système, alors n'ayez pas peur de faire des changements.

Nous passons aux tests. Pour confondre les anciens produits, une bonne stratégie consiste à tester la fumée.

Tests de fumée

Le concept de "test de fumée" nous est venu du monde de l'électronique. Un ingénieur a assemblé un circuit géant avec un tas d'ampoules et de fils. Mais avant de commencer les tests, je viens de brancher le circuit sur une prise de courant. Si la fumée a commencé, alors quelque chose s'est mal passé.

Dans les systèmes d'information, le concept des tests de fumée est assez simple. Imaginez un service Web, il a un point final. Essayons de lui envoyer une requête GET sans paramètres. Si, pour une raison quelconque, le produit se cassait soudainement (erreur 500), quelque chose s'est mal passé.

Le test de fumée est un bon début . Il s'agit d'un test qui teste certaines fonctionnalités et indique clairement que le système fonctionne ou est en panne. Même une simple demande au point de terminaison le plus simple affecte déjà plus de 1% du code. Avec de si petits tests, nous préparons un tremplin pour de nouveaux tests.

Le test de fumée révèle de nombreux problèmes. Il est possible que pendant toute la durée du fonctionnement du service personne n'ait deviné envoyer une demande sans paramètres.

Utilisez cette tactique pour couvrir plusieurs points d'entrée principaux dans votre programme: formulaire de saisie de login / mot de passe, services Web de base, boutons. C'est quelque chose que vous pouvez déjà montrer au manager et à ses collègues.

Tests de fonctionnement

Ce ne sont pas des tests de classes individuelles ou d'une méthode, mais le plus haut niveau possible de test d'une certaine partie de la fonction.

Imaginez la fonctionnalité pour «générer un rapport dans le service». Au lieu de vérifier des pièces individuelles, nous testons la situation de la demande pour créer un rapport avec certains paramètres et obtenir un fichier de données. Il n'est pas nécessaire de connaître le mécanisme de génération du rapport, mais si le service donne certaines données de sortie avec certaines données d'entrée, alors cette boîte noire avec une certaine probabilité fonctionne comme il se doit.

La couverture de la fonctionnalité principale avec de tels tests vous permet de démarrer rapidement et couvre immédiatement de grandes zones. Vous serez sûr que le code fonctionne au moins approximativement comme vous l'imaginez, gagnez en confiance, remplissez votre main et révélez encore plus de problèmes.

Les tests fonctionnels sont un moyen et non une fin.

Il est facile de devenir accro à l'aiguille de test fonctionnel: "Je teste de vraies fonctionnalités! C'est à cela que les utilisateurs sont confrontés. »

Un test fonctionnel implique de gros morceaux de code qui peuvent interagir avec des quantités gigantesques de données. Par conséquent, 3-4 tests fonctionnels sont bons, 10 sont pires et des milliers de tests qui prennent 9 heures sont trop. Malheureusement, cela se produit également.

Après les tests fonctionnels, faites des tests unitaires. Mais je n'en parlerai pas - vous savez déjà tout.

Nous sommes passés par les bases du test des machines et revenons au sujet principal. Les collègues et le manager ne sont pas le pire ennemi dans une bataille avec l'héritage. Le pire ennemi est vous-même.

Combattez avec vous-même

Soyez prêt pour le fait que le chemin vous semblera sans fin . Travailler pendant une semaine dans votre plan prendra six mois sans perspective de terminer le projet.

La résistance est inévitable . Tous les alliés finiront par douter, tenteront de s'écarter, les persuaderont de quitter les tests et de passer aux fonctionnalités. Soyez prêt pour cela. Rappelez à chacun pourquoi vous vous êtes impliqué dans tout cela, combien d'efforts et de temps ont été investis. Argument faible, mais pourrait fonctionner.

Personne ne garantit le succès . Même si vous montrez des efforts héroïques, vous mettez tous au travail, votre projet peut encore s'épuiser et la croisade avec les tests ne se terminera en rien.

C'est normal, ce n'est pas la fin de la vie et de la carrière. Ce n'est même pas la confirmation que vous êtes un pauvre professionnel. La seule conclusion ici est que ce projet particulier a échoué.

Mais alors vous avez de l'expérience et des connaissances. La prochaine fois, lorsque vous prendrez une nouvelle lance dans votre main et que votre cheval accélérera vers un autre moulin à vent, vous serez également prêt à casser cette lance, mais plus tard, par une méthode différente et avec moins de dégâts.

Désormais offensant, amer et éternel.

Mots de séparation

N'ayez pas peur des commentaires. J'ai dû entrer dans ce piège et voir comment les autres y tombaient. J'ai fait quelque chose et amené des collègues à se vanter: "Je l'ai fait!" Mais soudain, il s'avère que mon mécanisme pratique ne convient pas aux collègues, et je n'ai pas demandé.

Écrivez des tests, essayez ce que vous implémentez . Souvent, l'introduction d'un nouveau cadre de test est fascinante, mais vous n'écrivez pas les tests eux-mêmes. Ensuite, il peut arriver que dès que vous les écrivez, vous comprendrez que vous ne pouvez pas utiliser les tests. Peut-être que des collègues le voient également, mais sont silencieux, ou n'écrivent tout simplement pas de tests.

Aidez vos collègues en difficultémême s'ils ne le demandent pas. L'aide ne signifie pas prendre tout le travail sur vous-même - elle détend les collègues et les décharge de leurs responsabilités, et le nombre de "bus" tombe à l'unité. Ensuite, vous devenez un testeur humain: quelque chose s'est cassé, CI rouge, guide de test. Aide dans le cadre du raisonnable.

Le numéro "bus" n'est pas une blague. Vous ne pouvez pas toujours faire glisser le projet sur vous-même. Tout le monde peut s'épuiser, partir en vacances ou arrêter de fumer. Par conséquent, transmettez à vos collègues vos connaissances et votre responsabilité, ce qui est nécessaire pour faire face à vous. Cela vous aidera à éviter les appels désagréables lorsque vous vous détendrez sur la plage, et CI redevient rouge.

Améliorer les mécanismes de test. De nombreux problèmes peuvent être évités simplement parce que les tests lents sont devenus soudainement rapides. Auparavant, ils occupaient 20 lignes de code, mais maintenant une. Vous ne l'avez pas remarqué, car une fois que vous avez écrit quelque chose et que vous avez oublié: "Ça marche - ne le touchez pas!" Mais cette règle n'est pas toujours applicable.

Vous n'êtes pas le centre de l'univers. Encore une fois, je répète que le numéro "bus" n'est pas une blague. Plus d'une fois, je suis tombé sur une situation où une personne a commencé à tester, puis a reçu une offre pour le projet plus frais: il a tout quitté, s'est enfui, mais n'a pas laissé de commentaires et de documentation. Tout fonctionne jusqu'à un nouveau commit, mais il est impossible de le corriger - personne ne comprend comment tout fonctionne.

Je ne veux pas que tu sois cette personne. Ne vous transformez pas en facteur limitant.

Écrivez la documentation.
Mener des formations.
Partagez votre expérience.

Lorsque tous les collègues sont au même niveau que vous (plus ou moins), le processus passera d'une course d'une personne à une course de relais par équipe avec le passage du drapeau. Ce n'est que grâce au soutien de vos collègues que vous réussirez. Si vous êtes seul sur le projet, pensez que quelqu'un d'autre après vous souffrira également seul. Donnez à votre disciple un ami sous forme de documentation, ne laissez pas mourir seul.

27 Moscow Python Conf++ Python 2 Python 3 — 2020 .

, (fb, vk, twitter) telegram- . !

Dompter la bête: code hérité, tests et vous