Entry

グローバル変数の使用とかプログラミングスキルとか

2008年11月01日

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント - 分裂勘違い君劇場」を読ませてもらって,なんだかなぁと思ってたんですけれど,ちとメモがてら書いておきます。

また、stdin/stdoutやRubyのprintなどは、言語仕様に近い組み込みのシステム変数やメソッドなので、別格としてグローバルにアクセスできるだけだ、と単純に思いこんでいる人もときどきいるが、それは違う。

デフォルトの言語仕様の上に、自分が開発しようとしているアプリケーションのドメインに特化した言語仕様を載せて創り出した「拡張言語仕様」の上でプログラムを書くと生産性が大きく向上する。プログラミングの上級者になると、自然とそういうプログラミングスタイルになる人がけっこういる。

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント - 分裂勘違い君劇場

あたしゃ普段,「スコープ広げて拡張言語仕様」とか,「共通ルーチン化しないことも花」とかについて,あまり頓着してなくて(それもいかんとは思うんですが),便利だったらやりましょうねくらいの感覚だったります。でも,スコープを広げて便利だったことは,あまりない。

例えば,スコープを広げる場合でいうと,名前がぶつかることを心配するってのももちろんあるんですけれど,変更した時の影響を拾う工数を無視できなくなってきます。結局,変更しても影響が少ないようにグローバル変数を規定すると,本当に基本的な機能を持ったオブジェクトしか定義できなくなる。

また,上とは裏腹に,グローバルな変数は多方面から呼ばれるようになることから,無意味に多機能になりがち,という弊害もあります。新機能を追加するに当たって,このクラスにほげほげの機能を追加しましょう,みたいなことが繰り返されることがあるけれど,これを繰り返していくと,原則や例外の扱われ方が複雑になって,結局何がやりたかったオブジェクトだったか分からなくなることがある。原則はほげほげの機能を提供するけれど,引数オプションで例外のへろへろも提供できる,しかし,新機能との兼ね合いでこの例外機能にもふがふがな例外機能があります……みたいな。プログラムルーチンじゃないけれど,ls(1) なんて,その典型ですしね。こゆ場合,グローバルなスコープにオブジェクトを用意するにしても,本当に基本的な機能しか用意しておかないようにして,ローカルでコンポジットな関係を作るか,継承を使える言語なら継承してローカルに拡張していく方が効率的だったりします。

ここら辺は,morioX さんも書かれています。

例えば、「グローバル変数を使うな」と一般に言われるのは、グローバル変数に絡む修正が、モジュール内で閉じず、プログラム全範囲に影響を及ぼすために、オープン・クローズド原則を破ってしまうからです。それは、リグレッションテストの手間が増したり、それでも見つからないバグを埋め込んだりしてしまう可能性を高める事に繋がってしまいます。

本質はたぶんそんなに複雑な事じゃなくて - morioXのもくもく日記

特に,このサイトで度々ぶーたれてるような,要件がグズグズなプロジェクトなんかでは,スコープを広げて責任の所在を稀釈化するのは,根本的な設計見直しの原因にもなるわけで,危険ですらある。「要件定義書には『月次の売上集計を参照する』としか書いてないんですけれど,実はこの集計,3種類あるんですよー」とか,後になって分かるような怖い話が普通にあるプロジェクトでは,「売上集計オブジェクト」が頻繁にアクセスされるとしても,決してスコープを広げてはいけない。まぁ,こゆ案件では,ドメイン周りの「拡張言語仕様」なるもんを策定することが,そもそも不可能だったりするわけですが。

んなもんで,いずれにしても,基本は「スコープ狭め」が安全牌なんじゃないかと思います。スコープを広げて汎用化できる機能ってのは,例えば人事情報(例:人事コードを引数にして「部長」とか表示するだけの機能)のように,安定していて間違いが少ない機能に限られるじゃないかと思います。

一方で,弾さんのような考え方もあるんですけれど,こちらは,システム開発というよりは,純粋に個人的なプログラミングの話なんだと思います。つか,論点ずれてる気が。

まず、この台詞はプロ2グラマーとしては0点。

なぜなら、プログラムが正しいかどうかを決めるのは、使う人々だから。

この中には、自分自身も含まれる。一行野郎からテストスクリプトまで、おそらくプログラムのほとんどは、自分自身のために書かれる。こういうプログラムまで「スコープがどうの」だの「言語がこうの」などというのはまさに none of your business。

(snip)

しつこいほどくりかえす。ユーザー視点において、 What to Code に比べたら、 How to Code などブロックをendで閉じるか}で閉じるかほどの意味しかないことを。

404 Blog Not Found:そろそろ3つのポイントについて「弾言」しとくか

保守性や拡張性の高いコードを考える上で,ユーザはあまり関係ないと思う。ユーザからすれば,できたもんを外から眺めてるだけなんだから,中身がスパゲッティだろうがオブジェクトうんたらだろうが関係ない,というのはその通りなんですが。その意味で言うと,引用本文の最後の話も,若干論点がずれている。

プログラミング言語のスキルというのは、価値あるスキルのうちの一つにすぎないどころか、それほど優先順位の高いスキルではない。実際には、サーバ設定、ネットワーク、データベース、パフォーマンス設計、セキュリティ設計に関するスキルは、プログラミング言語の知識に負けず劣らず重要だ。プログラミング言語を極めることにこだわりすぎるあまり、それらシステム開発全体のスキルのバランスを欠くと、独りよがりで視野狭窄的なシステム設計に陥りがちだ。

中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな3つポイント - 分裂勘違い君劇場

スキルバランスを考えることは重要だと思います。けど,一方でプログラミングスキルは,何においてもこの業界の人が身につけなければいけないスキルなんだと思います。システム管理や上流の SIer さんなんかと話すと,プログラミングの話をしているところで「でもプログラミングってそれほど重要なファクターじゃないんだよねー……云々」みたいなちゃぶ台返しを食らうことがあるんですけど,「なら話振るなよ」とか思うことがある……。プログラミングできない人に限って言うから始末が悪い。これもスキルバランスを欠いている一例です。

もともと業務アプリってのは,プログラミングのスキルが低くても組める言語なりフレームワークなりを利用するのが普通なわけで,プログラミングが重要なファクターじゃないってのは当たり前の話だったりします。それは,大抵の基幹プロジェクトが要件レベルや外部設計・キャパプラでコケてることからも分かる。プログラミング重要じゃないとか言うなら,頼むからコケんなよ(要件がコケると詳細設計者やプログラマもとばっちりを食らって残業する羽目になる)。

また,プログラミングが「それほど優先順位の高いスキルではない」というのは,プログラミングを身に付ける必要がないことではない,ということにも注意する必要があります。開発工程全体の中で,製造工程=プログラミングが重要な地位を占めていないとしても,他の工程は,プログラミングできる人が作業することが暗黙の前提になっています(まぁ,うちの場合ですが)。ろくにプログラミングを経験していない設計者は,トンデモな設計書を書く危険が高いし,口だけでしのいできたプログラマ崩れが提案する「ソリューション」なるもんは,夢物語にすぎません。

ある意味,この業界でプログラミングスキルってのは,基礎体力なわけで,製造工程以外に関わる場合であっても,何かしらの形で必要になるスキルだったりします(営業にすらある程度は必要だと思う)。んでもって,優秀とされるかどうかは,目的に対して適切なやり方で,プログラミングスキルを活かしているか,ということなんじゃないだろうか。引用本文では,ケースバイケースが多用されるけれども,これはまさにその通りで,プログラミングスキルでもって何を実現したいのかによって,理想とするプログラム像もプログラマ像も変わってくるんだと思います。つことで,グローバル変数の使用もケースバイケースということで……。

でも,グローバル変数はやっぱり積極的には使わないなぁ……。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN