「ものもの」さんのブログをみていたら、２つ面白い記事がありました。
開発中のカーネルを毎日テストすべきというトーバルスの発言と、
テストの自動化、その最新事情 （＠ＩＴ）の、「テストの自動化」を「アジャイル」の中で考えようというアプローチ。
この２つの記事とも、最近の「リファクタリング」の流れの中の話でおこる、「頻繁にテストして、バグがあったり、不具合があったら、どんどん修正すればいいじゃん！」っていう、よく、若手の人が言う考え方と同じと、とらえられますよね。
（って、まさか、トーバルスさん自身も、そう思ってるのかなあ？？）
で、この考え方がまずいのは、汎用やってた人なんかが、よく言うとおもうけど、
１．バグを修正したことによる、新たなバグを含有する危険性（デグレード）
２．頻繁にテストを行うと、テストでバグや問題点をみつけようとしてしまう
→机上デバッグが減るため、バグが入りやすくなったり、仕様決めが甘くなる
３．そのうち、いつの間にか、インターフェース(＊)まで直してしまい
結果として、前のインターフェースをもとにして作ったソフトと、
あとのインターフェースを基につくったソフトの両方をリンクしてしまって、
動かない上に、仕様が混乱する。
（Javaのinterfaceの意味ではなく、関数、メソッドの引数などのこと。ポインタ渡し、動的リンクにしてると問題あり）
まあ、この辺の話で、Linuxのディストリの話(kondaraとそれ以外）とかあるんだけど、ここでは省略。
そんなことにくわえ、これは、若手の人にいっても、わかってもらえる話でないから言わないような話として、こんなところじゃないかしら。
４．プログラムは、全体を、ある程度の量、こなさないと分からない
（パターンなどが見えてこない）。
ある程度こなして、見えてきたら直すのと、
その場で、少しずつなおすのでは、全然レベルが違う。
なぜなら、量をこなして、ある程度パターンが見えたとき、
確実に、次元が上がっているわけで、
そこから前のプログラムをみると、
今のプログラムは、（恥ずかしいくらい）違って見える。
５.同じプログラムをいつまでも修正してしまって、もっと大事なプログラムが、手付かずになる可能性がある。
プログラムを修正していると、仕事している気になるから、そういう、やりやすいところからやって、肝心な、しかし大変な新しいプログラムの開発は手付かずなんていうことにもなりかねない。
じゃあ、どうするべきかというと、
・パフォーマンス低下を引き起こすようなコードはどういうものか
という情報の共有の周知徹底
ってことは、いわれそうだけど、
そもそも、周知徹底なんて、できるもんじゃないから、
「テストの自動化」を「アジャイル」の中で考えようというアプローチがでてくるわけだとおもう。
つまり、トーバルスさんが指摘するように、全体が出来上がってからパフォーマンステストをしたんではおそい。
そこで、自分の今回開発した一部分が出来たら、その修正前と後で、パフォーマンスをチェックする（アジャイルに）。
しかし、そのパフォーマンスツールなんてないから、その部分はつくんないといけないけど、そんなもんは、お手軽につくっちゃいばいい、ごたいそうなもん（伽藍（がらん：Cathedral）と表現してる）でなれば、ノリノリでつくれるよね、ってはなし。
（ちなみに、この記事は、もっと先の話をしていて、そういうパフォーマンステストをやっているところを、ツールやさんが見れば、もっと有意義なテストツールを作れるよねっていう話で、この辺は最近、新人がドキュメント、テストをやっているところを見て、VBAなんかつかって、テストツールをつくるノリみたいな話してる）
そうやって考えると、トーバルスさんの考え方も、「テストの自動化、その最新事情」からみれば、古いわけで（全体を毎日テストする）、部分ごとに、必要な目的をテストする、そのためのツールをノリノリで作らなきゃいけないってことなんでしょうね。
でも、この考え方でも、上記（５）の、「大事なプログラムが、手付かずになる可能性がある」っていう問題は解決しない。
つまり、アジャイルで、すべてをテストすることが、本当に大切なのか？という問題がある。
そうすると、プロジェクトマネージャーさんとかは、
プロジェクトの優先順位に基づき、
適正な手順・管理下の元、
行わなければならない。
とかいうんだけど、そもそも、優先順位って、なんで付くの？
っていうことから考えないといけない。。。
たぶん、この優先順位っていうのは、全体最適から来るとすると、Linuxの場合は、
カーネルのシステムコールのインターフェース
glibcのインターフェース
：
（中略）
：
カーネルのパフォーマンス
とかなるわけで、特にglibc のバージョンが違うと。。。
とかって、書くと、長くなるんだけど、こんな話、おもしろいかなあ。。。？
たぶん、読んでる人、長くて寝てるよね(;_;)
ということで、クリック数が多かったら、このあとの話
Linuxのインターフェースとしては、なにが重要か？
を、「Linuxのディストリの話(kondaraとそれ以外）」
とあわせてとか、
Linuxのプロジェクトの問題点としての、
横ならびチェックの軽視からくるハッキングの問題
とか、
Linuxの翻訳の問題(poファイルを訳せばいいだけじゃない）
とか書きます。
クリック数が、すくなかったら、（みんな興味ないということで）別の話題に変えますね。ちなみに、ウィリアムのいたずらは、とっても少ないと思ってます。
あ、そうそう、「テストの自動化」の記事で、「優れたツール開発担当者は、ソリューションを短時間で準備できるよう、Java、Perl、あるいはPythonといった高級言語のプログラム手法に関する知識があるはずだ」ってあるけど、文中で出てきた、Excel VBAから、テストツールをアジャイルに作ってるなんていう話は・・・もっと興味ないよね。
今回の記事は、思ったより、しょーもない出来であった。
けど、せっかく書いたので、公開しておきます。
（意外と、ウケたりして ^^;)
開発中のカーネルを毎日テストすべきというトーバルスの発言と、
テストの自動化、その最新事情 （＠ＩＴ）の、「テストの自動化」を「アジャイル」の中で考えようというアプローチ。
この２つの記事とも、最近の「リファクタリング」の流れの中の話でおこる、「頻繁にテストして、バグがあったり、不具合があったら、どんどん修正すればいいじゃん！」っていう、よく、若手の人が言う考え方と同じと、とらえられますよね。
（って、まさか、トーバルスさん自身も、そう思ってるのかなあ？？）
で、この考え方がまずいのは、汎用やってた人なんかが、よく言うとおもうけど、
１．バグを修正したことによる、新たなバグを含有する危険性（デグレード）
２．頻繁にテストを行うと、テストでバグや問題点をみつけようとしてしまう
→机上デバッグが減るため、バグが入りやすくなったり、仕様決めが甘くなる
３．そのうち、いつの間にか、インターフェース(＊)まで直してしまい
結果として、前のインターフェースをもとにして作ったソフトと、
あとのインターフェースを基につくったソフトの両方をリンクしてしまって、
動かない上に、仕様が混乱する。
（Javaのinterfaceの意味ではなく、関数、メソッドの引数などのこと。ポインタ渡し、動的リンクにしてると問題あり）
まあ、この辺の話で、Linuxのディストリの話(kondaraとそれ以外）とかあるんだけど、ここでは省略。
そんなことにくわえ、これは、若手の人にいっても、わかってもらえる話でないから言わないような話として、こんなところじゃないかしら。
４．プログラムは、全体を、ある程度の量、こなさないと分からない
（パターンなどが見えてこない）。
ある程度こなして、見えてきたら直すのと、
その場で、少しずつなおすのでは、全然レベルが違う。
なぜなら、量をこなして、ある程度パターンが見えたとき、
確実に、次元が上がっているわけで、
そこから前のプログラムをみると、
今のプログラムは、（恥ずかしいくらい）違って見える。
５.同じプログラムをいつまでも修正してしまって、もっと大事なプログラムが、手付かずになる可能性がある。
プログラムを修正していると、仕事している気になるから、そういう、やりやすいところからやって、肝心な、しかし大変な新しいプログラムの開発は手付かずなんていうことにもなりかねない。
じゃあ、どうするべきかというと、
・パフォーマンス低下を引き起こすようなコードはどういうものか
という情報の共有の周知徹底
ってことは、いわれそうだけど、
そもそも、周知徹底なんて、できるもんじゃないから、
「テストの自動化」を「アジャイル」の中で考えようというアプローチがでてくるわけだとおもう。
つまり、トーバルスさんが指摘するように、全体が出来上がってからパフォーマンステストをしたんではおそい。
そこで、自分の今回開発した一部分が出来たら、その修正前と後で、パフォーマンスをチェックする（アジャイルに）。
しかし、そのパフォーマンスツールなんてないから、その部分はつくんないといけないけど、そんなもんは、お手軽につくっちゃいばいい、ごたいそうなもん（伽藍（がらん：Cathedral）と表現してる）でなれば、ノリノリでつくれるよね、ってはなし。
（ちなみに、この記事は、もっと先の話をしていて、そういうパフォーマンステストをやっているところを、ツールやさんが見れば、もっと有意義なテストツールを作れるよねっていう話で、この辺は最近、新人がドキュメント、テストをやっているところを見て、VBAなんかつかって、テストツールをつくるノリみたいな話してる）
そうやって考えると、トーバルスさんの考え方も、「テストの自動化、その最新事情」からみれば、古いわけで（全体を毎日テストする）、部分ごとに、必要な目的をテストする、そのためのツールをノリノリで作らなきゃいけないってことなんでしょうね。
でも、この考え方でも、上記（５）の、「大事なプログラムが、手付かずになる可能性がある」っていう問題は解決しない。
つまり、アジャイルで、すべてをテストすることが、本当に大切なのか？という問題がある。
そうすると、プロジェクトマネージャーさんとかは、
プロジェクトの優先順位に基づき、
適正な手順・管理下の元、
行わなければならない。
とかいうんだけど、そもそも、優先順位って、なんで付くの？
っていうことから考えないといけない。。。
たぶん、この優先順位っていうのは、全体最適から来るとすると、Linuxの場合は、
カーネルのシステムコールのインターフェース
glibcのインターフェース
：
（中略）
：
カーネルのパフォーマンス
とかなるわけで、特にglibc のバージョンが違うと。。。
とかって、書くと、長くなるんだけど、こんな話、おもしろいかなあ。。。？
たぶん、読んでる人、長くて寝てるよね(;_;)
ということで、クリック数が多かったら、このあとの話
Linuxのインターフェースとしては、なにが重要か？
を、「Linuxのディストリの話(kondaraとそれ以外）」
とあわせてとか、
Linuxのプロジェクトの問題点としての、
横ならびチェックの軽視からくるハッキングの問題
とか、
Linuxの翻訳の問題(poファイルを訳せばいいだけじゃない）
とか書きます。
クリック数が、すくなかったら、（みんな興味ないということで）別の話題に変えますね。ちなみに、ウィリアムのいたずらは、とっても少ないと思ってます。
あ、そうそう、「テストの自動化」の記事で、「優れたツール開発担当者は、ソリューションを短時間で準備できるよう、Java、Perl、あるいはPythonといった高級言語のプログラム手法に関する知識があるはずだ」ってあるけど、文中で出てきた、Excel VBAから、テストツールをアジャイルに作ってるなんていう話は・・・もっと興味ないよね。
今回の記事は、思ったより、しょーもない出来であった。
けど、せっかく書いたので、公開しておきます。
（意外と、ウケたりして ^^;)
アクセス
トータル
ランキング
