"Understanding Software"の著者、Max Kanat-Alexander氏へのインタビュー

昨年10月、Max Kanat-Alexander氏は"Understanding software"という書籍を出版した。この本はソフトウェアをシンプルに保ち、複雑でメンテナンスできないソフトウェアを避ける方法について書いてある。レビューはこのサイトで読める。

InfoQは氏にインタビューしこの本について話を聞いた。

InfoQ: なぜ、"Understanding software"を書こうと思ったのですか。

Max Kanat-Alexander: それは、この本のイントロダクションで詳しく書きましたが、根本的にはより良いプログラマになることを支援したいからです。私には、プログラミングの基底にある原理を明らかにして、それを世界に共有したいという願望がありました。また、その原理から学んだこと、つまり、どのように原理を応用するか、大規模な組織にその原理を応用することから得られる教訓なども共有したいと思っていました。

InfoQ: どのような読者を想定していますか。

Kanat-Alexander: プログラマーです。プログラマーの周辺で働いている人も興味を引くかもしれません。エンジニアリングマネージャー、プロダクトマネージャーなどです。しかし、プログラマーを対象にした本です。

InfoQ: コードの例はあまり多く含まれていない本ですね。具体的な理由はありますか。

Kanat-Alexander: はい。私は自分の書いたものにコードをあまり入れたくはありません。普遍的な内容にしたいからです。すべてのプログラマーがどのような状況でも応用できる原理にフォーカスしたいと思っています。時代遅れになってしまったり、特定のプログラミング言語を選択することで制限されてしまうような情報は求めていません。汎用的なプログラミング言語で表記したり、Pythonのようなコードで示したりしている部分もあります。

また、巨大なシステムのリファクタリングについて言及する場合があるのも、具体的な例を避ける理由のひとつです。大規模なシステムの仕事をしていると実際に出会うような問題について言及する場合があります。この場合には、システム全体の膨大なコードを記述しなければ、良い例を示すことができません。同じように、あるアイディアが、大規模なシステムをリファクタリングするのに優れたアイディアであることを理解したい場合に、その大規模なシステム全体の例を示すことは難しいです。なので、私はその代わりに、ストーリーと類推を使って原理と例を示すようにしています。それで、開発者自身が原則を現実のシステムに応用することで経験を積むようにしています。

InfoQ: この本では観察のサイクルについて書いていますね。この点について説明してください。

Kanat-Alexander: プログラムを書くには(ひょっとしたら、あらゆることをするには)、観察をして、意思決定をして、その決定に基づいて行動をします。プログラミングについて、この点を指摘するのは、ソフトウェアエンジニアのツールの扱い方と関連があるからです。コードを書き、そのコードについて何か(コードの出力結果、コードそのもの、テストの結果など)を読み取り、その情報に基づいて意思決定をします。最後に、決定を基づいて行動を起こします。コードを変更する、新しいテストを書くなどの行動です。小さく行われる(数行のコードを書いて、そのコードを観察し、新しいコードを書くという決定をして、新しいコードを書く)こともあれば、システム全体で行われることもあります(問題を観察し、そのプログラムを書いて問題を直そうと決定し、プログラムを書く)。

このことについてはたくさん話せることがあり、それがこの本の内容です。

InfoQ: この観察のサイクルを小さく保つ方法としてのテスト駆動開発についてのあなたの考えを教えてください。

Kanat-Alexander: まったく問題ない方法だと思います。しかし、唯一の方法ではありません。TDDの支持者の中には混乱している人もいます。観察できることはたくさんあり、観察や決定、行動を獲得するために選択できる行動もたくさんあります。TDDがうまくいく場合もありますし、他の方法がうまくいく場合もあります。私たちは正しいフィードバックを行動を起こした後に素早く手に入れることを望んでいます。TDDがうまくいくいき、TDDを実践することによって長い間観察もせずに何もしない状態にならないとしたら、私は賛成します。

InfoQ: 生産性をあげるために、すべてのプログラマーにおすすめできるプロダクトはありますか。

Kanat-Alexander: 難しいですね。使っている言語に依存しますし、プログラミングの方法にもよりけりです。使っておくべきツールのタイプがある、と言う方がいいかもしれません。やりたいことを素早くできる良いエディタ、IDEは欲しいでしょう。優れたビルドツール(bazelのような)を持つ必要があります。テストフレームワークやテストランナーも必要でしょう。特にチームには、Jenkinsのような継続的統合システムが必要です。

また、必要なツールの中には既製の良いバージョンがないものもあります。例えば、リリースプロセスを管理するシステムがあったら便利です。ほとんどの企業は、このようなツールを自分たちで作っています。汎用的なツールがリリースされ得るマーケットの空白があるのは間違いありません。

もちろん、linterも欲しいですね。愚かな間違いやスタイルの問題をコミット前に教えてくれます。

大きなプロジェクトでは、自動リファクタリングツールを使うのもいいでしょう。IDEは、大抵の場合、ほとんどの一般的なニーズを満たしてくれます。たとえば、クラスやメソッドのリネーム、呼び出し元をすべて新しい名前に変更する機能です。

他にも便利なツールはたくさんありますが、その一部分しかリストにはなっていません。

InfoQ: エレガントな小さなシステムが作り込まれた、肥大化したシステムに勝ってしまうという、第2システム効果を避ける方法を教えてください。

Kanat-Alexander: システムのリライトはやめましょう。ほとんどの場合、リライトする必要はありません。大抵の場合は、リファクタリングできるのです。最初の本(Code Simplicity)の、リファクタリングとリライトのどちらを選択するのかについてのチェックリストを見てください。

InfoQ: あなたは"Code simplicity: the fundamentals of software"という本も書きました。この新しい本と前の本、どちらから読み始めるのがおすすめですか。

Kanat-Alexander: 何を探しているかによります。最初の本はソフトウェア開発の基本的な原則について詳しく書いています。なぜ、シンプルさが大事なのか、ということを一番の基礎から説明しています。

新しい本、Understanding Softwareは、より高いレベルで書かれた記事を構成したもので、Code Simplicityに書いた原則を私自身が実践した経験を元に書いています。Code SimplicityよりもUnderstanding Softwareの方が実践的だと感じる人もいるでしょう。

Understanding Softwareから読み、気に入ったらCode Simplicityも読んでみてください。

InfoQ: プログラマの生産性を計測することについてアドバイスをしていますね。アーキテクトやマネージャのようなソフトウェア開発チームにいるプログラマ以外の人には、あなたはどのようなメトリクスを使って計測しているのでしょうか。

Kanat-Alexander: それらの人々がどのようなものを生み出しているかに関わっているのかによります。アーキテクトは新しいソフトウェアプロジェクトの計画をするだけなのか、それとも完成されたソフトウェアを作るのか。もしそうなら、プログラマの成果を計測するのと同じようにできます。ただし、1人の人としてではなく、アーキテクトが率いた技術チーム全体として計測します。

マネージャの場合も同様に何を生み出すのかを知る必要があります。チームによって異なるでしょう。内部の開発者向け生産性ツールを開発するチームのマネージャをするなら、ウェブベースの会計ソフトウェアを開発するチームのマネージャとは異なるメトリクスで成功を計測するでしょう。また、仕事の一部が採用やチームの成長に関わるものなら、そのような、人に関連するメトリクスも必要かもしれません。この点は私の専門ではありませんので、具体的なメトリクスを提示しません。言えるのは、生産性を知りたいなら生産を計測するということをしっかりやるといい、ということです。

InfoQ: あなたが出会った一番怖ろしいコードはどんなものでしたか。どのようなアプローチでリファクタリングしましたか。

Kanat-Alexander:最悪のコードベースについては正確に覚えています。ひとつはオープンソースでした。私は善人で開発者を侮辱したくないので、それがどれかはここでは言いません。もうひとつはクローズドソースな製品で、私がある企業で働いていたとき、その製品に関わりました。具体的に言うことはできませんが、このふたつに対するリファクタリングについては話すことができます。

最初に話したオープンソースの方は、まず、プログラム全体を理解しようとしました。ひとつのファイルにすべてが書かれていたので、私はコードを読んで、プログラムを大きな部分に分割することにしました。いくつかコメントを追加することで部分に分割し、ファイルの先頭にプログラムの流れについて簡単な説明を書きました。確か、これが私の最初のコミットだったと思います。それから、さらに調べて、理解でき、簡単に直せる部分的を見つけ、修正しました。このように進めていって、最終的には、かなり良いリファクタリングができました。

クローズドソースな製品の方は、Code Simplicityのチェックリストを確認しました。このプロジェクトは私が今までの中で唯一、リライトを行ったプロジェクトです。一度にひとつの変数だけを変更する実験ようなリライトです。外部向けのインターフェースはリライト前とまったく同じです(ただし、バグ修正や性能問題に対する対処は行いました)。驚くべきことに、リライトは好評でした。バグが少なく、性能も改善したからです。

InfoQ: ここ数年であなたが見たプログラミング生産性についての開発でもっとも興味深いものは何ですか。

Kanat-Alexander:私の考えでは、ここ数年で一番目立つ開発は、継続的テストランナーの登場です。ファイルを保存したタイミングでテストを再コンパイルしてリランしてくれるツールです。このツールは開発の文化を劇的に変えています。PythonやJavaScriptのようなインタプリタ言語でうまく使えるツールです。コンパイルがいらないからです。しかし、JavaやGoでも使えます。ファイルを保存してから継続的テストランナーが2秒で終わるなら、このツールは開発生産性ツールの聖杯と言えるでしょう。ファイルを保存したときに、ファイルを保存すれば、毎回、システム全体が正常化どうかを明確に知る(はっきりしたフィードバックとテストの失敗を簡単にデバッグできる状態で)ことができるのです。これがテストの文化にどのような変化を起こすでしょうか。システムの安定性はどうなるでしょうか。リファクタリングにもより自由を感じませんか。とにかく、チームの文化にも大きな影響を与えるでしょう。

著者について

 Max Kanat-Alexander氏はGoogleのCode Healthのテックリード。ブログはcodesimplicity.com。Understanding Software 、Code Simplicityの著者。Twitterアカウントは@mkanat。