Get best of the week

Comment faire en sorte qu'une voiture écrive des tests à partir du code pour vous

Nous vivons dans un monde imparfait. Les gens écrivent du code ici, et les gens sont naturellement enclins à faire des erreurs . Tout irait bien, des erreurs peuvent être détectées au stade des tests et ne pas être autorisées à nuire à quiconque. C'est possible si vous écrivez des tests. Ce que les gens n'aiment pas faire pour une raison quelconque. Mais il y a peut-être de l'espoir - la génération automatique de tests à partir de code écrit.

Julia Volkova veut tester l'idée en réalité et essaie de déplacer la création de tests basés sur du code vers une machine, sans utiliser d'instructions ou de contrats supplémentaires. Julia vous racontera les découvertes que le voyage apporte au monde de la métaprogrammation, de l'AST, de l'analyse syntaxique et de la tokenisation, et ce que tout cela nous a permis de réaliser dans la génération automatique de tests, à Moscou Python Conf ++. En attendant, j'ai demandé d'où venait l'idée - pour automatiser les tests, quelle est la base du prototype et ce qui reste à faire.

Julia Volkova (xnuinside) Senior Python Developer GridDynamics. pet-, . , legacy-, , . , «» . -, .

— , , , ? , . ?

- Je pense qu'il y a plusieurs raisons. Premièrement, la plupart d'entre nous sont de nature paresseuse. Peu de gens aiment directement passer des tests - se réveiller le matin et dire: "Nous devons commencer la journée avec 15 tests, sinon tout sera mauvais, mais en même temps ma vie ne réussira pas." La paresse naturelle se manifeste plus souvent, surtout quand vous voyez que la méthode n'est pas très intéressante, elle a un code clair et primitif, mais vous devez quand même la couvrir de tests.
Peu écrivent TDD, donc non seulement vous devez écrire un test, mais vous devez également passer du temps sur le code.
Le problème est qu'une quantité infinie de temps n'est pas allouée au développement. Il existe toujours des produits de liste de souhaits à durée limitée. Dans les équipes produit en général, en règle générale, tout était nécessaire hier, car le temps c'est de l'argent. Il semble aux gestionnaires que plus nous écologisons une fonctionnalité, plus notre produit sera cher et meilleur. Et il n'est pas toujours évident que tester la couverture, la qualité du code affecte directement la vitesse ultérieure d'ajout de fonctionnalités, la prise en charge du code, la mise à jour, etc.

Nous blâmons souvent tout sur les gestionnaires et disons qu'ils ne nous donnent pas assez de temps, sinon nous passerions des tests. En fait, ce n'est pas toujours le cas. Et les développeurs robustes pas toujours expérimentés disent d'écrire des tests, et les jeunes collègues ne le veulent pas.

Je travaille dans l'informatique depuis longtemps, mais je suis directement impliqué dans le développement depuis 3-4 ans. Avant cela, j'ai travaillé davantage dans des postes de direction et j'ai vu différents développeurs. Beaucoup de gens ne peuvent pas être appelés inexpérimentés, car ils écrivent du code depuis 10 ans, mais croient en même temps que les tests en tant que tels ne sont pas nécessaires. Supposons que vous n'ayez pas besoin de couvrir le code avec des tests unitaires, car il y a un ingénieur QA qui a besoin d'attraper des bogues. Et ils ne pensent pas qu'un tel ingénieur ne puisse pas couvrir tous les cas avec des tests de bout en bout.

"Si vous n'allez pas à de tels extrêmes, qu'en pensez-vous, qui devrait passer les tests?" Doit-il être le programmeur lui-même, le junior ou, à l'inverse, le développeur le plus cool de l'équipe?

- Si nous parlons de tests unitaires, ce ne devrait certainement pas être de l'AQ. Ces tests doivent être vérifiés, réussis et écrits avant les validations, ils doivent être dirigés vers la requête pull, en aucun cas une autre personne ne doit les écrire plus tard. Par exemple, moi, en tant que développeur non junior paresseux, je mettrais simplement des juniors pour écrire des tests de code primitif. Il y a des choses pour lesquelles il suffit de simplement lire le code à un niveau intermédiaire et d'écrire des assertions, un tel travail est tout à fait adapté aux juniors et sera utile pour leur développement.

Ce sont des tests unitaires qui couvrent simplement le code d'état tel quel. Ces tests ne vérifient pas la validité de la fonction par rapport à l'exigence de tâche dans la tâche, mais s'assurent simplement que le code fait ce qu'il fait et le fait correctement ...

Mais pour vérifier la validité du code pour les exigences métier, pour la logique métier, une personne qui met en œuvre ces exigences doit néanmoins. Il doit comprendre quoi et comment il couvre les tests. Mais il n'est pas clair comment cela peut aider si une personne n'a pas initialement compris le problème, a écrit une méthode qui le résout incorrectement, mais a fait le test correct pour cette méthode incorrecte.

- Nous pouvons dire que le problème est que les gens ont une mauvaise idée de la façon dont le processus de développement logiciel se déroule?

- C'est très subjectif. Vous vous imaginez comme une unité de développeurs qui comprennent que des tests sont nécessaires, pourquoi ils sont nécessaires, et vous pensez que c'est vrai et bon. Mais il y a une couche assez importante de développeurs qui pensent que c'est redondant. Et, dans un sens, les gestionnaires ont probablement raison à leur manière quand ils disent que les tests n'ont pas besoin de couvrir tout le code, il suffit de tester manuellement au stade.
Il n'est pas toujours correct de dire qu'une personne qui n'aime pas les tests est un développeur non qualifié.
Il a sa propre vision, et ce n'est pas à moi d'en juger. Je rencontre encore souvent des développeurs qui écrivent du code depuis 10 ans et je dis que c'est redondant de tout couvrir avec des tests unitaires, assez de tests de fumée et un travail d'AQ suffisent.

À mon tour, je me sens mal à l'aise sur un projet dans lequel il n'y a pas de tests unitaires pour les fonctions. Il est important pour moi qu'il existe au moins des tests garantissant une protection contre le facteur humain, capables d'attraper une virgule placée au hasard ou un nom de clé modifié dans un dict. Mais je n'aime pas y passer du temps, car je veux toujours faire plus de tâches «intelligentes». Par conséquent, je pense à des outils pour automatiser le processus d'écriture des tests.

- Pensez-vous que Python est typé dynamiquement et ne vérifie rien au stade de la compilation? Cela pourrait-il être plus facile dans d'autres langues avec cela?

- Je pense, joue et fort. C'est une histoire éternelle sur les types, mais avec l'avènement des annotations de type, il est devenu plus facile de travailler avec.

Par exemple, en Python, il peut y avoir des chaînes de fonctions imbriquées, où l'attendu à la fin de la liste pour une raison quelconque se transforme en dictionnaire. L'exécution peut ne jamais atteindre la fonction finale, mais dans certains cas, dans certains cas exceptionnels, elle le fera, puis une erreur apparaîtra.

Bien sûr, avec un langage tapé, cela ne peut pas se produire en principe, car une erreur se produira déjà au stade de la compilation. À cet égard, bien sûr, Python fournit des moyens supplémentaires de se tirer une balle dans le pied (dans la tête et ailleurs). Surtout si vous travaillez avec de grands projets avec une logique ramifiée, où les données peuvent être versées dans différentes variantes, dans différentes agrégations.

- Que faire alors de la typification? Pensez-vous que la dactylographie devrait être au maximum ou au minimum? Quel devrait être l'équilibre entre la saisie de code dynamique?

- C'est encore assez subjectif. Beaucoup de gens sont venus sur Python précisément parce qu'il n'y a pas de saisie et parce que tout est tellement flexible et pratique. Vous ne devez pas oublier cela et ne pas éliminer une énorme couche de développeurs, y compris des scientifiques des données et des analystes qui écrivent également du code. Supposons que je, en tant que développeur principal, soit bien sûr plus à l'aise lorsque la frappe est généralement partout. Idéalement, mypy fonctionne également.

Mais dans la plupart des projets auxquels j'ai participé, ce n'est pas possible. Parce que le projet a également des analystes de données qui disent que parce qu'ils écrivent en Python parce qu'ils ne veulent pas jouer avec les types, c'est tellement pratique pour eux.
Un grand nombre de personnes pensent que plus Python en l'absence de types et de dactylographie.
Vous devez atteindre un certain niveau pour comprendre quand et pourquoi cela devient un inconvénient. Dans certains petits scripts Python ou dans de petits projets, je n'utilise pas non plus de types, car je sais que dans un script à 2 fonctions, les types ne sont pas particulièrement nécessaires. Mais c'est quelque chose que, grosso modo, j'ai rapidement fait à genoux pour retirer quelque chose de la base. Et dans les grands projets, j'essaie d'ajouter des types au maximum partout, s'il n'y a pas de résistance des autres développeurs.

- Je suis totalement d'accord avec toi là-dessus. Il ne reste plus qu'à comprendre comment utiliser les types, car il s'agit d'un sujet obscur distinct.

: «, Haskell , : , . Python , , ».

— . , , legacy- smoke-. . ?

- Je ne dirai pas que mon approche est meilleure, c'est juste différent. Couvrir votre code avec des tests de fumée est bon quand vous le pouvez. Mon projet précédent était la douleur par excellence associée aux tests. C'était une plateforme de science des données de 8 microservices et 20 000 lignes de code. Le problème est que la plate-forme reçoit une grande quantité de données et de caractéristiques pour les véhicules, les gares et les villes, divers parkings et types de fournitures, agrège et crée un énorme ensemble d'horaires potentiels pour ces véhicules à travers le monde. L'horaire prend en compte un grand nombre de conditions de la catégorie où vous pouvez faire le plein du véhicule, où faire un arrêt intermédiaire.

Il existe de nombreuses méthodes différentes dans le système qui peuvent être utilisées dans 1-2 situations, dont peut-être même aucun des clients ne se souviendra. L'écriture des tests de fumée se transforme en fait en tests d'écriture pour l'ensemble du système, en tenant compte de toutes les fonctions et de leurs combinaisons.

Le test de fumée doit vérifier que tout fonctionne sur la sortie et ne se casse pas de façon minimale. Un test de fumée très primitif que le système a démarré et fonctionne d'une manière ou d'une autre n'apporte aucun avantage dans notre cas. Disons que nous avons vérifié qu'il existe une connexion à la base de données, que quelque chose démarre, l'interface utilisateur obtient une sorte d'API. Et puis un pas à gauche, un pas à droite - et rien ne fonctionne. Autrement dit, il y a un test de fumée, pour ainsi dire, mais des erreurs volent toujours de la production.

Dans ce système, les tests unitaires ont très bien fonctionné: lorsqu'il est clairement contrôlé que les fonctions n'ont pas changé, elles ne se sont pas cassées après quelques modifications de code. Le code est également différent. Différents projets, différentes tâches nécessitent des approches de test différentes.

L'idée sur laquelle je travaille actuellement ne peut être qualifiée que de génération automatique de tests conditionnellement. Il s'agit plutôt d'un outil développeur. Je veux obtenir un outil qui va écrire des tests pour moi et exécuter tout le code qui peut fonctionner sans moi.

Je vais vous donner un exemple. Il y a une petite fonction qui prend un dictionnaire, de là une valeur et une clé. Cette clé est très importante pour les entreprises, mais du point de vue du code, c'est une opération plutôt primitive: prendre du dictionnaire, même s'il s'agit plusieurs fois d'une clé imbriquée; vérifiez qu'il est là, qu'il n'est pas nul; échangez-le ou renvoyez simplement la valeur. Il s'agit d'un code assez primitif précisément du point de vue de l'AST. Je ne veux pas perdre mon temps avec lui et passer des tests. Je veux que la voiture le fasse pour moi.

Il s'agit précisément d'un métaprogramme avec un code d'entrée et un code de sortie. Disons, au py-module, qui dit: "Ici, j'ai une affirmation, je vous" ai aidé "qu'il y avait des erreurs de levée dans cette condition, des valeurs valides retournées dans une telle situation, quelque chose d'autre s'est produit avec un tel argument" . Autrement dit, il fait le travail où je regarderais moi-même ce qui est alimenté à l'entrée de la fonction et l'écrirais dans le test.

Je veux que le programme génère le minimum qu'il peut exécuter pour moi. Mais cela devrait être un fichier de test, dans lequel, si vous le souhaitez, vous pouvez modifier ou développer quelque chose. Que vous pouvez valider dans Git, test test, etc.

- Dans quelle mesure pouvez-vous compter sur de tels tests générés automatiquement? Qu'est-ce que je veux dire - dans quelle mesure sont-ils liés à une implémentation spécifique, et comment se comporteront-ils dans le cadre des changements normaux de la logique métier ou du refactoring?

- L'idée est de prendre le code sous la forme dans laquelle il se trouve actuellement, et en se basant sur lui pour générer des tests valides pour le moment.

Bien sûr, vous pouvez régénérer les tests à chaque fois, mais ce ne sera pas correct, car il n'y aura pas de suivi de l'état du changement de code. En conséquence, il existe encore des différences de test pour cela, c'est-à-dire que les tests sont générés uniquement pour ce qui n'a pas été couvert par les tests auparavant. Et les tests déjà créés doivent être pris en charge par vous-même.

C'est peut-être un peu de paranoïa, mais jusqu'à présent, je doute qu'avec la génération automatique, il soit possible de garantir qu'en régénérant les tests, vous ne couvrirez pas un code valide avec des tests valides. C'est une chose quand en février 2019 j'ai généré des tests, et si vous changez la logique, alors vous changez les tests vous-même, parce que vous savez quelles modifications ont été apportées. Vous savez pourquoi les tests ont échoué et vous pouvez les corriger en conséquence. Et c'est une tout autre affaire lorsque vous les régénérez à chaque fois. Les tests seront valides, mais uniquement dans cet état modifié du code.
Je veux obtenir un outil pour le développeur, et non un élément pour augmenter la couverture du code.

- Quelles peuvent être les mesures de réussite? Comment comprendre que nous avons bien généré les tests?

Je vais nommer ce à quoi je fais attention, sans quoi il me semble que les tests n'ont pas de sens. Il est impératif que tous les cas de comportement de code décrits par le développeur soient traités dans les tests. Par exemple, s'il y a un if qui ne renvoie rien, mais écrit un journal, dans le test, ce journal devrait fonctionner. Non seulement que les gens écrivent un avertissement et impriment. Par conséquent, s'il y a un traitement d'erreur de relance quelque part, vous devez le résoudre dans un test. Si soudainement lever disparaît, c'est-à-dire qu'il y aura un changement dans la logique du code, alors cela doit également être réglé.

De même, s'il y a des instructions if, alors il doit y avoir un traitement dans l'assertion de chaque condition. Le test sera alors plus ou moins proche de la vérité. Et n'oubliez pas que tout doit être commencé, et pas seulement émettre un «succès» dans PyTest avec des corps de test vides.

- Dites-moi combien il est techniquement difficile de le faire. Cela ressemble à une tâche assez difficile.

Oui, c'est une tâche très difficile, et c'est probablement ce fait et plusieurs autres circonstances qui m'ont amené à en parler dans un rapport sur Moscou Python Conf ++. Je veux soulever ce sujet, y intéresser d'autres personnes et discuter avec elles de solutions.

J'ai le sentiment que personne n'a essayé de le faire, car la tâche est difficile. Sinon, il y aurait des artefacts sur le réseau tels que du code, des descriptions, des articles, ou au moins mentionne qu'il y avait une telle chose, mais elle a été abandonnée.

Pour comprendre à quel point cela est difficile, rappelons le fonctionnement de l'interprète. Il y a des opérations, des instructions dans le code, l'interprète les exécute - bonnes, pas bonnes, a échoué, n'a pas échoué - et produit le résultat. De plus, le développeur ajoute manuellement de nouveaux arguments, redémarre l'interpréteur, s'assure que tout réussit maintenant. Mais lorsque vous essayez de générer des tests pour le code, vous devez d'abord parcourir l'arborescence AST et comprendre les étapes à suivre pour obtenir le résultat.

Une fonction peut avoir de nombreux groupes d'arguments, des stratégies d'arguments et de nombreux résultats pour ces stratégies. En parlant de stratégies, je veux dire que, disons, il y en a if arg_1==1: raise error. Cela signifie qu'il existe certains groupes arg_1=1pour lesquels la fonction renvoie toujours une erreur. Mais avec l'argument, le arg_1>2résultat de la fonction sera différent, et un deuxième groupe sera créé, la deuxième stratégie.

En conséquence, nous devons trouver et mettre en évidence tous ces groupes d'arguments (si, bien sûr, ils le sont), dans lesquels la fonction change de comportement. Et puis suivez la chaîne d'actions: ce qui se passera à l'intérieur de la fonction avec ces arguments pour obtenir le résultat final.

De plus, nous n'oublions pas qu'en plus du fait qu'il y a un argument, il y a aussi des actions à l'intérieur de la fonction, par exemple assigner des variables, appeler d'autres fonctions. Autrement dit, nous obtenons également un graphique des dépendances des méthodes sur les méthodes, lorsque pour vérifier un code, vous devez d'abord obtenir le résultat d'un autre code.

Par conséquent, pour générer des tests, vous devez d'abord obtenir toutes les informations nécessaires de l'arborescence AST, puis générer des arguments, des paramètres et des données pour chaque stratégie. Avec eux, parcourez toute la chaîne des actions, obtenez le résultat, et alors seulement nous aurons un test valide avec différentes assertions. C'est une tâche difficile.

Je ne pense pas qu'un jour il sera possible de couvrir à 100% toutes sortes de cas automatiquement, par exemple pour les énormes toiles des codes sources de Django. C'est laborieux mais intéressant. Jusqu'à présent, je suis simplement curieux de savoir où j'ai la patience et la force pour atteindre.

- Y a-t-il des exemples dans d'autres langues et régions où quelque chose comme ça fonctionne?

- Il n'y en a pas de semblables connus. Je pense que c'est plus facile d'écrire un test que de couper un outil spécial.
Mais j'ai le sentiment que nous automatiserons tôt ou tard ce que nous faisons déjà bien.
Il existe un large bassin de développeurs qui écrivent bien les tests unitaires. Nous avons suffisamment de compétences en développement Python pour vouloir écrire un outil ou une bibliothèque qui le fait pour nous. Et nous écrirons des choses plus complexes, des tests plus complexes.

Il existe une sorte de génération de test en Java, C et .Net. Mais là aussi, tout est plutôt basé sur la propriété ou sur le contrat. En C, il y a une génération de test caractère par symbole, on dirait qu'il ne regarde que le code et sur la base de cela fait quelques tests. Mais c'est un niveau d'abstraction tellement différent dans la langue elle-même que je ne suis pas sûr que ce soit une histoire similaire.

S'il y avait quelque chose de très similaire, alors, bien sûr, on pourrait adopter quelque chose, jeter un œil.

- Pensez-vous que les frameworks ou les techniques d'écriture de code Python simplifient ou compliquent la tâche de génération de tests à partir de l'arbre AST?

- Il est difficile de dire si, dans ce sens, il est très différent d'importer simplement une bibliothèque ou d'utiliser un cadre directement spécifique. Absolument, cela peut grandement compliquer le travail de quelque chose qui change le comportement de l'interprétation d'un processus de code, par exemple, une extension C. Comment y faire face, je ne sais pas encore, mais l'utilisation de mes troisièmes packages préférés jusqu'à présent dans ce problème repose sur la nécessité de résoudre les importations. Tout est simple avec les packages intégrés, mais avec les importations tout devient plus compliqué. Mypy a quelques idées et implémentations, mais je ne touche pas encore à l'histoire de l'importation de packages tiers.

- C'est peut-être une sorte de technique - beaucoup de dynamique, l'utilisation de getattr - quelque chose comme ça? Ou ça marche bien?

"Cela fonctionne parfaitement bien." Parce que getattr ou manipulations avec des métaclasses sont visibles dans AST. Oui, ils doivent être résolus, ce qui ajoute une certaine complexité. Mais cela est suivi de toute façon.

- Nous avons déjà dit que les tests auto-générés sont principalement destinés aux personnes. Dans quelle mesure seront-ils lisibles pour les gens? Il y aura beaucoup de logique à l'intérieur de chaque test, affirme-t-on? À quoi ressemblera la séparation entre le code et les données, comment la voyez-vous?

- Maintenant, j'essaie d'abord d'ajouter toutes sortes de choses banales aux tests. Supposons, s'il s'agit d'une sorte d'erreur de relance, alors ce n'est pas seulement avec une relance, mais au moins laissez un commentaire, quel genre d'erreur, pourquoi cela apparaît, afin que la personne, après avoir lu le test, comprenne ce qui s'est réellement passé, quel argument mène à quelle erreur .

Jusqu'à présent, les assertions sont combinées dans une seule méthode. Autrement dit, s'il y a une fonction et qu'il y a 5 états que nous voulons vérifier, alors jusqu'à ce que 5 assertions entrent dans la fonction.

Il y avait une idée pour introduire des conventions de nom, par exemple: mettre les erreurs à la fin de l'erreur, les journaux de test ont aussi quelque chose de propre. Mais je l'ai reporté pour l'instant, car la question de savoir comment créer le type final de tests dans le code, directement un bloc de texte avec des tests, est l'opération la plus économique. Si l'idée apparaît soudainement que tout doit être reformaté, alors ce sera facile à faire - il y a des asserts prêts à l'emploi, il vous suffit de choisir un look différent pour les tests.

- Soutenez-vous unittest ou pytest?

- Pytest. Et juste parce que je ne veux pas dépenser beaucoup d'énergie sur la sortie maintenant. Pytest est bon car il existe de nombreux plugins, décorateurs, divers modificateurs pour celui-ci qui sont faciles à utiliser.

La beauté peut être importante à la fois pour l'utilisateur final et pour le développeur. Mais cela n'affecte pas du tout le développement de l'idée. Si vous devez prendre en charge unittest, cela peut être facilement ajouté.

- Dans quelle mesure cette approche est-elle liée aux tests basés sur les propriétés?

- Maintenant, pour générer des arguments, seul le type moki est utilisé: vous avez besoin de int, donnez int aléatoire. Mais de telles stratégies seront alors faciles à réécrire, par exemple, commencer à utiliser l'hypothèse. Bien que je n'y consacre pas beaucoup de temps et d'efforts, car je comprends que je peux ensuite utiliser des générateurs tiers pour leur valeur. Maintenant, il me semble que ce n'est pas aussi important que de travailler avec AST.

- Prévoyez-vous de soutenir la programmation des contrats ou de vous séparer d'une manière particulière? Parce que cela aide beaucoup à travailler avec les tests unitaires, les tests basés sur les propriétés et les tests, en principe, pour comprendre la logique métier.

- Si par programmation sous contrat, nous entendons des contrats dans le code, je m'écarte le plus possible de cela. Parce que lorsque vous pouvez utiliser la programmation de contrats, vous pouvez essentiellement coder les contrats avec des contrats et générer des tests unitaires sur leur base. Et puis mon outil n'est pas si nécessaire.

Maintenant, j'essaie de ne penser à rien qui modifie le code. Parce que, par exemple, dans les projets de sous-traitance, dans lesquels je faisais face au problème du manque de tests - et c'étaient presque tous des projets, malheureusement, dans l'entreprise actuelle - il était presque impossible de toucher au code. Autrement dit, il était impossible d'apporter des modifications tant que vous ne pouviez pas garantir que ce décorateur ou ce contrat ne changerait pas la totalité du composant fonctionnel du code.
S'il est possible de modifier le code, les tests de contrat sont bons.
Mais pour l'instant, je pars du fait qu'il n'y a pas une telle possibilité. Et donc, en effet, sur la base de contrats, vous pouvez générer des tests unitaires et, en fait, implémenter la duplication des fonctionnalités.

- Parlez-nous du prochain point important: comment tester les tests reçus et dans quelle mesure pouvez-vous garantir que ces tests testent vraiment quelque chose?

- Le test mutationnel n'a pas été annulé, et dans une image idéale du monde, il doit certainement être utilisé dans cette histoire. L'idée dans son ensemble est la même que si le test avait été écrit manuellement par le développeur. Autrement dit, tout ce qui est disponible pour tester les tests peut être entièrement appliqué.

- Discutons maintenant un peu de la conférence Moscou Python Conf ++. Nous joueronsl'un des développeurs d'hypothèses que nous avons mentionné à plusieurs reprises. Que seriez-vous intéressé à lui demander?

- Je serais intéressé de demander à Zach où ils veulent développer le projet avec les responsables: quoi ajouter, quelle voie développer. Je sais avec certitude que Zach a maintenant un PR pour la génération de tests. Ils le font régulièrement. Plus précisément, les décorateurs complètent les tests unitaires existants.

Je voudrais discuter des idées de la génération automatique de tests en termes de la façon dont l'hypothèse la regarde, comment les contributeurs la regardent. Certes, les gens qui sont engagés dans des tests à un tel niveau ont des idées ou peut-être que quelqu'un a déjà essayé quelque chose.

«Nous comptons sur cela lorsque nous préparerons le programme de la conférence: pour que les rapports définissent des sujets de discussion, au cours desquels tout le monde trouverait de nouvelles idées et de nouvelles orientations de développement. À quels rapports irez-vous?

- Je voudrais me fâcher et aller à tous les rapports à 12 heures. À ce moment, il y aura Zac Hatfield-Dodds, Andrey Svetlov avec un rapport sur la programmation asynchrone et Vladimir Protasov avec l' automatisation du refactoring . Je vais passer à quelques-uns des deux derniers, puis je vais courir vers Zack à la fin du rapport ( Ndlr: mettre le piratage au service de la vie -. Presque entendre un nouveau thème, et à l'orateur, avec qui vous voulez parler, arrivez à la fin du rapport et des questions ) .

Il doit y avoir très intéressantrapport sur la validation des données , ça m'intéresse directement. Et il y a deux autres rapports auxquels j'irais également, mais ils iront tous en parallèle avec le mien: il s'agit d'un rapport de Vitaly Bragilevsky sur la dactylographie et Christian Heimes sur le profilage . Malheureusement, je ne peux en aucun cas y accéder.

- Parlez-moi un peu plus du sujet de votre rapport, pourquoi faites-vous, que faites-vous, pourquoi parlez-vous et qu'attendez-vous du discours?

- Je veux plus d'outils pour automatiser les processus de développement et plus de collaborations liées à cela. Il y a une telle activité, mais dans le contexte d'écrire constamment le même code, il me semble qu'il devrait y en avoir plus.

Comme je l'ai dit, il n'y a pas d'expérience ouverte dans les tests de génération automatique en Python. Il est difficile de savoir si quelqu'un faisait cela, si oui, pourquoi n'a pas décollé, n'est pas parti. Je ne sais pas dans quelle mesure la génération de tests basés sur AST sera pertinente pour la communauté, jusqu'où elle peut aller. Maintenant, je fais cela parce que je m'intéresse au processus lui-même, je suis intéressé à fouiller dans les arbres AST, à en savoir plus sur le fonctionnement du code Python et à rencontrer de nombreuses nuances différentes qui ne sont pas évidentes lorsque vous travaillez avec le code de niveau supérieur. Travailler avec des arbres AST apporte une tonne de découvertes soudaines.

Je veux que les gens aient des idées après le rapport, par exemple, comment automatiser quelque chose qu'ils utilisent dans leur travail. Pour que certains d'entre eux arrêtent d'écrire des morceaux de code qu'ils écrivent déjà tous les jours et commencent à générer ou à réduire le temps nécessaire pour les écrire. J'espère que quelqu'un sortira avec une nouvelle compréhension de la façon de résoudre ce problème.

- Où prenez-vous le temps de parler lors de conférences, d'écrire vos propres bibliothèques? Cette question revient en fait constamment, beaucoup de gens se plaignent de ne pas avoir le temps pour rien.

- Tout d'abord, à propos de l'heure. Je ne suis pas un employé très pratique pour de nombreuses entreprises dans le sens où je ne fais pas de choses qui me semblent inefficaces. J'essaie de faire des choses qui m'intéressent vraiment ou que je peux faire de manière efficace et correcte. Si, par exemple, un gestionnaire veut que je corrige une sorte de bogue en ce moment, qui n'est en fait pas un bogue, mais une nouvelle liste de souhaits de client, je ne m'asseoirai pas pour tout réparer, car je sais que le client reviendra et dira pourquoi vous l'a fait.
J'essaie de ne pas faire de travail inutile au travail, de ne pas faire ce qui entraînera une perte de temps par la suite.
Supposons que s'ils me demandent de me déployer vendredi, je dis: «Les gars, je vous aime tous beaucoup, vous êtes tous de bons amis, mais si vous avez besoin de déployer quelque chose maintenant, veuillez vous déployer et je rentrerai chez moi. Je peux le déployer lundi, nous pouvons expliquer pourquoi une telle situation s'est produite, que vous souhaitez déployer maintenant vendredi. » Cela peut être douloureux pour la première fois de le dire au client ou aux responsables, mais plus tard, les gens s'y habituent, étudient et ne vous demandent pas de faire quelque chose de très urgent le vendredi soir. Ils comprennent que, premièrement, personne n'est décédé vendredi dernier, lorsque personne n'a été inondé, et même personne n'a perdu d'argent. J'essaie de ne pas faire quelque chose qui me nuira.

La même histoire à propos des bogues - s'il y a de nombreux bogues qui doivent être corrigés en permanence, la question est: pourquoi ces bogues apparaissent-ils? Nous ne devons pas les réparer, mais réfléchir à la raison pour laquelle ils sont si nombreux, d'où ils viennent et se battre principalement avec le problème racine. Ce sont également des problèmes toujours douloureux, lorsqu'un gestionnaire ou un client dit qu'il est urgent de réparer une fonctionnalité en production. Mais vous devez être en mesure de dire que si je touche ce code maintenant, alors vous avez peut-être autre chose que cette fonctionnalité, vous n'aurez pas de production, car le code n'est pas couvert par des tests, vous ne pouvez pas en ajouter un autre si, car nous ne nous souvenons pas de ce que font les six autres.

Parfois, vous devez vous dépasser et commencer à parler. Ce n'est pas toujours possible, il faut atteindre un certain niveau de conscience que pour combien de temps vous passez sur ce genre de travail, vous êtes responsable.

Par conséquent, j'ai probablement le temps. Parce que j'essaie d'optimiser mon temps de travail, de lui faire prendre un certain nombre d'heures pour terminer une tâche. Dans le même temps, je comprends que dans une bonne structure, il devrait y avoir 1-2 heures pour la dette technique et quelques améliorations.

Je ne dirai pas que je travaille 8 heures sans me lever. Je regarderais un développeur qui s'assied et écrit du code pendant 8 heures de temps de travail. Si vous prenez ma journée de travail habituelle, alors 2 heures sont juste toutes sortes de tests, révision de code, dette technique, "buzz" sur le code. Heures 3 est une solution aux problèmes actuels, une heure pour communiquer avec les managers. Et les 2 heures restantes sont réparties pour une raison quelconque, pour des discussions avec des équipes et des trucs indépendants.

Il y a des choses que vous êtes intéressé à faire - vous le faites, et quand vous n'avez pas de force, elles vous donnent de la force. J'ai beaucoup d'activités différentes - c'est ce qu'on appelle probablement la procrastination utile - quand je fais ce qui m'intéresse en ce moment, et non ce que je dois faire. Si vous apprenez à varier entre ce qui est intéressant et ce qui est encore nécessaire, ce sera le plus réussi. Vous ne perdez tout simplement pas votre temps à faire ce que vous ne voulez pas.

Il n'y a pas de secret, il vous suffit de faire ce que vous aimez, mais en même temps sans nuire à votre entourage et au projet.

Pour plus de détails sur l'implémentation de la génération de tests à partir du code Python, ainsi que sur la résolution de nombreuses autres tâches d'un développeur Python, consultez Moscou Python Conf ++ , que nous avons reporté au 15 septembre.

More articles:


All Articles