2014年2月8日土曜日

技術は、ひとに着く。

技術は、人に着く。それは、他人へ伝えるのが難しい。

論理的に表現したり説明したりできないもの。論理的じゃないから理解できない。

理解できた気になっても行動に結びつかない。

どこかでこの話を聞いて、自分なりに補足して、納得しているだけです。

でも、真理かどうかは、私にはわかりません。

他人が書いたコードは、できれば読みたくない。

他人が書いたコードは、できれば読みたくないという話。

もちろん私は知っています。プログラミングの経験が浅い新人とかは、

他人が書いたコードを読むのは、良いことです。

他人が書いたコードを読むことで、良いコードと悪いコードという概念が

作られます。それは、自分にとって、どうかと言う意味です。

ひとは、他人が書いたコードを読み、その中から良いコードは、真似。

悪いコードは、真似ずに、自分のコードに対する価値観を構築してゆきます。

そういう意味で、他人が書いたコードを読むことで、プログラミングの

スキルが向上すると思います。

でも、ある程度、そのような学習を積み重ねてきて(そのような学習は、常に

必要ですが。。。。)上達してくると、良く理解できないコードは、

読みたくなくなります。読んで、意味が分からないコードは、読んでもしょうがない。

となります。もちろん、バグとかで、そのコードが読みづらくても直さなければいけない

ときは、読みますが、できれば、読みたくない。

コードを読まないということは、それだけ生産性が高まります。

だからコードを読まないこともいいことなのです。うまくいっている証拠です。

どっちなんだと、言うかもしれませんが、他人の書いたコードは、できれば読みたくない。

でも、読まざるおえないときのために、読みやすいコードを書きたいですね。

システム開発における探索的と目的的?


最近思ったこと。

システム開発をしていると探索的に進めている場合と目的的に進めている場合があるなぁーと。

探索的とは?
目標を決めずに(大体は決まっているけど、細かくは、決めない)で、システム開発を進めること。

目的的とは?
目標を決めて、それに向かってシステム開発を進めること。

テストでも探索的テストとか言いますよねー

そこから取ったのですけど。

アジャイルとかは、「探索的システム開発」とも言えるのかなーとか。

私は、昨年、3月から関わっているプロジェクトは、探索的システム開発みたいな感じを

イメージしています。

仕様書は、書かない。テストをしながら、仕様を決めて行く感じ。

そんなの普通じゃないとか、そんなのうまくいくわけないとか、いろいろ言われます。

なんで、そんな手法をとっているかと言えば、アジャイルの『動くソフトウェアを重視する(価値置く)』

という思想に共感したからです。

これのいいところは、顧客もなにを求めているか、動くソフトウェアを見ながらあーだこーだ言って

要求を決められること。そのためには、『設計→実装→テスト』のサイクルが早くなければ

いけない。でも、これを早くするのも難しく、そこはうまくいかなかったなと反省しています。

来週の金曜日で一次納品。あと少しです。