Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。Coplien氏とMartin氏、TDDとCDDそしてプロフェッショナルの定義について大いに語る。Martin氏はアジャイルマニフェストの起草者の一人であり、アジャイルプログラミング、XP、UML、オブジェクト指向プログラミング、C++などの多くの本の著者でもある。Mentor社(www.objectmentor.com)のCEOであり社長である。Coplienはオブジェクト指向プログラミングとC++とマルチパラダイム設計の第一人者である。彼は設計において人間が関わる側面の価値を認めており、設計や開発について彼が書いた本は非常に高い評価を受けている。Marinescuです。Martin氏と居ます。我々には、TDDの価値が何なのかというところで、とても興味深い見解の相違があります。そこで、それぞれが2~3分づつ発言しながら、議論をしましょう。私はあなた達の話を聞いていますから。最初にこれを言っておく必要があります。今私は、自分にとってヒーローと言える人の隣に座っています。私は1991年から1992年ぐらいにJim氏の本を読み、ソフトウェアに対する私の考え方を改めました。C++に対する考え方を。今この場にいられてとても光栄です。我々の見解の相違は、確信というわけでなくあくまで可能性ですが、観点の違いだと思っています。私の論点というのは、ここ6年の間に何が起きたかを考えると、テスト駆動開発していないソフトウェア開発者は"プロフェッショナル"であると自称できなくなってきているということです。昨日のあなたの基調講演では"テスト駆動開発"を使って何をしようとしているかという話でしたから、それはよいことだと思います。私は、とりわけXPコミュニティがテスト駆動開発と呼んでいるものについてについて強く反対してきました。過去6ヶ月の4っのカンファレンスで行われた多くのチュートリアルと聴講してみたのですが、彼らがテスト駆動開発と呼ぶものには、きわめて一貫した恣意的なストーリーが用いられていることがわかります。昨日の話しは、少し違っていました。そこで、この議論を有意義で意味あるものにするために、まずあなたの昨日の話を簡潔に繰り返してくれますか。すれば、前提を合わせて話ができます。BobはJimの要望に応え、三つの原則を紹介している。最初の一つは、テスト駆動開発者は、失敗するユニットテストを書くまでは、プロダクションコードは1行たりとも書かないというこです。失敗するユニットテストが存在していないのであれば、プロダクションコードは書かれていない筈です。二つ目の原則は、テストを失敗させるために充分なユニットテストがあれば、それ以上ユニットテスト書いてはいけないということです。コンパイルできないという状態は失敗に含みます。プロダクションコードを書いてないうちからユニットテストをたくさん書くことはできません。三つ目の原則は、テストをパスさせることができる充分なプロダクションコードがあれば、それ以上プロダクションコードを書いてはいけないということです。ユニットテストは書きかけで、それを脇に置いてプロダクションコードを書くということはやってはいけません。この三つの原則は、およそ30秒ぐらいのサイクルで行います。テストを30秒から1分ぐらいで行うことで、ユニットテストとプロダクションコードを実質的に同時に書くことが重要なのです。いまのところ、私がTDDについて抱いている主な懸念は、あなたの今の発言に関する限り、あまり問題ではないと考えています。それ以上でもそれ以下でもないのならば、私たちに考えにズレははないと思います。私の懸念は何なのか、というと、自分が多くの顧客と幅広い仕事をした中で体験したり、他のコンサルタントやスクラムマスター達が彼ら自身のプロジェクトで経験した話を聞いているうちに気づいたものなのです。私たちは今まで2つの重要な問題を確認してきました。1つ目の問題は、TDDでは実際に稼働している環境と同じアーキテクチャやフレームワークが無い状態でテストされているという点です。これはKent氏が最初の頃に強く主張していた「TDDをアーキテクチャを駆動するために使うのだ」というもので、ユニットテストすることで、手続き型ボトムアップアーキテクチャの原因になります。私たちは今さっき上の階で「TDDはユニットテストと同じなのか?」という議論をしていましたね。同じではないと思います。Fortranではユニットテストというのは素晴らしい考え方でした。APIを階層化したときにソフトウェアの構成要素としてのユニットは、ユニットテストと一致させることができたからです。今やソフトウェアの構成要素としてのユニットはオブジェクトなのに、テストしているのは手続きです。そこにはちょっとした不整合があるのです。アーキテクチャを駆動するためにこういった手段を取るならば、2次元データから3次元データを作り出すようなもので、結局失敗すると思います。いった光景は多くのプロジェクトでよく見られるものです。いう場合はリファクタリングをすることでこの状態から抜けることはできなくなっています。クラスのカテゴリ、階層を超えてリファクタリングしないといけない状況に陥っているので、リファクタリングしても同じ機能を維持しているかの保証ができないのです。Reenskaug氏と私がGUIの破壊にみられる現象についていろいろと話していた件です。Javaクラスラッパのような手続き的アーキテクチャを例に出すと、そこにはオブジェクト指向でそうしているような、ドメイン知識やユーザのコンセプトモデルに沿った形での構造の決定がもはやできなくなっているのです。Kent氏でさえ、しばしば「良いGUIを以てしても拙いアーキテクチャは隠しきれない」と言っています。アーキテクチャは常にインターフェスを透かして見えてくるものだと思います。言うと、ドメインモデルがインターフェースにどう影響するのか、という構図はインフラストラクチャにあるのですから、インフラストラクチャは重要なのです。ボブおじさんの三つの原則を当てはめようと思うなら、そうすること自体は問題ないでしょうが、私は、構造的な側面を把握できるような出発点があるとよいと思います。あなたは、テスト駆動開発の習慣は2007年の現在、プロフェッショナルな行動としての純粋な要件である、という命題については受け入れていないようです。それはどうしても受け入れられませんね。それでは最初の話題に戻りましょう。興味深い話ですからね。プロフェッショナルとは何かという話でしたが、その前に、アジャイルコミュニティの中では1999年頃からアーキテクチャというものは重要ではないという意見がありました。アーキテクチャをどうこうする必要はないということです。私たちに必要なのは、テストと、たくさんのストーリーをこなすこと、短いイテレーション、それから魔法のように自ら結合するコード、結局馬糞みたいなものしかできませんが、これが全てだという考え方でした。愚かなことに、アジャイル提唱者の大部分がそれに同意していました。今あなたがKent氏に会いに行って話をしたとしたら、彼がいつも言っているようにこう言うでしょう。「XP入門」だったと思うんですが、131頁で彼は実際こう言っています。いくつかのアーキテクチャは予め決めておきなさい。自分自身を失神させない程度に。話を元に戻して、他の視点で考えてみましょう。アーキテクチャというのはとても重要だと考えています。私自身多くのアーキテクチャに関する論文や書籍を書きましたし、アーキテクチャのかなりマニアだと思います。一方で、アーキテクチャというのは一枚布のようなもので出来るとは思っていません。した設計とアーキテクチャのスキルを使いながら、週や月単位のイテレーションを何回も繰り返し、アーキテクチャを少しずつ積み上げるやり方をするのが普通だと思います。作り出したアーキテクチャを構成する要素のうちいくつかは、捨ててしまうこともあるでしょう。いう時は、イテレーションを数回使って別のアーキテクチャを試したりすると思います。2~3回のイテレーションを経て、正しいと思えるアーキテクチャに落ち着いた上で、調整フェーズに入ります。私の考えは、コードを実行することで情報を得て進化し、テストを書くことでも情報を得て進化する、そういうものがアーキテクチャなのです。J:アーキテクチャが進化するというところには同意します。アーキテクチャというのは、書き上げたコードと、おそらく早い段階で提供されているであろうユースケースとの両方を使って形成していくものだと思います。アーキテクチャはスコープであったり、他のそういった類の情報も与えてくれますが、インクリメンタルにアーキテクチャの設計をやろうとしたならば、文字通り全てがインクリメンタルになってしまいます。ドメイン知識が事前に得られていない状態で顧客と作業を進めてしまうと、完全に間違った方向に進んでしまう怖れがあります。Kent氏と話をしていた時のことを話しましょう。彼がTDDや、動作しうる最も単純な方法で実装しようという意味でYAGNIという言葉を提唱したばかりのころ、彼は「よし。銀行の預金口座を実装しよう。預金口座っていったい何のことでしょうか?足したり引いたりできるだけの数字のことです。預金口座というのは計算機のことですね。差引残高に足したり、そこから引いたりするのを表示する計算機を作りましょう。これが動作しうる最も単純な例で、他の全てはその発展形であると言えます。本物の金融システムにしようとしても、預金口座はオブジェクトでさえないので、そこからリファクタすることで正しいアーキテクチャへ導けるようなものではありません。預金口座というのは、監査証跡をしつつ、預金、金利の集計、その他のお金の動きなどのデータベーストランザクションを繰り返し処理する一連のプロセスのことです。ユーザの立場から見た場合、預金口座は銀行のどこかの棚にいくらかのお金が置いてあるのとは訳が違います。ご存じのように、金融システムの基盤では、税理士や保険計理士、そういった民間の人達をサポートするために、他と比べて複雑な構造になっています。インクリメンタルな手法で取りかかれないのです。いや、不可能とまでは言えないですね。銀行業界が40年かけてここまできたように40年ぐらいかければ。そこに40年を費やすことができますか?でも、それはアジャイルとは言えませんね。前提知識を活用するべきなのです。確実な決断だけでも最初にいつくか行っておくべきでしょう。することで、決めきれなかった事項を後になって検討する時に、その判断を容易にしてくれるはずです。確かに状況は変わりますし、アーキテクチャは進化します。「アーキテクチャを塩漬けにしなさい」とまで言う人はいないんじゃないでしょうか。前もって適切なコード、つまり実際のメンバ関数として書かれるコードということですが、それができるとは思えません。見た目を書く、ロールを書く、ドメイン知識の構造を表現できるようなインターフェースを書く...そうして書いたものの中身のコードを書くのは、お金を払ってくれるクライアントを見つけてからです。しないとリーン原則に違反してしまうからです。「ジャストインタイム」方式でやるならば、最初から構造を押さえておこうとするべきです。しないと、リスク管理しているつもりで、自分自身の首を絞めているようなものです。小さな誤解についての説明と、いくつかそれに対する反論をさせてください。私は、抽象的なメンバ関数や存在しないメンバ関数を持つようなインタフェースを実装することは、まずありません。適切なインタフェースを持つオブジェクトを作るようにしています。Javaで説明すると、そこに何もないような「なんとかインタフェース」を作ることはあったかもしれないですが、いつか実装することがあるかもしれないと、たくさんのメソッドを持つインターフェースを取り入れるようなことはしていません。それが、テスト駆動や要求駆動を使おうとしている理由です。インターフェースを分離したほうがいいきっかけとなるアーキテクチャの不和を、鵜の目鷹の目で探しています。問題なのは、いわば、言葉というものが定義とは別に意味を持っているということです。何かをラバと呼んだり、ラバとは何ですか?と問うことをしなくても、ラバはラバという事実は変わりません。リンカーンが言ったように「ラバをロバと呼んでみても、ロバになるわけではない。メンバ関数がセマンティクスとして、意味を教えてくれています。やりすぎたり、当てずっぽうにやってはいけない...この点ではKent氏に同意できます。「XP入門」で彼が言っているように、「当てずっぽうにやってはいけない」これは真実です。ここで私の知っていることを確認しておきたいと思います。いくつかご存じのこともあるかとは思いますが、通信システムや金融システムの仕組みについてです。"recovery"オブジェクトを作ってはいけないということはご存じかと思います。私はかつて、大きな通信会社のプロジェクトの再構築に携わっていました。そこではオブジェクト指向と最新のコンピュータサイエンスの技術を駆使して、使用料の切換システムを作り直していました。そのプロジェクトで私に任されたのは"recovery"オブジェクトを作るような輩と一緒に仕事することでした。"recovery"はオブジェクトではないのに。彼の薄っぺらいドメイン知識ではそうするしかなかったのでしょう。そのオブジェクトのメンバ関数の正体を突き止めてみれば、それがオブジェクトですらないことが理解できると思います。そこで、こう聞きます。「う...ええと、recover関数です。