＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
なぜ「グローバル変数」を使っては、いけないのですか？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-04-16 12:46
と、はにまる様の高尚なご発言の後に書くのとても恥ずかしいですが、 皆様の様な上級者のご意見が多いので、初心者の部類に入る私の意見も述べさせて下さい。 私は「グローバル変数を使っては行けない！」と、いわれる立場ですね。 本題とはかなりずれてしまいますが、例え話です。 麻雀初心者は良く｢不用意に鳴くと上がれなくなるから、鳴いちゃ駄目！｣ と言われます。 鳴くとどういう利点があるのか、弊害があるのかも分からずに ただ見た目的に「綺麗にそろった！」だけで上がるとチョンボだったりします。 プログラムも同じ事が言えそうです。 ビルドは通りますが、いざ動かしてみると変な動きをする・・・ 原因はグローバル変数だったり・・・ 結局、利点と弊害さえ理解できていればグローバル変数を使用しても良いのではないか？ と思います。 鳴いた方が点数が高く、そして早く上がれるかもしれません。 どういうものか理解できていれば。 私はＰＧ・ＳＥとしては未熟ですが、早く「利点と弊害」を熟知できるよう様 初心者も頑張っています。鳴いても上がれるように・・・ 麻雀をご存知ない方御免なさい。そして主スレ脱線失礼しました！ | ||||||||
|
投稿日時: 2004-04-16 12:48
管理的な見方でもうひとつあります。
それは、「グローバル変数は使うな」は「グローバル変数は、勝手に作るな」ということ でもありますね。 つまりSEまたはリーダー格のプログラマーが、メンバーに対して言う場合です。 グローバル変数というのはスコープも全体に渡っているので、単に１クラス、１関数、 １モジュールのプログラミングを担当するプログラマーが決めることではなく、 全体を見渡せる立場の人が、「これはグローバルに定義する」という情報をメンバー に発信するものですから。 | ||||||||
|
投稿日時: 2004-04-16 13:04
> 私は、構造体の定義はグローバル、変数化の時にローカル定義の手法が多いです。
あぁ、なるほど。確かに構造体変数はローカルで宣言する事が多いですな。 よく考えるとCのコーディングでは自分でもそうしてます。ところで、構造体へのポインタを使うか、 構造体の実体を指定するか、いまだにどのケースでどちらを使うかの基準が明確ではありません。 自分では、どちらでも処理できる事が多いのですが、どういう場合に構造体へのポインタとして宣言 し、どういう場合に実体で宣言するのかいまいち釈然としません。 | ||||||||
|
投稿日時: 2004-04-16 13:18
例え話って、問題が抽象的に捉える事が出来、解り易くて良いですね！ 考えもなく鳴き撒くって、ふと気がつけば、上がり牌を捨てており、 手を崩さないと行けないが、手を崩すと役無しになり、立ち往生した事があります。 相当なアホです。 
その時、周囲のヤツに「お前はもう死んでいる」と言われました。バレバレ 私は、ＶＢで規模が大きく、パートナーさんの多い物件に携わる事が多い為、 「グローバル変数を使うな！」と組織的に取決める事が出来ないです。 その時、どこまでがセーフか？というのが、サクサクと取決める事が出来ると カッコイイな〜と思うのですが、その為には「利点と弊害の理解」が必要なんですよね。 レンジを幅広く持ち、組織状況に合わせた手段を用いる事が出来る、 カッチョイイ技術者／管理者になれるといいなと妄想しています。 実は、グローバル変数のみでプログラムを作成するには？と ちょっと考えてみました 
結果、変数をスコープ単位に構造体化して 構造体にサブルーチン名をつける位しか思いつきませんでしたが．．． ^^;
私は、「誤字脱字王」と「脱線王」を自負しています！ あと、他の人の発言を元に発言している為、 じゃんけんで後出しているのと一緒で卑怯なヤツです。 
| ||||||||
|
投稿日時: 2004-04-16 14:20
有難う御座います。お恥ずかしい^^； 内心、荒らし扱いで放置されるのでは？と、ドキドキでしたが 色々いじって頂けて光栄です。
私は、そのパートナーとし参入するほうが極めて多いです。 組織的に取り決めが出来ないというのは十分承知していますので 個人的には今のところ「グローバル厳禁」で携わって居ります。 もし、どうしてもの場合はプロジェクトリーダー等に確認・相談をするという スタンスですね。もっとも滅多に必要に迫られる事はありませんが^^ そういうのも含めて、「グローバル変数使用の可不可」は開発者個々の 意識の問題でもあると思います。 「使うな！」といっても使う人は使いますし 「使って良い」と明言されても使わない人は使いません。 開発者自身が自分の力量・責任と相談したうえ、かつ禁則を破る形であるなら 開発責任者に正しく使用目的と意義と問題点を提示して 使用していかなければならないのではないでしょうか？と 私は思っております。 私のような初心者は「なぜグローバル変数を使ってはいけないのですか？」 の質問をする前に開発に対する意識改革が先のようです。。。 | ||||||||
|
投稿日時: 2004-04-16 16:23
え〜、何時も通り脱線します。
「そうだよね、うん、うん」と読み流し、ちょっと間を空けてから気が付きました。 それは、「プログラム記述基準書」の運営方法を決めていないし、周辺管理をしていない。 
もともと、「プログラム記述基準書」では無く「プログラミング手引書」にして 「グローバル変数を使うな」では無く、「グローバル変数の弊害に遭わない様に」 の知識集を作る様にしないと、いけないですね．．． 簡単に言っていますが、実際に実行すると大変かな？（大変だろうな。 ）
でも、これをやるには、先に完全制限（「グローバル変数は使うな」）を掛けて、 「出来ない」「無理」などの要望を現場から貰った方が早そうですね．．． これまた、実際に実行すると大変かな？ | ||||||||
|
投稿日時: 2004-04-16 17:31
るぱんです。
みゅうさんの「言われる立場」を聞いて思いました。 あ、今回は個人的な独り言（？）です。（笑） 僕は逆にそれを言う立場なんですね。 で、次のように考えています。 「お前が使ってるくせに偉そうな事抜かしやがって・・・。」 普段言われてる人からしたらこう言いたくなりませんかね？ って。 僕だったら間違いなく言います。 んじゃ、いつも僕が言ってる事は自分に過剰に適用しておけば そう言う理不尽だと思われる事も少ないんですよね。 そのかわり、「あなたみたいには出来ないんです。」 とすねられる恐れ大ですが。（汗） だから、使わせないし、使わないんです。 使うにしてもめんどくさくしておけば申し開きぐらいはできますからね。 どちらかと言うとすねられてる方が、 御機嫌の取り様もあるので後処理も楽ですし、 一緒にお酒飲んでしまえば仲直りできます。 後々楽をする為に頑張る。めんどくさいことは嫌い。手遅れも嫌い。 誰になんと言われようともこれだけは譲れないんだな・・・。 ふとそう考えてしまいました。（笑） | ||||||||
|
投稿日時: 2004-04-16 18:41
"先に完全制限"は何となく、はにまるさんには向いていないのでは？（想像） どちらかというと、雰囲気の良いチーム作りの方が向いているような（さらに想像） 信頼して仕事を任せられる後輩をお持ちのようですので、そういう人に管理の一部を任せるなどしてなるべく多くの人で運営しているイメージを作った方がいいんじゃないですか？（これも想像） 具体的には共通関数と同じで、最初にある程度洗い出しておいて「この変数はこう使ってください」。例えば、 ・設定ファイルから読み込む項目は最初にこの変数に入れておくので各自参照のみ ・ログイン画面で取得した担当者の権限情報はこの変数に入れておくので各自参照のみ ・各フォームのロードイベントでこの変数に各自の機能ＩＤを入れてください ．．．などなど （言うまでもないですがこれは例です） で、「グローバル変数の管理は○○に任せるので、追加したい時や改善案がある時は相談してください」。 以上で完了でいいように思います。 実際問題追加はでません。余程のことがない限り。 しかもグローバル変数等は当然専用のBASファイルに入ることになりますので、管理者以外は勝手に追加できません。 残ったグローバル変数は資料も残った統制がとれたもののみ。これでグローバル変数で苦しんだとしても、それはグローバル変数のせいでなく単なるバグです。 （いつもの余談） 「出来ない」「無理」は現場から言わせない方がいいと思います。 言ってもらうなら「大丈夫」「任せてください」でしょうか。 ※今回の書き込みは全て "余計なお世話" ですみません。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.