テストとアーキテクチャの交差点：ニール・フォードとのインタビュー

QAアーキテクトの立場とはどういう意味ですか？ ミーム・ラングラーの完全に曖昧な位置はどういう意味ですか？ アーキテクチャに取り組むとき、いつからテスターを接続する必要がありますか？ 組織内のプロセスを変更して、最初の複雑さを持つ会議の人々が古いものに戻らないようにする方法



Neil Fordの Webサイトには、「ThoughtWorker」（多くの人がMartin Fowlerで知っているThoughtWorksの従業員）、「Software Architect」、「Meme Wrangler」の3つのオプションがあります。 まもなく、Heisenbugカンファレンスで、彼は外部の環境の変化に応じて変更できる「進化的アーキテクチャ」の作成について話します。 その間、 Mikhail xomyakus Druzhinin （Heisenbugプログラム委員会のメンバー）はNeilに尋ねました。彼のスピーチがテストとどのように交差するか、などなど。



-あなたはあなた自身とあなたのキャリアについて話すことから始められますか？



-もちろん。 ThoughtWorksには14年近く勤務しています。 それ以前は、約25人の小規模なコンサルティングおよびトレーニング会社のCTOでしたが、そこでJavaのような技術を試し始めました。 ThoughtWorksに入社する前に書いた最初の3冊の本。 最初の1つはDelphiに関するもので、当時はロシアとヨーロッパで非常に人気がありました。



私がCTOだったとき、私はアルファオタクであることにうんざりしていました。 周りの人たちが特に成長しているわけではないことを知っているとき。 私はさまざまな会議で講演を始めましたが、他の講演者が非常に頭が良く、興味のある人たちだったので、本当に楽しかったです。 そして、私は無意識のうちに、本当に賢くて興味のある人々が主に働く会社を探し始めました。 そして、多くのように、Martin FowlerのWebサイトでThoughtWorksを文字通りつまずいた。 CruiseControlやNUnitテストライブラリのようなものについて、私はそれらがオープンソースに多大な貢献をしており、非常に興味深いことをたくさんしていることに気付きました。 そのため、思いがけずThoughtWorksとのインタビュープロセスを開始しましたが、最後に求人を受け取りました。 彼らは非常に賢く、非常に熱心な開発者であるため、これは私にとって良いステップでした。



私は独立したコンサルタントになれるかもしれませんが、この役割では2つのことは好きではありません。 まず、すべてのビジネスを自分で行う必要があります。請求、金銭の追求、キャッシュフローの規制など。 私はこれを行うことができますが、私には興味がありません。 私の情熱はソフトウェアと開発です。



2番目：独立したコンサルタントである場合、チームとして共同作業を行うことはほとんどありません。 あなたはほとんど常に独力で、私はチーム開発が本当に好きです。 私は、私の最新の本であるEvolutionary Architectureを含め、他の著者と一緒にいくつかの本を書きました。 一緒に作業すると、結果は個々のコンポーネントの合計よりも大きいように思えます。 執筆プロジェクトであろうとプログラムであろうと、クリエイティブな作品でコラボレーションする場合、より多くの視点とより一般的なアイデアを得ることができるため、結果はより良くなります。



ですから、4月にはThoughtWorksにいたときから14年が経ちます。 ThoughtWorksで働くことの興味深い利点の1つは、会社に10年間在籍している場合、何でもやりたいときに12週間の有給休暇を取得できることです。 その後、5年ごとに6週間の有給のクリエイティブ休暇を取得するため、最初の6週間まであと1年です。 私は12週間のものが本当に好きで、次のものを楽しみにしています。 ですから、あなたは何十年もここにいたことを常に覚えています：彼らはそのような楽しい休日で測定されます。



-これは非常に具体的な休暇期間であり、クールです。



「ThoughtWorksにアーキテクトとして雇われ、ディレクターレベルに達するまでしばらくその役割を果たしました。」 現在、私の仕事のほとんどはソフトウェアアーキテクチャの分野に関連しているため、アーキテクチャとエンジニアリングの手法の交差点（たとえば、継続的な配信）に多くの時間を費やしました。ここで、私の関心はハイゼンバグの読者のものと交差しています。



特に、最近私がよく話したことは、私の最新の本である進化的アーキテクチャの構築のトピックです。 バグを防ぐことができれば、アプリケーションをテストしている人にとって簡単になります。 進化的アーキテクチャには、展開性、テスト容易性、スケーラビリティ、パフォーマンスなどの重要なアーキテクチャ機能のセキュリティ技術が含まれています。



「ミームラングラーとはどういう意味ですか？」



-ThoughtWorksのルールに従って、「CEO」などの予約済みの職種を除き、任意の職種を選択できます。 あなた自身のために興味深い位置を思い付いたら、それからお願いします。 また、一連の名刺が終了したら、新しい名刺を作成できます。



私の最初の役職は「アプリケーションアーキテクト」でした。 この立場は作品の本質を反映していますが、大企業では非常に多くの場合、特別な利益をもたらさず、何かを作るよりも絵を描くことに多くの時間を費やすことを意味します。



また、カスタム開発の利点の1つは、多数の異なるプロジェクトに精通できることです。 ソフトウェアアーキテクトは、本来「パターンマッチャー」であると思います。私たちは、目に見えるすべてのものに、実際の世界のものにもパターンを適用しようとしています。 そのため、カスタム開発のアーキテクトである場合、多くの異なるプロジェクトを確認する必要があり、それらのパターンを繰り返し表示し、どれが機能するかを確認します。 実際、私の仕事はソフトウェアエコシステムから興味深いアイデアを収集していることに気付きました。 ここからミームラングラーが来ました。



ミームは、作家リチャード・ドーキンスによって造られた用語です;それは、アイデアを指定するための広範なユニットです。 インターネットのミームは誰もが知っています。これは、ウイルスのようにキャッチして拡散する機知に富んだものです。 また、「絞殺」という言葉には2つの有用な意味があります。1つ目は紛争で裁判官として行動すること、2つ目は群れに追い込むことです。 そして、ミーム・ラングラーの立場を選んだのは、私が今していることをより正確に反映しているからです。 さらに、今私は別の本をリリースしているので、Twitterで「別のミームを投げかけ」、それをこの本に入れていると書いています。



-ソフトウェアアーキテクトがすべきこと、ソフトウェアアーキテクトとして何をすべきかを説明できますか？



「もちろん、私は試すことができますが、これを定義することに成功した人はいません。」 プログラミングの分野のすべてに定義を与えるのが非常にクールなマーティンファウラーは、「ソフトウェアアーキテクト」という言葉を「誰がアーキテクトが必要か？」と定義することを公に拒否しました。



しかし、ソフトウェアアーキテクトの役割を見ると、物事の1つは、変更するのが難しいすべてのものに責任があるということです。 これはすべて、ソフトウェアシステムの構造、つまりどの基本パターンを使用するか、どの言語またはどのフレームワークに関連するかです。 これらの決定はすべて、広範囲にわたる結果をもたらすためです。



建築家が本当に気にかけていることの1つは、「非機能要件」とも呼ばれる「アーキテクチャパラメーター」と呼ばれるものですが、この名前は好きではありません。 これらは、パフォーマンス、スケーラビリティ、弾力性、展開性などです。これらはすべて、アーキテクトの責任です。 アーキテクトは、プログラム自体の要件、およびプログラムで提供する必要のあるこれらすべてのアーキテクチャパラメーターを考慮した構造を作成できます。



あなたが建築家であり、大学に学生を登録するためのソフトウェアシステム構造を作成する必要があるとします。 登録する必要がある1,000人の学生と10のコースがあるとします。 そして今、大学がどのように組織されているかという知識に基づいて、あなたは何が起こると思いますか：学生は学期中に均等に分配され、各コースで同じ数の学生が得られるか、最後の1時間まですべてが続きますすぐにすべてを記録するために急いで？



そして、これは弾力性です。これは、このようなシステムを作成するときに確認する必要があるアーキテクチャ上のパラメーターです。 ほとんどの場合、これはどこにも示されていませんが、サブジェクト領域に基づいて単純にわかります。 これが、ソフトウェアシステムのアーキテクチャを非常に複雑にしている理由です。つまり、会社の技術的な能力と限界だけでなく、対象分野も理解する必要があります。 たとえば、このリレーショナルデータベースが既に当社の標準として選択されているという事実によって制限される可能性があり、パフォーマンスを向上させる必要があります。 これらの結果をどのように達成できますか？



これはソフトウェアアーキテクトの仕事です。非常に長期的な結果をもたらし、後で変更することは非常に難しいという事実に関連するこれらすべての重要な決定に対処するためです。 ユーザーインターフェイスなど、構造の多くの要素は、アプリケーションの1つのレイヤーを変更するだけなので、非常に簡単に開発できます。 そして、アーキテクチャは、これらすべてのレイヤーがどのように並置されるかについての詳細であり、通常は変更がはるかに困難です。



彼らは、マイクロサービスは現在非常に人気があり、そのようなアーキテクチャは絶えず変化することを期待して特別に作成されたと言います。 したがって、マイクロサービス構造に深刻な変更を加えることははるかに簡単ですが、それらは最初から作成されました。 そして、これは研究にとって非常に興味深いトピックです。業界にとってこれは非常に長い間最も困難であったため、変更が容易なアーキテクチャを設計する方法です。



-アーキテクチャと投稿の問題：名刺とLinkedInに「QAアーキテクト」がますます表示されています。



-これは「アーキテクト」という用語の問題の1つです。各企業はこのために独自の名前を考案する必要があります。 「QAアーキテクト」と「データアーキテクト」、「システムアーキテクト」、「ソリューションアーキテクト」、「技術アーキテクト」の両方に会いました-あらゆるストライプのアーキテクトに会いました。 そして、これは問題です。誰も明確な定義を与えることができず、あなたが望むものを与えることができないからです。



特定の会社にとって「QAアーキテクト」とはどういう意味なのか、私にもわかりません。 そのような人はQA構造を開発していますか？ 私にとっては、多くの場合、建築家も技術プロジェクトマネージャーであるため、技術専門家としての建築家の機能に近いです。 しかし、アーキテクトはプレゼンテーションとドキュメントも扱います。 ですから、私が建築家であり、新しい建築の素晴らしいアイデアを持っているのに、プレゼンテーションをしてお金で人々にこれをすべきだと納得させることができなければ、私のクールなアイデアを実現する機会はありません。 これはコミュニケーションスキルを意味します。



これらのスキルはQAフィールドに適用され、これを行う人は「アーキテクト」とも呼ばれます。 ほら、これはとてもあいまいな投稿です。 多くの組織は単純にシニアエンジニアをアーキテクトと呼ぶようになります。これはクールに聞こえ、他に何を呼ぶべきかわからないからです。 たとえば、シニアシニアシニア開発者-わかりました、アーキテクト。 そして、私はあるタイプの建築家がいる会社に会い、何十種類もの建築家がいる会社に会いました。 実際、これらは架空の投稿です。 私の「ミームラングラー」は、明らかにこの構成であるため、この意味で優れています。



-ハイゼンバグでのスピーチの方向に話しましょう。 あなたはテスト会議で講演します-あなたのためのソフトウェアの品質はどうですか？



-システムのアーキテクチャコンポーネントの品質を個人的に検討します。 QAの世界では、ソフトウェアをブラックボックスと見なします。つまり、ユーザーの観点から、エラーや障害の有無、正常に機能するかどうかを確認します。 もちろん、これにも興味がありますが、エラーの根本的な原因についてもっと心配しています。なぜアプリケーションが信頼できないのか、なぜ定期的にクラッシュするのか？ ここで私はこれがなぜ起こっているのかを理解し、最後の防衛線にならなければなりません。 また、パフォーマンスや応答性などがあります。 現在、UIの世界では多くの話題があり、明確な指標があります。モバイルサイトが表示コンテンツを3秒以上ロードすると、ユーザーは別の場所に移動します。



Webパフォーマンスには大きな注意が払われます。最初に表示されるコンテンツをロードするまでの時間、ページのロード時間の合計です。 そして、これらはすべて品質パラメーターであり、外部の観察者の視点から確実に見ることができます。私は、そのような指標が達成されるシステムをどのように構築するかを理解すべきです。 また、これにより、使用されるWebテクノロジーに関するフロントエンドの変更につながる可能性がありますが、バックエンドの変更にもつながる可能性があります。 おそらく、リアルタイムではなくパケットで情報を送信し、途中でキャッシングメカニズムを作成するのでしょうか。 私にとって、品質は次のようになります。要件が何であるかを判断し、それを具体化する技術的な実装を考え出します。



-品質に関する実践から最も興味深いケーススタディを教えてください。



-言うまでもありませんが、すべてのプロジェクトが異なっているため、常に最後に取り組んだプロジェクトが最高です！



まあ、どういうわけか、私は要件がLotus Notesに部分的に似ているシステムで作業しました。 そのような古代のプログラムを覚えていますか？ 彼女はひどいプログラムでしたが、彼女は非常に良いことをしました。 このプログラムは非常によく同期しました：メールとメモをダウンロードし、タクシーをつかまえ、どこかに行き、その時点ですべての手紙に答えて、次にネットワークに接続すると、すべてが自動的にアンロードされ、同期されて魔法のように動作します方法。



そして、同じ動作原理を望んでいた販売システムを持つクライアントがいました。 営業担当者は常に移動しているため、インターネットに接続せずに注文できるようにする必要があったため、すべてが同期して必要な状態になりました。



そして、提供する必要のある一連の境界ケースとシナリオのために、これがどれほど難しいかを認識しました。 まず、インターネットに接続せずに機能するシステムを開発し、次に同期を開始しました。 また、多くの頭痛の種がありました-たとえば、オフラインと比較したオンラインでのアプリケーションのパフォーマンス、そのときに同期が行われていたため、接続時に顕著な遅延が発生しました。 したがって、この場合、QAはシステム全体を破壊する境界線のケースを見つけたため、私たちにとって大きな破片でした。



そして、外部から見ると、これは単純なタスクのように思えます。 DropboxやGoogle Driveなどのアプリケーションがこの問題を解決し、見えなくなった。 そして、それは簡単そうです。 しかし、私たちがそれを解決しようとしたとき、百万の境界線のケースがあったことがわかりました。 したがって、信頼できるQAがなければ、すべてを見つけることは困難です。全体を構造が機能することを保証するために、それぞれをアプリケーションの構造に合わせて返す必要があります。



実際、このシステムを開発し、構造に根本的な変更を加えている間に、境界線のケースが頻繁に受け入れられないことがわかりました。 また、これは、アーキテクチャ設計とQAなどの部品との間に非常に確立されたフィードバックループを持つことがいかに重要であるかを示す素晴らしい例です。 非常に多くの企業がこれを最後の瞬間に先送りしますが、そうすると、最終的に多くのことが間違ってしまい、やり直すために多くの時間を費やす必要があります。 アーキテクチャの開発とテストの間に密接な関係を確立すると、これらの境界線のケースを見つけて、構造をはるかに迅速に変更できます。 幸いなことに、このプロジェクトでは非常に柔軟でした。ThoughtWorksプロジェクトであるため、非常に速いサイクルでした。 そして、非常に強力なテスターのチームがありました。



-テスト中の多くの人々は、彼らがどのようにアーキテクチャに影響を与えることができるかを尋ねます。 彼らにとって、建築は象牙の塔のようなものです。 これで何ができますか？



-テスターがアーキテクトに来て、彼らが仕事をうまくやっていないことを彼らに説明することはテスターに​​とって有用であり、テスターはそれを行う方法をよく知っているように思えます。 これを言われたとき、人々はそれを愛しています！ 実際、いや、彼らはそれを好まない、それから良いものは何も来ない。



私はそのような場合に好きなマントラを持っています：「議論するよりも見せた方が良い」。 あなたの世界が彼らの世界とどれほど違うかを示す必要があります。 テストエンジニアの場合、設計上の欠陥を明確に示すユーザーケースを提出する必要があります。 このシナリオをアーキテクトに示す場合、これは単に何かに関する苦情ではなく、具体的なデモンストレーションです。「プロジェクトはこのようなシナリオでは機能しないため、変更する必要があります。」 彼らがこれに同意しない場合、これは彼らが単に現実との接触を失ったことを意味します。 そして、建築家は現実の世界で起こることに敏感でなければなりません。



私がそれを呼ぶように、「有名な有名人」と「未知の未知の人」について話す元国防長官ドナルド・ラムズフェルドからの詩があります。 そのため、各ソフトウェアプロジェクトには「未知の未知数」が存在するため、アーキテクチャの開発は繰り返し行う必要があります。 あなたがどれほど考えているかは関係ないので、この構造を構築しようとすると、予測できなかったことが突然現れます。



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



-もちろん。 , , meme wrangler.



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



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



— .

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



, , — , , .



— . !

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