「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」?

ちゅーん @its_out_of_tune

きょん氏と山本せんせーの会話、きっと誰かがトゥギャってくれる。(他力本願)

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

僕が不勉強な部分はあるのだけど、「静的型付け関数型プログラミングだとOOよりもTDD(BDD)がしやすい(もしくはいらない)」とかたまにいう人がいるんだけど、その人がまともにTDD/BDDの説明しているの聞いたことがないので、まるで参考にならない意見ばかりでつらいです。

山本和彦 @kazu_yamamoto

.@kyon_mm 関数の型注釈を書く文化のある言語では、それが赤、本体の最低限の定義が緑で、そのあとリファクタリング、これをエディタ/IDE上でコンパイラからのフィードバックを受けながら繰り返す感じです。テストの専門家からすれば、オモチャかもしれませんが。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

静的型付き関数型のコンパイラからのフィードバックは、いわゆるOO言語のコンパイラメッセージとはフィードバックとしての質がだいぶ違う感じがするので、そのあたりが相互理解の壁になっているかも。同時に、工夫したらすごく面白そうな領域。 @kazu_yamamoto @kyon_mm

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto ありがとうございます。山本さんのご意見だと、静的型付け関数型だとOOよりもプログラマがテストしなくても設計を実装に落とせているかどうかを簡単に判断できるという意味だと思いました。これ以外に何かあったりするでしょうか？（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto というのも、先の部分だけではTDDの小さい部分でしかないからです。TDD/BDDとは分析/設計のフレームワークであり、その手段として実行可能なテストを使うことによって、実行,繰り返し可能な設計文書にしています。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto それらの側面に関して比較することがTDD/BDDにおいて重要な部分だと私は思っています。特に最初の側面は「書かないと自分のコードが信頼できない」がどの程度か？であり、分析/設計をどのように駆動するかとは少し趣が異なると思っています。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto 書かなくていいテストが増えることは正しい姿だと思っていますし「テストより先にコンパイルで検知されるものはREDとみなす」というのは非常に正しいことで、それはJavaのTDDでもあることです。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto その範囲が静的型付け関数型プログラミングの場合は非常に範囲が広範であることは想像に難くないです。（特に）BDDは「対象はどのようなものであるか」を説明することが、対象の責務を明確化、設計をよりよくするという概念です。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto これを実際にはテストコードに対象のメソッド呼び出しをいくつか書くことで定義しています。例えばファイルクラスであれば「パスを渡して、書き込む文字を渡して、保存をする」と書くことでファイルクラスがどのようなものかわかります。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto 先のは非常に簡単な例ですが、私が思うに端的に言い換えれば「ある要求を実現するにはこのように使えればいいはずだ」とか「このモジュールはこういった振る舞いまでが責務の範囲だ」とかだと思うのです。（続く

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@tomooda @kazu_yamamoto そういった意味で、静的型付け関数型プログラミングではどのように設計を明示化していてそれがひいてはTDD/BDDにおいてどのように作用しているのか？に興味があります。長々と失礼いたしました。

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda 静的型付け関数型という大きなくくりで言ってしまうと、その程度でしかないと思います。ただし、型レベルの検査は、証明であって、テスト以上の質があります。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

http://t.co/rpue0dUTcL のような仕組みを使った実際のプラクティスがどうなるのかには私も興味あります。 @kyon_mm @kazu_yamamoto

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda フレームワークは、言語によって異なるので、一般的には言えないと思います。ご存知だと思いますが、Haskell では doctest/hspec/quickcheck が統合されています。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@katzchang たしかに＞＜（TDDBC TokyoでScalaプログラマの方が言っていたのですが、書いたほうがよかったですね。今からでも書くべきか。（でも、アカウントを覚えていないので残念すぎる。

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda GHC 7.8 からは、doctest に prop> キーワードを使って性質が記述でき、quickcheck で検証できます。（これは、値レベルのテストです。)

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda Java だと、型で設計できないと思いますし、厳密な意味での(双方向の)型推論はありませんから、コンパイラが教えてくれるのは、文法間違いであり、型レベルの証明ではありませんよね。

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda もう一度言いますが、そこはフレームワークの部分で、言語特有の話ですので、一般化できないと思います。関数型がTDDに向いているという人の多くは、そこまで考えてないでしょう。赤、緑、リファクタリングサイクルを知っているかも怪しいです。

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda 低レベルな部分に戻りますが、Haskell では、純粋関数は全域関数にすべき、エラーを返す場合は直和を使えという教えがあり、副作用(IO)は型レベルで分離されているという特徴があります。これは設計に大きな影響を与えます。

山本和彦 @kazu_yamamoto

.@kyon_mm @tomooda それから、難しい部分は、型注釈で設計しておくというのがあり、型が実装を導いてくれるという感覚があります。その辺りは、命令型言語とは感覚が違うと思います。

極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda

そのあたり、「型が設計で、そこから実装を導く」という言い回しでは、「UMLでクラス間の関係を設計して、そこから実装を導く」こととの間にある質的な違いが、表現しきれてない感じがします。 @kazu_yamamoto @kyon_mm

山本和彦 @kazu_yamamoto

.@tomooda @kyon_mm そうだろうね。でも、僕は大きな事例を扱ったこともないし、UMLを書いたこともないので、表現することはできないです。orz