機械猫の日記

2006-09-03 軽量からアジャイルへ

[]軽量からアジャイル

id:yamazaさんの日記

なぜ「軽量言語Lightweight Language)」というのか

という疑問が投げかけられていた。軽量という意味は何か、というような疑問だと思うんですが、ふーむ。

そういえば、同じような話をどこかで聞いたなぁ・・・あ、Agileか。笑


アジャイルも元々軽量プロセスと呼ばれていたけど、「軽量って何?」みたいな話になってアジャイルという言葉誕生したのだった。

であれば、今言語に対しても同じことが起きるんじゃないかなぁ。

つまり、軽量言語ではなくアジャイル言語(?)に。


では、アジャイルって何か?というと、これはアジャイル宣言で明文化されていて、そのおアジャイル宣言の価値を共有するものがアジャイルなのだ(ですよね?汗)

では、今一度ここでアジャイル宣言を振り返ってみる。


 プロセスやツールよりも、個人と相互作用

 包括的なドキュメントよりも、動作するソフトウェア

 契約交渉よりも、ユーザとの協調

 計画に従うよりも、変化に対応


元々のアジャイルとは、開発手法というか、チームとしてのあり方を示したものなんやけど、じゃぁここでそれを言語に読み替えてみればどうなるかな。


プロセスやツールよりも、個人と相互作用

これは本来、言語そのものが重要なのではなく、それを使う人が大事なのだというこ。いきなり言語を否定してしまっているように見えるかもしれないけど、そうじゃなくて、言語側に読み替えればこれは、変な言語仕様を意識しなくちゃいけなかったり、やたらと使いにくいものになっていたりするのはツールに依ってしまうのは良くないということ。


つまり言語人間に優しくなくてはいけないっということだと思う。


また、優しい言語であれば可読性も高くしやすく、他人との相互作用を促進してくれるだろう。また言語と人との相互作用というのも重要


何をもって優しいというのかは難しいけど。。



包括的なドキュメントよりも、動作するソフトウェア

これは、すぐに陳腐化してしまって信頼性も低いドキュメント(しかも作成するコスト馬鹿にならない)に価値を置くよりも、実際のリアルソフトウェアのほうに価値を見出しましょうという話。(決してドキュメントいらないという話ではない)

これは言語側から見れば2点あると思う。

一つは「言語自然と可読性の高い記述になるように設計されていなくてはいけない」ということ。

もう一つは「ソースを読んだときにぱっと想像する処理内容と実際の処理内容に差があってはいけない」ということ。(これもある意味可読性の問題か)


そもそもなんでドキュメントが必要なのかというと、コードは読むには具体的すぎるし、さらには読むにはスキルがいる。というのと、角谷さんが「コードにはHowを、Testにはwhatを、コメントにはWhyを書く」と、言われていたように、コードとは別視点のドキュメントが必要になるからだ。

この別視点のドキュメントというのは、ちょっと置いておくとして、最初の「コードは読むには具体的すぎるし、さらには読むにはスキルがいる」というのは可読性が十分に高ければ、もしかしたら解決されるんじゃないかな?


十分に可読性が高い→全体を理解しやすい、あるいは処理内容が理解しやすい。また言語を知らなくても読める。


ということだと思えば、ある程度解決されているように見える。

ところでさっきちょっと置いた「別視点のドキュメント」についても、可読性の高い、良いコードはそこに意図(what/why)を反映させやすくもあるので少しは効果があるかもしれない。

つまり宣言的な記述ができる、あるいは宣言的な記述を促す言語であるほうが良いのだ。

とはいえ、完全にwhat/why記述できるわけではないし、やっぱり別視点のドキュメントというのは必要だろう。言語がどう進んでもドキュメント重要というのは変わらない。



契約交渉よりも、ユーザとの協調

これは言語開発者の間の契約(言語の文法、仕様)よりもユーザとどのように協調するかという点のほうが重要であるということ。

つまり変な文法や難解な仕様開発者を混乱させるよりは、素直で見通しのよい文法・仕様であるべきで、さらに開発者の思考を手助けして協調してくれなくてはいけないということ。やりたいことがパッと思いつくような言語のほうが重要だってこと。(ただ、言語に対する習熟というポイントもあるけど、まぁそれは今はおいておく)



計画に従うよりも、変化に対応

これも2つあるかなぁと思う。

アプリケーション変更が行いやす言語であること」と「言語側の仕様等の変更がしやすいこと」


アプリケーションの変更というのは、言語責任ではなくアプリ設計などの責任に思えるかもしれない。まぁそれは確かにそうなのだが、言語側としては、変更に強いアプリ設計になるような支援をするべきだと思う。

また、「言語側の仕様などの変更がしやすいこと」ってのは、例えば言語提供するライブラリがあったとしてそれが不十分だなぁっと感じたら簡単に拡張できるほうが良い、あるいは変な仕様だなぁっと思ったら、より素直な仕様と思えるような記述が可能にしやすいほうが良いなぁということ。(仕様等を拡張しても、既存アプリなどに影響を与えづらくしなくてはいけないという問題もある)



まとめ

以上の4つのことに価値を置いている言語アジャイルと言えるかなぁと思う。言語側に強引に焼きなおしてみると


言語は人に優しくあるべきだ

言語は可読性が高い記述を促さなくてはいけない

言語仕様は見通しがよくなくてはいけない

言語は変更に強くなくてはいけない

(これらの価値は互いに関連しあっている)


僕がRuby好きだからかもしれないけど、Rubyは上記の4つの価値にコミットしていると思う。笑

他の言語はどうでしょうか?


(追記)

というかあれですかね、システムは人が作る、ツールや言語は人が使う・コードは人が書き・人が読むという事実に価値を置くことがもっともアジャイルなんでしょうかね。

kakutanikakutani 2006/09/03 17:30 Groovyは”Agile Language”だと2004年にプレゼンしました(遠い目)。どんなにコードで頑張っても、「実装しなかった」という判断はコードに残すのが難しいと思うんですけど、どうですか?

kikainekokikaineko 2006/09/03 17:36 >どんなにコードで頑張っても、「実装しなかった」という判断はコードに残すのが難しいと思うんですけど、どうですか?
難しいと思います。
というか、そこまでコードで書く必要があるかという疑問もあるので、そういうのはすっきりとドキュメント(コメント)に記述するのが良いかと思います。
上記の日記でも、そのような視点(why:なぜ実装しなかったか)を「とりあえず置いて」議論しています。(^^;
(あるていどのwhy/whatなら表現できるとは思います。how/what/whyって明確な境界があるわけではなく、互いに入れ子になった構造だと思うので)

kakutanikakutani 2006/09/04 02:32 あ、そうか。文脈をちゃんと読めてませんでしたね、私。すんません。

kikainekokikaineko 2006/09/04 02:51 いえ、混乱させてしまいすいません。ちょっと追記しました。
また、遅れましたが、先日はうちの相方がご迷惑をおかけしてしまいすいません

トラックバック - http://d.hatena.ne.jp/kikaineko/20060903