gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

includeの順番とか

んと…最近、とみにPHPの人様のコードを読んで思うのが…端的に一言で片付けると「思想が継承されてないんだか自分の思想が古いんだか」。
ちとうまく説明できる自信があまりないので、時間軸にそって順番に。


昔々。もう二桁ほども年をさかのぼったころに、いわゆるCOBOLとかをやっているような現場で身に着けた知識なのですが、もともとは。
それなりの規模のテストをするときに。
まぁいわゆる.soとか.dllとか、そのあたりに相当する、ロードモジュールってのがあったです(今もこの名前があるのかはよく知りませぬ)。
でまぁ、ロードモジュールってのは各プログラムごとに作るので。バグとかがあると、適宜ソース直してコンパイルしてロードモジュールを入れ替えたりするわけなのですが。
当然「プログラムしくじる可能性」もあるわけで。
まず、以下のようなディレクトリたちを用意してたです(名前はかなりアバウトなのと、実際にはもうちょっと深い階層構造してました)。

  • ドラフトテスト
  • 公式テスト
  • フィックス

とりあえず「開発者個人がテストしたい」場合、ドラフトテストのディレクトリにコンパイルしたロードモジュール突っ込んでテストするです。
そうすると、実行する一通りのロードモジュールは「フィックス(または公式テスト)」から読み込まれるですが。「ドラフトテスト」に同名のロードモジュールがある場合、そっちを優先して読み込むです。
つまり「ほかは入れ替えずに自分がテストしたいモジュールだけ入れ替えてテストができる」です。
で。
自分のテストが終わったら、とりあえず何はともあれ「ドラフトテスト」ディレクトリはきれいに空っぽにするです。
そうすると、ほかの人は「すでに公式にフィックスしているロードモジュール」がちゃんと使えるです。ディレクトパーミッションとか間違えなければ「間違えて上書き」とか「削除」とかの心配もなっしんぐ。


で、自分でテストしてOKだなぁって思ったらソースコードを管理者(…おいらがやってました恐ろしいことに)に頼んでUpしてもらい、正式にコンパイル。この時点でのロードモジュールは「公式テスト」ディレクトリ。
で、専門のテスト屋さんがテスト。バグが直るとその辺が書類になって出回ってきて、最終的にOKならフィックス。ロードモジュールもフィックスディレクトリにぶち込まれます。


このやり方の便利なのは「とりあえずテストして」「やばかったらそのファイル消せばすぐに挙動が戻る」こと。ついでに「本番(っても開発中のブツですが)に影響する角度での消し間違い」がありえないこと。
ここでこの文書書いた理由その1。
………この手法の名前忘れた;;
誰か覚えてる方とかいたら是非突っ込みお願いします orz


おいといて。


最近開発してて思うですが。こういう手法が、あんまり出回ってないような。
なので、includeの順番で「優先順位の高いドラフトなディレクトリ用意していったん上書きして…」とか考えても、最近の人様のソースを見ると「ディレクトリ固定〜」とかが多くて、どうやろうか時々躊躇してしまうです。
実際問題。MWでは set_include_path とかをPHPの場合使ってるのですが。…あんまりよそで見たことがない(苦笑


この辺の「includeディレクトリの優先順位による解決(仮称)」を使わないのが、知識の継承不足なのか、なにか「この辺まずいぢゃん」てな理由があってなのかがちょいと興味があったので、メモ&考察。