Que signifie un poste d'architecte QA? Et que signifie la position totalement incompréhensible de meme wrangler? À partir de quand les testeurs doivent-ils être connectés lorsqu'ils travaillent sur l'architecture? Comment changer les processus dans l'organisation pour que les personnes lors d'une réunion avec la première complexité ne reviennent pas à l'ancienne?
Neil Ford présente trois options sur son site Web: ThoughtWorker (un employé de ThoughtWorks, que beaucoup de gens connaissent grâce à Martin Fowler), Software Architect et Meme Wrangler. Bientôt, lors de notre conférence à Heisenbug, il parlera de créer des «architectures évolutives», qui peuvent être modifiées en fonction des circonstances externes changeantes. Entre-temps,
Mikhail xomyakus Druzhinin (membre du comité du programme Heisenbug) a demandé à Neal: comment son discours se mêle aux tests, et bien plus encore.
- Pouvez-vous commencer par parler de vous et de votre carrière?- Bien sûr. Je travaille chez ThoughtWorks depuis près de 14 ans. Avant cela, il était CTO dans une petite entreprise de conseil et de formation d'environ 25 personnes, et là, il a commencé à s'essayer à des technologies comme Java. Les trois premiers livres que j'ai écrits avant de rejoindre ThoughtWorks. Le tout premier concernait Delphi, à l'époque assez populaire en Russie et en Europe.
Quand j'étais CTO, j'étais fatigué d'être un alpha geek. Quand vous en savez plus que les gens autour de vous, vous ne vous développez pas vraiment. J'ai commencé à prendre la parole lors de diverses conférences et j'ai vraiment apprécié d'être parmi les autres conférenciers, car ils étaient des gens très intelligents et intéressés. Et j'ai commencé à chercher inconsciemment une entreprise dans laquelle des personnes vraiment intelligentes et intéressées travailleraient principalement. Et littéralement tombé sur ThoughtWorks, comme beaucoup, sur le site Web de Martin Fowler. Sur des choses comme CruiseControl et la bibliothèque de tests NUnit, j'ai remarqué qu'ils apportent une énorme contribution à l'open source et font beaucoup de choses très intéressantes. J'ai donc commencé par inadvertance le processus d'entretien avec ThoughtWorks, à la fin duquel j'ai reçu une offre d'emploi. Ce fut une bonne étape pour moi, car ce sont des développeurs très intelligents et très enthousiastes.
Je pourrais être consultant indépendant, mais dans ce rôle, je n'aime pas deux choses. Tout d'abord, vous devez faire toutes les affaires vous-même: facturer, chasser les gens pour de l'argent, réguler les flux de trésorerie et tout ça. J'en suis capable, mais ça ne m'intéresse pas. Ma passion est le logiciel et le développement.
Et le second: si vous êtes consultant indépendant, vous réussissez rarement à travailler en collaboration avec quelqu'un, en équipe. Vous êtes presque toujours seul et j'aime beaucoup le développement d'équipe. J'ai même écrit plusieurs livres avec d'autres auteurs, dont mon dernier livre, Evolutionary Architecture. Il me semble qu'en travaillant ensemble, le résultat est supérieur à la somme des composants individuels. Lorsque vous collaborez à un travail créatif, que ce soit un projet d'écriture ou un programme, vous pouvez obtenir plus de points de vue et une idée plus générale, donc le résultat sera meilleur.
Donc, en avril, cela fera déjà 14 ans que je travaillais chez ThoughtWorks. Je le sais si bien, car l'un des avantages intéressants de travailler chez ThoughtWorks est que si vous travaillez dans l'entreprise depuis 10 ans, vous bénéficiez de 12 semaines de vacances payées lorsque vous pouvez faire ce que vous voulez. Et après cela, tous les 5 ans, vous obtenez un congé créatif payé de 6 semaines, il me reste donc un an avant les 6 premières semaines. J'ai vraiment aimé celle de 12 semaines et j'attends avec impatience la prochaine. Donc, vous vous souvenez toujours de la décennie que vous avez passée ici: ils se mesurent avec des vacances si agréables.
- C'est une durée de vacances très tangible, cool.«J'ai été embauché par ThoughtWorks en tant qu'architecte et j'ai joué ce rôle pendant un certain temps jusqu'à ce que j'arrive au niveau de directeur.» La plupart de mon travail concerne maintenant le domaine de l'architecture logicielle, j'ai passé beaucoup de temps à l'intersection des pratiques d'architecture et d'ingénierie (par exemple, la livraison continue) - je soupçonne qu'ici mes intérêts se croisent avec ceux du public Heisenbug.
En particulier, ce dont j'ai beaucoup parlé récemment est le sujet de mon dernier livre, la construction d'une architecture évolutive. Si vous pouvez éviter les bogues, les personnes qui testent l'application seront plus faciles. L'architecture évolutive comprend des techniques de sécurité pour les fonctionnalités architecturales critiques, telles que la déployabilité, la testabilité, l'évolutivité, les performances, etc.
"Que signifie Meme Wrangler?"- Selon les règles de ThoughtWorks, vous pouvez choisir n'importe quel titre de poste, à l'exception de quelques titres réservés comme "PDG". Si vous arrivez à une position intéressante pour vous-même, alors s'il vous plaît. Et lorsque le jeu de cartes de visite se termine, vous pouvez en créer une nouvelle.
Mon premier emploi était architecte d'application. Cette position reflète l'essence du travail, mais très souvent dans les grandes entreprises, elle implique que vous n'apportez plus beaucoup d'avantages, que vous passez plus de temps à dessiner des images qu'à créer quoi que ce soit.
Et l'un des avantages du développement personnalisé est que vous pouvez vous familiariser avec un grand nombre de projets différents. Les architectes logiciels, je pense, sont par nature des «modèles de correspondance»: nous essayons d'appliquer des modèles à tout ce que nous voyons, même aux choses du monde réel. Donc, si vous êtes un architecte dans le développement personnalisé, vous devez voir beaucoup de projets différents, vous voyez des motifs répétitifs, vous voyez lesquels fonctionnent. Et j'ai réalisé qu'en fait, mon travail consiste à collecter des idées intéressantes de l'écosystème logiciel. De là est venu le Meme Wrangler.
Mème est un terme inventé par l'écrivain Richard Dawkins; c'est une unité répandue pour désigner des idées. Tout le monde connaît les mèmes sur Internet - c'est quelque chose d'esprit qui attrape et se propage comme un virus. Et le mot «wrangle» a deux sens utiles, le premier est d'agir en tant que juge dans un différend, et le second est de conduire dans un troupeau. Et j'ai choisi le poste de Meme Wrangler, car il reflète plus précisément ce que je fais maintenant. De plus, maintenant que je publie un autre livre, j'écris sur Twitter que je "lasso un autre mème" et le mets dans ce livre.
- Pouvez-vous expliquer ce qu'un architecte logiciel doit faire, que faites-vous en tant qu'architecte logiciel?"Bien sûr, je peux essayer, mais personne ne réussit vraiment à donner à cette définition." Martin Fowler - un homme très cool pour donner des définitions à tout dans le domaine de la programmation - a publiquement refusé de définir le terme "architecte logiciel" dans son texte
"Qui a besoin d'un architecte?" .
Mais si vous regardez le rôle d'un architecte logiciel, l'une des choses est qu'il est responsable de tout ce qui est alors difficile à changer. Tout cela est lié à la structure de votre système logiciel: quels modèles fondamentaux utiliserez-vous, quel langage ou quels cadres. Parce que toutes ces décisions ont des conséquences d'une portée considérable.
L'une des choses qui intéressent vraiment les architectes est ce que nous appelons les «paramètres architecturaux», qui sont également appelés «exigences non fonctionnelles», mais nous n'aimons pas ce nom. Ce sont des choses telles que les performances, l'évolutivité, l'élasticité, la déployabilité - tout cela est de la responsabilité de l'architecte. Un architecte peut créer une structure qui tiendra compte des exigences du programme lui-même et de tous ces paramètres architecturaux qui doivent y être fournis.
Supposons que vous soyez architecte et que vous ayez besoin de créer une structure de système logiciel pour inscrire les étudiants dans une université. Supposons que nous ayons un millier d'étudiants et 10 cours auxquels ils doivent s'inscrire. Et maintenant, selon notre connaissance de l'organisation des universités, que pensez-vous qu'il se passera: les étudiants seront répartis uniformément tout au long du semestre afin que nous obtenions le même nombre d'étudiants dans chaque cours, ou ils dureront tous jusqu'à la dernière heure, et alors précipitez-vous pour enregistrer tout d'un coup?
Et c'est l'élasticité, c'est un paramètre architectural que vous devez vous assurer lorsque vous créez un tel système. Très probablement, cela n'est indiqué nulle part, mais vous le savez, simplement en fonction du sujet. C'est ce qui rend l'architecture des systèmes logiciels si complexe: vous devez comprendre le domaine, ainsi que les capacités techniques et les limites de votre entreprise. Vous pouvez être limité, par exemple, par le fait que cette base de données relationnelle est déjà sélectionnée pour le standard de notre entreprise, et nous devons augmenter la productivité. Comment pouvons-nous atteindre ces résultats?
C'est le travail de l'architecte logiciel - faire face à toutes ces décisions importantes liées au fait qu'il a des conséquences à très long terme et qu'il est très difficile de le changer plus tard. De nombreux éléments de la structure, tels que l'interface utilisateur, sont assez faciles à développer, car vous ne changez qu'une couche de l'application. Et l'architecture est plus sur la façon dont toutes ces couches sont juxtaposées, et il est généralement beaucoup plus difficile de changer.
Ils disent que les microservices sont maintenant très populaires, et une telle architecture a été créée spécifiquement dans l'attente de changements constants. Il est donc beaucoup plus facile d'apporter des modifications majeures à la structure du microservice, mais elles ont été créées dès le début. Et c'est un sujet de recherche très intéressant - comment concevoir une architecture facile à changer, car pour l'industrie c'est exactement ce qui a été le plus difficile depuis très longtemps.
- Sur la question de l'architecture et des posts: je vois de plus en plus «QA Architect» sur les cartes de visite et LinkedIn.- C'est l'un des problèmes du terme «architecte»: chaque entreprise doit inventer son propre nom pour cela. J'ai rencontré à la fois des «architectes QA» et des «architectes de données», des «architectes de systèmes», des «architectes de solutions», des «architectes techniques» - j'ai rencontré des architectes de tous les horizons. Et c'est un problème, car personne ne peut donner une définition claire et donner ce que vous voulez.
Ce que «l'architecte AQ» peut signifier pour une entreprise particulière, je ne sais même pas avec certitude. Une telle personne développe-t-elle une structure d'AQ? Pour moi, c'est plus proche de la fonction d'un architecte en tant qu'expert technique, car souvent un architecte est aussi un chef de projet technique. Mais l'architecte s'occupe également de présentation et de documentation. Donc, si je suis architecte et que j'ai eu une idée géniale pour une nouvelle architecture, mais je ne peux pas faire une présentation et convaincre les gens avec de l'argent que nous devrions le faire, alors nous n'aurons pas la possibilité de réaliser mon idée cool. Cela signifie des compétences en communication.
Ces compétences s'appliquent à l'AQ, et quiconque fait cela peut aussi être appelé un «architecte». Vous voyez, c'est un poste tellement vague. De nombreuses organisations arrivent simplement au point d'appeler l'ingénieur principal architecte, car cela semble cool et elles ne peuvent pas comprendre comment l'appeler autrement. Comme, vous savez, développeur senior-senior-senior - d'accord, architecte. Et j'ai rencontré des entreprises où il y a un type d'architectes, et j'ai rencontré des entreprises où il y a des dizaines de variétés d'architectes. En fait, ce sont des articles fictifs. Mon «meme wrangler» est meilleur en ce sens car il est évidemment composé.
- Parlons dans le sens de votre discours à Heisenbug. Vous prendrez la parole lors d'une conférence de test - qu'en est-il de la qualité des logiciels pour vous?- Je considère personnellement la qualité des composants architecturaux du système. Je sais que le monde de l'assurance qualité voit plus le logiciel comme une boîte noire, c'est-à-dire qu'il regarde du point de vue de l'utilisateur s'il y a des erreurs et des échecs, s'il fonctionne correctement. Bien sûr, cela m'intéresse également, mais je suis plus préoccupé par les causes profondes des erreurs: pourquoi l'application n'est-elle pas fiable, pourquoi se bloque-t-elle périodiquement? Ici, je dois être la dernière ligne de défense, comprendre pourquoi cela se produit. Et il y a des choses comme la performance et la réactivité. On en parle beaucoup dans le monde de l'interface utilisateur maintenant, ils ont des indicateurs clairs: si votre site mobile charge du contenu visible pendant plus de 3 secondes, les utilisateurs partiront et iront ailleurs.
Une grande attention est accordée aux performances Web: quel est le délai avant le chargement du premier contenu visible, quel est le temps total de chargement de la page. Et ce sont tous des paramètres de qualité, qui sont certainement visibles du point de vue d'un observateur extérieur, et c'est moi qui devrait déterminer comment nous allons construire un système dans lequel de tels indicateurs seront atteints. Et cela peut entraîner des changements dans le frontend concernant les technologies Web qui seront utilisées, mais cela peut également entraîner des changements dans le backend. Peut-être, pour transmettre des informations non pas en temps réel, mais dans un paquet, et au milieu faire un mécanisme de mise en cache? Pour moi, la qualité ressemble à ceci: déterminer quelles sont les exigences, puis proposer une implémentation technique qui les incarnera.
- Pouvez-vous donner l'étude de cas la plus intéressante de la pratique liée à la qualité?- C'est difficile à dire, tous les projets sont différents, donc le meilleur est toujours le dernier sur lequel j'ai travaillé!
Eh bien, d'une manière ou d'une autre, j'ai travaillé sur un système dont les exigences ressemblaient en partie à Lotus Notes. Rappelez-vous un programme aussi ancien? C'était un programme terrible, mais elle a fait une chose très, très bien. Ce programme se synchronise très bien: vous pouvez télécharger votre courrier et vos notes, puis prendre un taxi, aller quelque part, répondre à toutes les lettres à ce moment-là, et la prochaine fois que vous vous connecterez au réseau, tout se déchargera automatiquement, se synchronisera et fonctionnera comme par magie façon.
Et nous avions un client avec un système de vente qui voulait le même principe de fonctionnement. Parce que les vendeurs sont toujours en mouvement, et il était nécessaire qu'ils puissent passer des commandes sans connexion Internet, puis tout se synchroniserait et deviendrait comme il se doit.
Et nous avons réalisé à quel point cela est difficile, en raison d'un tas de cas limites et de scénarios qui doivent être fournis. Tout d'abord, nous avons développé un système qui fonctionnait sans aucune connexion Internet, puis nous avons commencé la synchronisation. Et il y avait un tas de maux de tête - par exemple, les performances d'une application en ligne par rapport à hors ligne, un retard notable est apparu lors de la connexion, car la synchronisation était en cours à ce moment-là. Donc, dans ce cas, l'assurance qualité a été un gros éclat pour nous, car ils ont trouvé des cas limites qui ont détruit l'ensemble du système.
Et de l'extérieur, cela semble être une tâche simple. Des applications comme Dropbox et Google Drive ont résolu ce problème afin qu'il devienne invisible. Et cela semble facile. Mais lorsque nous avons essayé de le résoudre, il s'est avéré qu'il y avait un million de cas limites. Donc, sans contrôle qualité fiable, il est difficile de les trouver tous, chacun devant être retourné pour s'aligner sur la structure de l'application afin de garantir que la structure globale fonctionne toujours.
En fait, pendant que nous développions ce système, en apportant des changements fondamentaux à la structure, nous avons réalisé que les cas limites seraient fréquents et inacceptables. Et cela illustre bien combien il est important d'avoir une boucle de rétroaction très bien établie entre la conception de l'architecture et des pièces comme l'AQ. Trop d'entreprises remettent cela au dernier moment, mais si vous le faites, au final, beaucoup de choses seront mal faites, et vous devrez revenir en arrière et consacrer beaucoup de temps à le refaire. Si vous établissez un contact étroit entre le développement de l'architecture et les tests, vous pouvez trouver ces cas limites et changer la structure beaucoup plus rapidement. Heureusement, nous avons été extrêmement flexibles dans ce projet - puisqu'il s'agissait d'un projet ThoughtWorks, nous avons eu un cycle très rapide. Et nous avions une équipe de testeurs très solide.
- Beaucoup de personnes dans les tests demandent comment elles peuvent affecter l'architecture. Pour eux, l'architecture est quelque chose dans une tour d'ivoire. Que peut-on faire avec ça?- Il me semble qu'il serait utile que les testeurs viennent voir les architectes et leur expliquent qu'ils font mal leur travail, et qu'il vaut mieux que les testeurs sachent comment l'exécuter. Les gens aiment ça quand on leur dit ça! En fait, non, ils n'aiment pas ça, rien de bon n'en sortira.
J'ai un mantra préféré pour de tels cas: "il vaut mieux montrer que discuter." Vous devez montrer à quel point votre monde est différent de leur monde. Si vous êtes un ingénieur de test, vous devez apporter un cas d'utilisation qui démontrera clairement le défaut de conception. Si vous montrez ce scénario à un architecte, il ne s'agit pas simplement d'une plainte concernant quelque chose, mais d'une démonstration concrète: «Maintenant, votre projet ne fonctionnera pas dans un tel scénario, il doit donc être modifié.» S'ils ne sont pas d'accord avec cela, cela signifie qu'ils ont simplement perdu le contact avec la réalité. Et les architectes doivent être sensibles aux choses qui se produisent dans le monde réel.
Il y a beaucoup, comme je l'appelle, de la
poésie de l'ancien secrétaire à la Défense Donald Rumsfeld, qui parle du «célèbre célèbre» et de «l'inconnu inconnu». Ainsi, dans chaque projet logiciel, il y a des «inconnues inconnues», donc le développement de toute architecture doit être itératif. Parce que peu importe à quel point vous pensez, les choses que vous ne pouviez pas prévoir de quelque manière que ce soit n'apparaîtront tout à coup que lorsque vous essayez de construire cette structure.
, , Docker. , , . , , .
. , , , — , .
, , ?
— .— ! ! , , , . (QA). , , , .
, , QA , . , , , . -, . -, .
, — . , QA , . , . , .
— , ?— . , , , - QA-, -, , data science, . , .
, . , , . - : « ». - : «, , , , , ». , , , . .
, ThoughtWorks, « » . , , deployment pipeline. , , , , , . , QA, , , , , , , . , -.
— . , «-», «QA» - ?— . ThoughtWorks , , , . , , . , , -, . , . , .
— QA ?— , , . — . , .
- , . , , , . - , . , , . , , , . , .
, . , — , 1975 , .
— 1975-?— « -» , . , . ( ), « ». , . , , - , . , . , .
, , , — , QA . , . , , . , , .
— .— , , Apple , . Wi-Fi , , . . UI, . QA, .
— , . , ThoughtWorks — ?— , , « , ». , , , .
, . ? UI, , , — , . , , , : «! !» , , 50 Jira, .
. , : , , , : , , , . , .
. , . , , , .
, — « , ». , . , , . , , . , , — , . , .
. HR, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
- Oui.
— .
15- Jira, , , . , , , , . , , - Slack, , , , Slack.
, , . , 30 . ? , . , , , . -. , . , .
: , , , , . - QA: , , email Slack, , . , , , .
— . . , -, , . .— , . , , . , , : , .
Slack! Slack — , . , , . « » , Slack. , « ». , , , , . - Slack, , , - .
, , .
-. , . — , , , . , . , - ?
— .— ! , . , . Slack, , . , Slack, , , , , , , .
— -. - , , .
. , IT-, , , , . . , , - - ?— . . - , , , -, . - , .
: - , . «, ». . , .
, . , , . ThoughtWorks, , , , . . , ThoughtWorks , .
, , , , , . « , ». , , - , — , . , - , . «»: , , , . . , , , .
, . -, . : «, , agile-, 1,3 , «», 30% ». , . : « , , , , ».
— , ?— : ? ? , . , - — . ? - — , , .
, , . , , , . , -, QA , , , , . , . , , , — , , , .
— , , , - ?— . , : , , -, , , , .
— , , , . , : « », , , .
— «architecture is abstract until operationalized», . , , ?- Bien sûr. , , meme wrangler.
, DevOps-. , , . DevOps , , — , , .
, — , « » . . , . , : , , . , , ?
— .— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .
, , — , , .
— . !Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .