Der Scheideweg von Test und Architektur: Ein Interview mit Neil Ford

Was bedeutet eine Position als QS-Architekt? Und was bedeutet die völlig unverständliche Position des Meme Wrangler? Ab wann sollten Tester angeschlossen werden, wenn an der Architektur gearbeitet wird? Wie können Prozesse in der Organisation geändert werden, damit Personen bei einem Meeting mit der ersten Komplexität nicht zum alten zurückkehren?

Neil Ford präsentiert auf seiner Website drei Optionen: „ThoughtWorker“ (ein Mitarbeiter von ThoughtWorks, den viele Menschen aufgrund von Martin Fowler kennen), „Software Architect“ und „Meme Wrangler“. In Kürze wird er auf unserer Heisenbug-Konferenz über die Schaffung von „evolutionären Architekturen“ sprechen, die mit sich ändernden äußeren Umständen geändert werden können. In der Zwischenzeit fragte Mikhail Xomyakus Druzhinin (ein Mitglied des Heisenbug-Programmkomitees) Neal: Wie seine Rede sich mit Tests überschneidet und vieles mehr.

- Können Sie zunächst etwas über sich und Ihre Karriere erzählen?

- Natürlich. Ich bin seit fast 14 Jahren bei ThoughtWorks. Zuvor war er CTO bei einer kleinen Beratungs- und Schulungsfirma mit etwa 25 Mitarbeitern. Dort versuchte er sich an Technologien wie Java. Die ersten drei Bücher, die ich geschrieben habe, bevor ich zu ThoughtWorks kam. Das allererste handelte von Delphi, das zu dieser Zeit in Russland und in Europa sehr beliebt war.

Als ich CTO war, hatte ich es satt, ein Alpha-Geek zu sein. Wenn Sie mehr wissen als die Menschen um Sie herum, entwickeln Sie sich nicht wirklich. Ich begann auf verschiedenen Konferenzen zu sprechen, und ich habe es wirklich genossen, unter den anderen Rednern zu sein, weil sie sehr kluge und interessierte Leute waren. Und ich begann unbewusst nach einem Unternehmen zu suchen, in dem wirklich kluge und interessierte Leute hauptsächlich arbeiten würden. Und stolperte buchstäblich über ThoughtWorks, wie viele auf Martin Fowlers Website. Bei Dingen wie CruiseControl und der NUnit-Testbibliothek habe ich festgestellt, dass sie einen großen Beitrag zu Open Source leisten und viele sehr interessante Dinge tun. Und so begann ich versehentlich den Interviewprozess mit ThoughtWorks, an dessen Ende ich ein Stellenangebot erhielt. Das war ein guter Schritt für mich, denn sie sind sehr kluge und sehr begeisterte Entwickler.

Ich könnte ein unabhängiger Berater sein, aber in dieser Rolle mag ich zwei Dinge nicht. Zunächst müssen Sie das ganze Geschäft selbst erledigen: Abrechnung, Geldjagd, Regulierung des Cashflows und so weiter. Ich bin dazu in der Lage, aber es interessiert mich nicht. Meine Leidenschaft ist Software und Entwicklung.

Und zweitens: Wenn Sie ein unabhängiger Berater sind, schaffen Sie es selten, mit jemandem als Team zusammenzuarbeiten. Sie sind fast immer alleine und ich mag die Teamentwicklung sehr. Ich habe sogar mehrere Bücher zusammen mit anderen Autoren geschrieben, darunter mein neuestes Buch, Evolutionary Architecture. Es scheint mir, dass bei der Zusammenarbeit das Ergebnis größer ist als die Summe der einzelnen Komponenten. Wenn Sie in der kreativen Arbeit zusammenarbeiten, sei es ein Schreibprojekt oder ein Programm, erhalten Sie mehr Sichtweisen und eine allgemeinere Vorstellung, daher ist das Ergebnis besser.

Im April ist es also schon 14 Jahre her, dass ich bei ThoughtWorks war. Ich weiß das so gut, denn einer der interessanten Vorteile der Arbeit bei ThoughtWorks ist, dass Sie, wenn Sie 10 Jahre im Unternehmen sind, eine bezahlte Urlaubszeit von 12 Wochen erhalten, in der Sie tun können, was Sie wollen. Und danach erhalten Sie alle 5 Jahre einen 6-wöchigen bezahlten Kreativurlaub, sodass ich bis zur ersten 6-wöchigen Pause noch ein Jahr Zeit habe. Die 12-wöchige hat mir sehr gut gefallen und ich freue mich auf die nächste. Sie erinnern sich also immer daran, was für ein Jahrzehnt Sie hier waren: Sie werden mit so angenehmen Ferien gemessen.

- Dies ist eine sehr greifbare Länge des Urlaubs, cool.

"Ich wurde von ThoughtWorks als Architekt eingestellt und spielte diese Rolle eine Weile, bis ich zum Regisseur kam." Der Großteil meiner Arbeit bezieht sich jetzt auf den Bereich der Softwarearchitektur. Ich habe viel Zeit an der Schnittstelle von Architektur und Ingenieurspraktiken verbracht (z. B. kontinuierliche Bereitstellung). Ich vermute, dass sich hier meine Interessen mit denen des Heisenbug-Publikums überschneiden.

Insbesondere worüber ich in letzter Zeit viel gesprochen habe, ist das Thema meines neuesten Buches, die Konstruktion der evolutionären Architektur. Wenn Sie Fehler verhindern können, sind die Personen, die die Anwendung testen, einfacher. Die evolutionäre Architektur umfasst Sicherheitstechniken für wichtige Architekturfunktionen wie Bereitstellbarkeit, Testbarkeit, Skalierbarkeit, Leistung usw.

"Was bedeutet Meme Wrangler?"

- Gemäß den Regeln von ThoughtWorks können Sie eine beliebige Berufsbezeichnung auswählen, mit Ausnahme einiger reservierter Berufsbezeichnungen wie "CEO". Wenn Sie sich eine interessante Position einfallen lassen, dann bitte. Und wenn der Satz Visitenkarten endet, können Sie sich eine neue einfallen lassen.

Mein erster Job war ein Anwendungsarchitekt. Diese Position spiegelte die Essenz der Arbeit wider, aber sehr oft impliziert dies in großen Unternehmen, dass Sie nicht mehr viel Nutzen bringen, dass Sie mehr Zeit damit verbringen, Bilder zu zeichnen als etwas zu erstellen.

Einer der Vorteile der benutzerdefinierten Entwicklung besteht darin, dass Sie eine Vielzahl verschiedener Projekte kennenlernen können. Ich denke, Softwarearchitekten sind von Natur aus „Mustervergleicher“: Wir versuchen, Muster auf alles anzuwenden, was wir sehen, auch auf Dinge aus der realen Welt. Wenn Sie ein Architekt in der kundenspezifischen Entwicklung sind, müssen Sie viele verschiedene Projekte sehen, Sie sehen sich darin wiederholende Muster, Sie sehen, welche davon funktionieren. Und mir wurde klar, dass meine Arbeit darin besteht, interessante Ideen aus dem Software-Ökosystem zu sammeln. Von hier kam der Meme Wrangler.

Meme ist ein Begriff, der vom Schriftsteller Richard Dawkins geprägt wurde und eine weit verbreitete Einheit zur Bezeichnung von Ideen ist. Jeder kennt Memes aus dem Internet - das ist eine witzige Sache, die sich wie ein Virus fängt und verbreitet. Und das Wort „Streit“ hat zwei nützliche Bedeutungen: Die erste besteht darin, in einem Streit als Richter zu fungieren, und die zweite darin, in eine Herde zu fahren. Und ich habe mich für die Position von Meme Wrangler entschieden, weil sie genauer widerspiegelt, was ich jetzt mache. Außerdem schreibe ich jetzt, da ich ein anderes Buch veröffentliche, auf Twitter, dass ich "ein anderes Mem lasso" und es in dieses Buch schreibe.

- Können Sie erklären, was ein Softwarearchitekt tun soll, was Sie als Softwarearchitekt tun?

"Natürlich kann ich es versuchen, aber es gelingt niemandem wirklich, dies zu definieren." Martin Fowler - ein Mann, der sehr cool darin ist, alles im Bereich der Programmierung zu definieren - hat sich öffentlich geweigert, den Begriff „Softwarearchitekt“ in seinem Text „Wer braucht einen Architekten?“ Zu definieren. .

Wenn Sie sich jedoch die Rolle eines Softwarearchitekten ansehen, ist eines der Dinge, dass er für alles verantwortlich ist, was dann schwer zu ändern ist. Dies hängt alles mit der Struktur Ihres Softwaresystems zusammen: Welche grundlegenden Muster werden Sie verwenden, welche Sprache oder welche Frameworks. Weil all diese Entscheidungen weitreichende Konsequenzen haben.

Eines der Dinge, die Architekten wirklich sehr interessieren, ist das, was wir "Architekturparameter" nennen, was auch als "nicht funktionale Anforderungen" bezeichnet wird, aber wir mögen diesen Namen nicht. Dies sind Dinge wie Leistung, Skalierbarkeit, Elastizität und Bereitstellbarkeit - all dies liegt in der Verantwortung des Architekten. Ein Architekt kann eine Struktur erstellen, die die Anforderungen an das Programm selbst und alle diese darin enthaltenen Architekturparameter berücksichtigt.

Angenommen, Sie sind Architekt und müssen eine Softwaresystemstruktur für die Registrierung von Studenten an einer Universität erstellen. Angenommen, wir haben tausend Studenten und 10 Kurse, für die sie sich einschreiben müssen. Und jetzt, basierend auf unserem Wissen darüber, wie Universitäten organisiert sind, was wird Ihrer Meinung nach passieren: Die Studenten werden gleichmäßig über das Semester verteilt, so dass wir in jedem Kurs die gleiche Anzahl von Studenten haben, oder sie werden alle bis zur letzten Stunde dauern, und dann hast du es eilig, alles auf einmal aufzunehmen?

Und das ist Elastizität. Dies ist ein Architekturparameter, den Sie beim Erstellen eines solchen Systems sicherstellen müssen. Höchstwahrscheinlich wird dies nirgendwo angezeigt, aber Sie wissen es, einfach basierend auf dem Themenbereich. Dies macht die Architektur von Softwaresystemen so komplex: Sie müssen den Themenbereich sowie die technischen Fähigkeiten und Einschränkungen Ihres Unternehmens verstehen. Sie können beispielsweise dadurch eingeschränkt werden, dass diese relationale Datenbank bereits für den Standard unseres Unternehmens ausgewählt ist und wir die Produktivität steigern müssen. Wie können wir diese Ergebnisse erzielen?

Dies ist die Arbeit des Softwarearchitekten - um all diese wichtigen Entscheidungen zu bewältigen, die damit verbunden sind, dass sie sehr langfristige Konsequenzen haben und es sehr schwierig ist, sie später zu ändern. Viele Elemente der Struktur, wie z. B. die Benutzeroberfläche, sind recht einfach zu entwickeln, da Sie nur eine Ebene der Anwendung ändern. In der Architektur geht es mehr darum, wie all diese Ebenen nebeneinander stehen, und es ist normalerweise viel schwieriger, sie zu ändern.

Sie sagen, dass Microservices mittlerweile sehr beliebt sind und eine solche Architektur speziell mit der Erwartung ständiger Änderungen geschaffen wurde. Es ist also viel einfacher, größere Änderungen an der Microservice-Struktur vorzunehmen, diese wurden jedoch von Anfang an erstellt. Und dies ist ein sehr interessantes Thema für die Forschung - wie man eine Architektur entwirft, die leicht zu ändern ist, denn für die Industrie ist dies genau das, was seit langer Zeit am schwierigsten war.

- Zum Thema Architektur und Beiträge: Ich sehe immer mehr „QA Architect“ auf Visitenkarten und LinkedIn.

- Dies ist eines der Probleme des Begriffs „Architekt“: Jedes Unternehmen muss dafür seine eigenen Namen erfinden. Ich traf sowohl "QS-Architekten" als auch "Datenarchitekten", "Systemarchitekten", "Lösungsarchitekten", "technische Architekten" - ich traf Architekten aller möglichen Richtungen. Und das ist ein Problem, weil niemand eine klare Definition geben und geben kann, was Sie wollen.

Was "Architekten-Qualitätssicherung" für ein bestimmtes Unternehmen bedeuten kann, weiß ich nicht einmal genau. Entwickelt eine solche Person eine QS-Struktur? Für mich ist dies näher an der Funktion eines Architekten als technischer Experte, da ein Architekt häufig auch ein technischer Projektmanager ist. Der Architekt befasst sich aber auch mit Präsentation und Dokumentation. Wenn ich Architekt bin und eine brillante Idee für eine neue Architektur hatte, aber keine Präsentation halten und die Leute nicht mit Geld davon überzeugen kann, dass wir dies tun sollten, haben wir keine Chance, meine coole Idee zu verwirklichen. Dies bedeutet Kommunikationsfähigkeit.

Diese Fähigkeiten gelten für die Qualitätssicherung, und wer dies tut, kann auch als „Architekt“ bezeichnet werden. Sie sehen, das ist so ein vager Beitrag. Viele Organisationen kommen einfach dazu, den leitenden Ingenieur als Architekten zu bezeichnen, weil es cool klingt und sie nicht herausfinden können, wie sie es sonst nennen sollen. Wie Sie wissen, Senior-Senior-Senior-Entwickler - okay, Architekt. Und ich traf Unternehmen, bei denen es eine Art von Architekten gibt, und ich traf Unternehmen, bei denen es Dutzende verschiedener Arten von Architekten gibt. In der Tat sind dies fiktive Beiträge. Mein "Meme Wrangler" ist in diesem Sinne besser, weil es offensichtlich erfunden ist.

- Lassen Sie uns in Richtung Ihrer Rede bei Heisenbug sprechen. Sie werden auf einer Testkonferenz sprechen - was ist mit der Qualität der Software für Sie?

- Ich persönlich betrachte die Qualität der architektonischen Komponenten des Systems. Ich weiß, dass die QS-Welt Software eher als Black Box betrachtet, dh aus Sicht des Benutzers sieht es aus, ob es Fehler und Ausfälle gibt, ob sie richtig funktioniert. Natürlich interessiert mich das auch, aber ich mache mir mehr Sorgen um die Hauptursachen von Fehlern: Warum ist die Anwendung unzuverlässig, warum stürzt sie regelmäßig ab? Hier muss ich die letzte Verteidigungslinie sein, um herauszufinden, warum dies geschieht. Und es gibt Dinge wie Leistung und Reaktionsfähigkeit. In der Welt der Benutzeroberfläche wird derzeit viel über sie gesprochen. Sie haben eindeutige Indikatoren: Wenn Ihre mobile Website sichtbare Inhalte länger als 3 Sekunden lädt, verlassen Benutzer die Website und gehen an einen anderen Ort.

Besonderes Augenmerk wird auf die Webleistung gelegt: Wie lange dauert es, bis der erste sichtbare Inhalt geladen wird, wie lange dauert es insgesamt? Und all dies sind Qualitätsparameter, die aus Sicht eines externen Beobachters sicherlich sichtbar sind, und ich bin derjenige, der herausfinden sollte, wie wir ein System aufbauen werden, in dem solche Indikatoren erreicht werden. Dies kann zu Änderungen im Frontend hinsichtlich der verwendeten Webtechnologien führen, aber auch zu Änderungen im Backend. Vielleicht, um Informationen nicht in Echtzeit, sondern in einem Paket zu übertragen und in der Mitte einen Caching-Mechanismus zu erstellen? Für mich sieht Qualität so aus: Bestimmen Sie die Anforderungen und entwickeln Sie dann eine technische Implementierung, die sie verkörpert.

- Können Sie die interessanteste Fallstudie aus der Praxis in Bezug auf Qualität geben?

- Es ist schwer zu sagen, dass alle Projekte unterschiedlich sind. Das Beste ist also immer das letzte, an dem ich gearbeitet habe!

Irgendwie habe ich an einem System gearbeitet, bei dem die Anforderungen teilweise Lotus Notes ähnelten. Erinnerst du dich an so ein altes Programm? Sie war ein schreckliches Programm, aber eines hat sie sehr, sehr gut gemacht. Dieses Programm war sehr gut synchronisiert: Sie konnten Ihre E-Mails und Notizen herunterladen, dann ein Taxi nehmen, irgendwohin fahren, alle Briefe zu diesem Zeitpunkt beantworten, und wenn Sie das nächste Mal eine Verbindung zum Netzwerk herstellen, wird alles automatisch entladen, synchronisiert und funktioniert auf magische Weise Weg.

Und wir hatten einen Kunden mit einem Verkaufssystem, der das gleiche Funktionsprinzip wollte. Weil die Verkäufer immer in Bewegung sind und es notwendig war, dass sie Bestellungen ohne Internetverbindung aufgeben konnten und dann alles synchronisierte und so wurde, wie es sollte.

Und wir haben erkannt, wie schwierig dies ist, da eine Reihe von Grenzfällen und Szenarien bereitgestellt werden müssen. Zuerst haben wir ein System entwickelt, das überhaupt ohne Internetverbindung funktioniert, dann haben wir mit der Synchronisation begonnen. Und es gab eine Reihe von Kopfschmerzen - zum Beispiel, die Leistung einer Anwendung online im Vergleich zu offline, trat beim Herstellen einer Verbindung eine merkliche Verzögerung auf, da zu diesem Zeitpunkt eine Synchronisation stattfand. In diesem Fall war die Qualitätssicherung ein großer Splitter für uns, da Grenzfälle gefunden wurden, die das gesamte System zerstörten.

Und von außen scheint dies eine einfache Aufgabe zu sein. Anwendungen wie Dropbox und Google Drive haben dieses Problem gelöst, sodass es unsichtbar wurde. Und es scheint einfach. Aber als wir versuchten, es zu lösen, stellte sich heraus, dass es eine Million Grenzfälle gab. Ohne eine zuverlässige Qualitätssicherung ist es daher schwierig, alle zu finden, von denen jede zur Ausrichtung an der Anwendungsstruktur zurückgegeben werden muss, um sicherzustellen, dass die Gesamtstruktur weiterhin funktioniert.

Während wir dieses System entwickelten und grundlegende Änderungen an der Struktur vornahmen, stellten wir fest, dass Grenzfälle häufig und inakzeptabel sind. Dies ist ein gutes Beispiel dafür, wie wichtig es ist, eine sehr gut etablierte Rückkopplungsschleife zwischen Architekturdesign und Teilen wie der Qualitätssicherung zu haben. Zu viele Unternehmen haben dies im allerletzten Moment verschoben, aber wenn Sie dies tun, werden am Ende viele Dinge falsch gemacht, und Sie müssen zurückgehen und viel Zeit aufwenden, um es zu wiederholen. Wenn Sie einen engen Kontakt zwischen der Entwicklung der Architektur und dem Testen herstellen, können Sie diese Grenzfälle finden und die Struktur viel schneller ändern. Glücklicherweise waren wir in diesem Projekt äußerst flexibel - da es sich um ein ThoughtWorks-Projekt handelte, hatten wir einen sehr schnellen Zyklus. Und wir hatten ein sehr starkes Team von Testern.

- Viele Testpersonen fragen, wie sie die Architektur beeinflussen können. Architektur ist für sie etwas in einem Elfenbeinturm. Was kann man damit machen?

- Es scheint mir nützlich zu sein, dass Tester zu den Architekten kommen und ihnen erklären, dass sie ihre Arbeit schlecht machen, und es ist besser für Tester, zu wissen, wie man sie durchführt. Die Leute lieben es, wenn ihnen das gesagt wird! Nein, sie mögen es nicht, es wird nichts Gutes daraus.

Ich habe ein Lieblingsmantra für solche Fälle: "Es ist besser zu zeigen als zu diskutieren." Sie müssen zeigen, wie unterschiedlich Ihre Welt von ihrer Welt ist. Wenn Sie ein Testingenieur sind, müssen Sie einen Benutzerfall mitbringen, der den Konstruktionsfehler deutlich macht. Wenn Sie dieses Szenario einem Architekten zeigen, ist dies nicht nur eine Beschwerde über etwas, sondern eine konkrete Demonstration: „Jetzt funktioniert Ihr Projekt in einem solchen Szenario nicht mehr, daher muss es geändert werden.“ Wenn sie dem nicht zustimmen, bedeutet dies, dass sie einfach den Kontakt zur Realität verloren haben. Und Architekten müssen sensibel für Dinge sein, die in der realen Welt passieren.

Es gibt sehr wenig, wie ich es nenne, Gedichte des ehemaligen Verteidigungsministers Donald Rumsfeld, die vom „berühmten Berühmten“ und „Unbekannten Unbekannten“ sprechen. In jedem Softwareprojekt gibt es also „unbekannte Unbekannte“, daher sollte die Entwicklung jeder Architektur iterativ sein. Da es keine Rolle spielt, über wie viel Sie nachdenken, werden Dinge, die Sie in keiner Weise vorhersehen konnten, einfach plötzlich angezeigt, während Sie versuchen, diese Struktur aufzubauen.

, , 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, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
— .
— .

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», . , , ?

- Natürlich. , , meme wrangler.

, DevOps-. , , . DevOps , , — , , .

, — , « » . . , . , : , , . , , ?

— .
— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .

, , — , , .

— . !

Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .