プログラミングに対するスタンスの差がモロに出てるね

思ったことをつらつらと。結構適当かも。批判して。

ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな転職日記
はてブでふろむださんが指摘しているように、アプリ屋さんの意見だなぁと思う。そして、この意見が決して間違っているわけではない。

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場 by ふろむだ
サービス屋さんの意見というかデータを扱うプログラムを書く人の意見だと思います。データを扱うので、プログラムはデータベースから目的のデータを取ってくるなり、取ってきたデータを如何に表示するかということが問題となり、この目的にプログラムを使う場合はデータの付属品でしかありません。Ruby On Rails最近触ったけれども、データベースから取ってくる使い方は１行で済んでしまう。こうなると、ますますこの使い方におけるプログラミングの重要性は低くなっていく。今後もこの流れは加速されると思われる。かける時間に見合わないような概念は消えていくだろう。
例えば、インターフェースさえ既定してしまえば、その内部でのスコープはあまり重視しなくてもよくなってくる。もちろんスコープを規定しないと、予期しない使われ方をしたり、いろんなところからアクセスを許可することになるのでスパゲッティコードになる可能性がある。スパゲッティコードを良くないけど、フレームワークによってコードを管理することで、コードがぐちゃぐちゃになるリスクはだいぶ減っていることを考えれば、スコープの既定は優先度が低いタスクになるだろう。　
あと大事なこととして、サービスはデータの見方が重要であると思っている。WWWのリンク構造を評価システムと見ることでWebページのランキングを構築した PageRankであったり、Webページのアクセスを集計してサイトの導線を解析したり、おもしろいサービスの中にはデータの見方を買えることで成功しているサービスが少なくない。見方を変えると言うことは、データの扱いかたを変えるということだ。もし開発中にデータの見方を変えることになれば、今まで使っていたコードは捨てるしかなくなる。一部のコードは再利用できるかもしれないが、部品としては役に立たなくなる。捨てる可能性のあるコードが多くなるのに、そこに注力しすぎるのはどうなのだろうか。

一方、アプリケーションを作る場合は事情が異なる。大規模なプログラミングを行うことが多くなるので、クラスやモジュールなどで部品単位にまとめないと何がなんだかわからなくなる。そして部品の数も多いので、それの使い方をドキュメント・スコープの両方で制御したほうが、誤りが少なくなる。グローバルで扱うほうが良いケースはそれほど登場しない。あってもログ出力とか、ヘルパー関数とかかなぁ。その場合、先のエントリで否定された3項目はほとんどの場合プラスにはたらくので、「3つの迷信」を守るのはいいんじゃないかなと思います。

ちなみに、俺はオブジェクト指向があまり好きではない。正確には自分が設計する範囲でオブジェクト指向があまり好きではない。共通部分が多くなることは良いことだと思うが、捨てる可能性の高い部分に意識の大部分を向けるのは無駄であると思っている。俺は、絶対この見方がは変わることはないと言える場合だけ共通化・抽象化を使う。そうでない場合は手続き的な書き方を好むようになった。サービスを作る場合、継承ってほとんど害悪にちかいでしょ。

プログラムをメインに据えるか、サイドに据えるかの立場の違いによりこの二つの意見の衝突が起こっているだと私は考えます。捨てられないコードと捨てても良いコードでは書き方が違うよね、というお話かなw