}ページHome2013-07-28「仕組み」の名前の考え方Tweet名前に関する記事のタイトルがいまいちなのはさすがによくないので、タイトルを直した(2013/7/29)---最近ちょっと近くで話題になっていた「名前」の考えていきかたについて整理してみた。ブランド名のように、独自性を持たせることを目的とするのではなく、後で呼びやすく混乱しないための名前付け。「それ」を知る人間同士がその物を識別するために使うための名前のガイドライン。「わかりやすい」「混乱しにくい」名前をつけるにはどう考えていけばいいか、というお話。自分の立ち位置的に、ソフトウェア設計の視点が強くなってしまうが、仕組みを作る立場であれば似たような話になると思う。経験がたまれば、更新するかも。文をそのまま使う「これは何ですか?(何をするものですか?何をすることですか?)」と聞かれたと想定して、それで出てきた説明文をそのまま呼び名にすることを検討する。「何ですか?」の回答そのものなので、意図が伝わりやすい。長くなりがちだが、明快な説明ができる人間の命名であれば、短いことを上回るメリットがあることが多い。確認ポイント使う頻度は高くないか?使う頻度が少ない(例えば、個別の機能のいちモジュール名だったり、年一回の事務処理の細かい手順のひとつだったり)のであれば、意図が伝わりやすいことのメリットが大きい。毎日呼び合うような名前だと、短い名前をつけることを検討したあと、決定したほうがよい。いうと、ただ呼びやすいだけのあまり考えられていない(混乱しやすい・わかりにくい)名前で呼ばれてしまいやすくなるから。一部の単語だけピックアップして呼び続けられたりしないか?ピックアップされても混乱はないか?ピックアップしても区別できないから、本当に汎用な言葉がピックアップされることは少ない。「顧客情報データ」を「データ」と略して呼び続けることは少ない。文脈を共有すると選んで呼びやすくなってしまう語がある。「クライアント」とか。混乱がなければそれでもいいのだけど、混乱することがすでに想定できるのであれば、別の名前をつけてあげるのがよい。明示しておくと混乱がない。一方で、その略語が他と同じ場合、かえって混乱を招くので、そもそも略していない状態でも他の呼び名を検討する。そのまま使うパターンにマッチせず、意図した内容が既に一般的な名前として決まっている場合(「一般的に決まった名前」は以後、「定義された名前」とする)は、それを使うことを検討する。そのものということなので、ほとんどの場合良いが、安易に使うと大混乱を招くケースがある。確認ポイント元の語と明白に異なる意図を持っていないか?新しくつける名前側が従で、定義された名前のほうが先に来ているようなケースでは、それが前提である以上、異なる意図は存在しにくいので、この名前付けパターンは良い選択である。定義された名前が何かの規格で、その規格に乗ることこそ意図されたような場合であれば、それを名前につけるのは、受け取る側の意識付けの意味としても、非常に有効である。定義された名前が従の場合、注意が必要である。「これこれはAで、あれそれはB...これってXYZって名前ついてるじゃん!」というケース。いった場合、一部の重要な部分が異なる場合がある。「定義された名前ではそれそれはCなんだけど、自分が考えるのはそれそれはDなんだよね...」といった感じ。このようなことが名前付けの段階で明らかに分かっている場合は、その名前は使うべきではないことが多い。いうと、聞いた側は、名前が既に定義されているが故、その定義側の意図のほうを名前に感じてしまうから。「俺のXYZはそうじゃないんだ!」といっても、最初はいいかもしれないが、よっぽどの強さがないと、元の語の意図を書き換えるのは難しいので、どんどんその意図は薄れて行ってしまう。元の語に付加したい強い意図は持っていないか?意図を狭めたくはないか?定義された名前は確かにずばりなんだけれど、もっと範囲を狭めておきたいという意図がある場合は、言葉を付加するなり、別の名前付けをするなりを検討すべき。しておけば、広すぎて何を言っているかわからないという事態を避けられる。別ジャンルの意図することと関係のある単語を使う文そのものでも、既存の言葉もない場合は、別ジャンルの近そうな言葉がないかを考える。メタファー/こじつけの世界。一回目は聞いてもわからないが、わからない故、確認が必要となる。ゆえに、混乱を招きにくい。比喩になっているので、一回認識してしまえば、覚えやすい。確認ポイント選んだ言葉から受ける意図が、他の一面と衝突しないか?単語の持つ意味は一面ではないことがあるので、ある面を見て比喩を選んでも、別の面で衝突している可能性がある。固いイメージを与えたいからといって「フライパン」と名付けたとしても、冷たいという意図を併せ持つものだったりすると、「フライパン」の持つ熱せられそうなイメージと衝突するので、混乱を招く。元のジャンルでその言葉は別の意味を持っていたりしないか?比喩として使われていたりなどで、すでに使われていないか。ケースで意図がバッティングすると、大混乱を招く。別ジャンルの全く関係ない単語を使う3)に近いが、名前付けに意図がないので、さらにぱっと見/ぱっと聞きでわかりにくくなるが、混乱も小さくなる。数が必要な場合に選ぶとよい。新単語を作るどうしても困る場合は、新しい言葉を作ってしまうのもひとつ(文を略語化するのもこのパターンの一つなんだけど)。似たような意図の語がすでに用意されていないか?それとの違いは何か?最初にやるべきだけど、名前をつけることで明確になることもあるので、再度確認する。似たような単語が既に使われていないか?別の意図なのに、同じあるいは同じような用語が使われていないか確認する。2.0向け...Azureはどんどん変わるので)。このブログでAzureが登場するのは初めてかも。Express\AppServer\applicationHost.configを変更する。うまくいかなかったら、下に書いた方法で調べるといいかも。Expressを使うかIISを使うかをクラウドサービスプロジェクトの設定で選べる。Expressが利用される。Expressの場合はIISではないので、この方法では設定が反映されない。いじれという情報がWebにある(例えばいつもお世話になっているブチザッキさんのブログ)ので、「これだ!」と思って変更するものの、反映されない。Explorerでiisexpress.exeのコマンドラインを調べてみると、applicationHost.configの場所が明示的に指定されていることがわかった。読んで、上記の一時的なパスに書き込んでいることがわかったので、元のファイルを書き換えてみると無事反映された。