デカルトさんにプログラミングを学ぶ。(メモ)

デカルトさんの、方法序説をOutput-Driven Learningする。

1.明証

わたしが明証的に真であると認めるものでなければ、どんなことも真として受け入れないことだった。言い換えれば、注意深く速断と偏見を避けること、そして疑いをさしはさむ余裕のまったくないほど明晰かつ判明に精神に現れるもの以外は、何もわたしの判断のなかに含めないこと。

    • テストしていない、テストケースがないプログラムはどんなものも自身の成果物に取り入れないこと。
    • 顧客が明示的に要求している用件のみを満たそうとすること。憶測で実装しない。

良いと思って作ってみたけど、顧客にとって別にどうでもよいものであり、それに対する時間的対価は払いたくないよということは多々あると思う。
ただ、個人的なプロジェクトに関して言うならば、憶測を明証するために実装することにかける時間は意外とかけがえのないものになるのかもしれない。「それ」が要らない理由を知るきっかけができるかもしれないし、いらないという一つの明証になる。
憶測から実証に変われば、必要な明証の一つとして顧客への要望にこたえることができるかもしれない。

2.分析

わたしが検討する難問の一つ一つをできるだけ多くの、しかも問題をより解くために必要なだけの小部分に分割すること

    • 顧客の要求や、仕様はできるだけ細かく分割すること。
    • 分割できないところまで分割すること。

3.総合

わたしの思考を順序にしたがって導くこと。そこでは、もっとも単純でもっとも認識しやすいものから始めて、少しずつ、階段を昇るようにして、もっとも複雑なものの認識にまで昇っていき、自然のままでは互いに順序がつかないものの間にさも順序を想定して進むこと。

    • まず動くものを作って、求めているものを認識する(モックアップ)
    • 小さく始めて大きく育てるオープンソースのように。

4.枚挙/吟味

すべての場合に、完全な枚挙と全体にわたる見直しをして、何も見落とさなかったと確信すること。

    • コードレビューすること。

あとがき

1.明証はプログラミングにとって重要だよなぁってすごく感銘を受けたので、これってプログラミングの理解に役立つのかなぁと思い、一通りざっと書いてみた。

リファクタリングとかがないのかなぁ。「わたしが」という言葉で始まるように、チームという概念は4つの規則にはないのので、一個人としてプログラムを制作する上での規則になるかもしれない。すくなくとも1.明証は大事だ。
それも、シンプルに明証できることが重要なんだと思う。