2014年10月2日
あなたは全部知っていますか？プログラミングの業界用語30選
(2012-07-20)by Jeff Atwood
本記事は、原著者の許諾のもとに翻訳・掲載しております。
Stack Overflowは、私が学習に役立ててきた多くのオンライン・コミュニティと同じように、自然と厳しくなってきました。第一にこれは、自己防衛機能です。子どもが初めて学校や託児所に入ると広大な世界にさらされて、 髄膜炎菌症を発症 して日々くしゃみやせきを繰り返しながら成長するのと同じような免疫システムです。常に好ましいことだとは言い難いですが、生き残るためには必要なプロセスなのです。
2年前に投稿された、下記の質問のことを考えてみてください。
あなたが新しく作ったプログラミングの業界用語は何ですか？
あなたが作り、あなたの周りで使われるようになった、プログラミングの用語は何ですか？（他の人が真似して使っているのを聞いた、など）あなた独自の言い方が、職場内でのみ使われていたり、インターネット上で幅広く普及していたりすることもあるでしょう。
独自のプログラミングの用語、単語、言い回しを太字のテキストで書いてください。私たちが適切な文脈で使えるように、説明や引用元、それに使用例も添えてください。
すでにプログラミングの文化に深く根付いているkludge、automagically、cruftなどの業界用語以外でお願いします。（作成者である場合は別です。）
自分だけの表現や、周囲の環境で普及して役立った用語を共有することによって、プログラマのコミュニケーション精神を豊かにするための質問です。
本当にこれは質問と言えるでしょうか？ どれくらいの回答が寄せられたのでしょう？
その数なんと386です！
386もの異なる”回答”が集まるなんて、これはもう質問とは言えません。まるで世論調査や選挙、Xリストです。全ての回答を読めばプログラミングについて何かしら学べるに違いないと思うことでしょう。しかし、明らかにこの回答の山は、学習として使うよりもはるかに滑稽で興味深いものでした。それゆえ、経験の長いStack Overflowのコミュニティ・メンバーによって削除されてしまったのです。学習の素材という点ではどうにかボーダーライン上で、削除するという行為には個人的には反対でしたが、正確な方法できちんと削除されたという点には同意します。 意見はさまざま です。
私たちの “愉快な戦い” や、 trouble with popularity の流れを全て見せて、退屈させるつもりはありません。結局のところ、Stack Overflowは組合ではなく大学なのです。サイト内の全てのコンテンツは、楽しさよりも学習の役目を果たすために存在しなくてはいけません。つまりそれが、プラスマイナス10％目的を達成できない質問や回答を取り除くという厳しい要求になったとしてもです。
しかしプログラマの文化には、 業界用語ファイル という前例があります。あいにく私たちには、削除されてしまった”愉快すぎる”質問を生かしておくための良い場所はありませんが、Stack Exchangeの全てのコンテンツは永久にCreative Commonsに認可されています。つまり、しかるべき出典を明記すれば、自分個人のブログ内に、永久的に残しておけるのです。というわけで、下記にStack Overflowの新しいプログラミングの業界用語30選を集めてみました。Stack Overflowのコミュニティに判定されたものです。楽しんでください。*
1. Yoda Conditions (ヨーダの条件式)
if(4 == foo)のようにif(variable == constant)の代わりにif(constant == variable)を使う式。ヨーダの”if blue is the sky”や”if tall is the man”という話し方から。
2. Pokémon Exception Handling (ポケモン例外処理)
すべての例外を捕まえようとすること。
try {
}
catch (Exception ex) {
// Gotcha!
}3. Egyptian Brackets (エジプト人ブレース)
下記のように、行の最後でブレースを開く括弧の使い方を知っていますか？
if (a == b) {
printf("hello");
}私たちはこの括弧のつけ方を”エジプト人ブレース”と呼んでいます。なぜでしょう？ コードの括弧と、絵に描かれている手の位置を比べてみてください。
（この括弧はKernighanとRitchieの著書 『The C Programming Language』 の中で使われており、K&Rスタイルとして広く知られています。）
4. Smug Report (ドヤ顔レポート)
実際に大したことをしているわけではないのに、”自分はシステムデザインについて豊富な知識がある”と思い込んでいるユーザから報告される、バグのレポート。見当違いの技術的な詳細や、問題の原因と解決策に関するいくつかの（そしていつも間違っている）提案で埋められています。
関連語として、Drug Report（内容が理解できなさすぎて、ドラッグをやっている人が書いたとしか思えないレポート）、Chug Report（提出者が１つの事について、うるさく書きすぎているレポート）、Shrug Report（エラーメッセージや再プログラミングなどの処理もなく、問題点のみが曖昧に書かれているバグのレポート。「動きません」という言葉がよく登場する）があります。
5. A Duck (カモ)
経営陣の興味を引く目的以外、特に理由もなく追加される機能。製品の不必要な変更を避けるために、結局は取り除かれる。
私がこの言葉を最初に作ったのかどうかは分かりませんが、元になった話は別にあります。
これは協力会社に伝わっている話です。有名なプロデューサたち（PMと同等なゲーム業界の地位）は、完成した作品の全てに変更を加えなければいけませんでした。そうしなければ、価値のある作品にできないという意識が漠然とあったのでしょう。
Battle Chessのクイーンのアニメーションを制作していたアーティストはその傾向に気付いており、革新的な解決策を考え出しました。彼は自分が最良だと思う方法で、アニメーションにあるものを追加しました。ペットのカモをつけたのです。クイーンのアニメーション全てに同じようにカモを描き、クイーンの近くで羽ばたくようにしました。彼はまた、それが”実際の”アニメーションとは重ならないように、細心の注意を払いました。
そして、プロデューサによるアニメーションのレビューの日がやってきます。アニメーションを見終えたプロデューサは、アーティストの方を向いてこう言いました。”すばらしいね。ただ、カモだけは取り除いてくれ”。
6. Refuctoring (リファックタリング)
うまく設計されたコードにするため、小さな変更や、いったん変えたコードを戻したりするといったことを繰り返すうちに、自分以外はまったくメンテナンスできないコードにしてしまうこと。
7. Stringly Typed (謎の型付け)
Mark Simpson
strong typied（強い型付け）をもじったもの。プログラマやリファクタリングがうまく使える状態なのに、不必要に文字列を使った実装のことを表わします。
例：
- より適切な型があるのに、文字列を使うメソッドのパラメータ
- 文字列がメソッドの呼び出しで必要とされる場合。（ネットワークサービスなど）文字列が渡されて、最初により適切な型に変換せずに、残りのコールグラフを通して使われる。（解析してenum型を生成し、残りのコードベースを通して強い型付けを行うなど）
- 型付けされたメッセージを使わずにパスするメッセージなど
8. Heisenbug (ハイゼンバグ)
作者不明
検証しようとすると消えてしまったり性質を変えたりするバグ（ Wikipedia ）。
9. Doctype Decoration （DOCTYPEデコレーション）
WebデザイナがDOCTYPEを宣言したものの、正しいマークアップを書いていないという状態です。
<!DOCTYPE html>
<BLINK>Now on sale!</BLINK>10. Jimmy （ジミー）
何も分からない新人の開発者に対して汎用的に使える名前。
他の開発者にとっては、仕組みについての最小限の知識さえあれば対応できるフレームワークコンポーネントを開発している時にジミーが登場しました。”ジミーがその属性の更新を忘れたらどうなるかな？”というような形で、常に使ったものです。
このことから、よくデザインされているフレームワークコードを示す時の用語、”ジミープルーフ（Jimmy-proof）”が生まれました。
11. Higgs-Bugson （ヒッグスバグ粒子）
ごく少数しか発生したことがない関連イベントログやユーザが報告してきた曖昧な事例から、存在するであろうと推測されています。本当に存在しているのかどうか、そしてバグが発生した原因も分からないため、デバッグ環境で再現させるのが（再現が可能なのであれば）難しいバグです。（ ヒッグス粒子 参照）。
12. Nopping （ノッピング）
私はAIの観点から サイエンスフィクションの小説 を書いているのですが、その小説で数多くのプログラミングの業界用語を使っています。その中のひとつに、アセンブラ言語で何もしないことを意味するNOPが語源の”nopping （ノッピング）”という用語があります。”nap （昼寝）”と似ていますが、寝るという意味ではなく、単に意識を失いそうになるという意味です。”スクリーンセーバーを見ながら座っていたスタニラフは、しばらくの間ノッピングした。”
13. Unicorny （ユニコーンっぽい）
かなり初期の計画段階にあるため、まるで空想上の世界のように思える機能を表す形容詞。Yehuda Katzが、昨年の Windy City Rails の基調講演を締める時に、Railsに関する将来の機能について説明するために使っていた言葉です。
14. Baklava Code （バクラヴァコード）
レイヤが多すぎる コードのこと。
バクラヴァは紙のように薄いフィロ生地のレイヤからなるとてもおいしいお菓子です。お菓子なら薄いレイヤは申し分ないのですが、ソフトウェアにおいて、特にそのようなレイヤが互いに積み重なっている時、薄いレイヤは何の価値もありません。プログラマがコードに没頭している時に、それぞれのレイヤはプログラマのメンタルなスタックにプッシュされます。その上、フィロ生地のレイヤは透けていて、ハチミツがしみ込みやすくなっているものです。しかし、ソフトウェアの抽象化では何も漏らしてはなりません。ところが、ソフトウェアでレイヤの上にさらにレイヤを積み重ねると、レイヤは何かしら漏らしてしまうことになります。
15. Hindenbug （ヒンデンバグ）
データを破壊する壊滅的なバグ。”何てことだ！”
この用語はCounterbug （カウンターバグ）（バグを作った人により引き起こされたバグによって現れるバグ）やBloombug （ブルームバグ）（偶然お金を生み出すバグ）にも結びつきます。
16. Fear Driven Development （恐怖駆動開発）
プロジェクト管理者からプレッシャー（解雇、納期の前倒し、プロジェクトからのリソース削減など）をかけられること。
17. Hydra Code （ヒュドラーコード）
修正できないコード。 ヒュドラーの神話 のように、バグを1件修正するたびに、新たに2件のバグが出現します。そのようなコードは書き直しましょう。
18. Common Law Feature （事実上の機能）
匿名
非常に長い間アプリケーションに存在し続けたために、要求機能の一部になってしまったバグ。実際はユーザサポートが調整しなければなりません。
19. Loch Ness Monster Bug （ネス湖の怪獣バグ）
ネス湖の怪獣バグは、再現性がない、または1人にしか目撃されていないバグのことです。僕のオフィスでは、今や誰もがこの用語を使っています。（同義語： Bugfoot （バグフット）、Nessiebug （ネッシーバグ））
20. Ninja Comments （忍者コメント）
見えないコメント、秘密のコメント、コメントなしとも言います。
21. Smurf Naming Convention （スマーフの命名規則）
ほとんど全てのクラスに同じプレフィックスをつけていること。こういった感じです。ユーザがボタンをクリックした時に、SmurfAccountViewがSmurfAccountDTOをSmurfAccountControllerに渡します。SmurfIDがSmurfHistoryReviewViewかSmurfHistoryReportingViewに転送する前にSmurfHistoryMatchに渡されるSmurfOrderHistoryをフェッチします。SmurfErrorEventが発生するとSmurfErrorLoggerによって${app}/smurf/log/smurf/smurflog.logに記録されます。
22. Protoduction （プロトダクション）
そのまま商品化された試作品のこと。フェルミ研究所の技術者が使っていました。その人が生み出した言葉ではないそうですが、フェルミ研究所では多用されているようです。
23. Rubber Ducking （アヒルのおもちゃとの語らい）
時には、問題をただ口に出して言ってみることが必要です。かつて私はボスの部屋に行って話をしたものでした。ボスはただ私の話を聞き、そうしているうちに私は、自分で自分の疑問の答えが分かり、ボスのアドバイスをもらうことなく彼の部屋を出たのです。アヒルのおもちゃに向かって話しかけられるように、誰かがアヒルのおもちゃをモニタのところに置いたという話を読んだことがあります。アヒルのおもちゃとの語らいは、自分が持っている問題を口に出して言ってみる手段になるのです。
24. Banana Banana Banana （バナナ バナナ バナナ）
ドキュメントの作成を進めている時に書いておくプレースホルダテキスト。主にpublic関数がドキュメンテーションされていない時に出てくるFxCopの警告を避けるために使われます。
/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate()食べ物が絡んだ他の用語： Programmer Fuel （プログラマの燃料）（マウンテンデュー、コーヒー、マテ茶などのカフェインが摂取できるものなら何でも）、Hot Potato （ホットポテト）（httpやhttpsそれぞれ。同じ数の音節だが、口に出すと楽しいもの）、Cake （ケーキ）（Martyのヘタクソなケーキはビルドを破壊した）、Chunky Salsa （実入りのサルサ）（ chunky salsa rule （実入りのサルサルール） より。特にプロダクション環境で発生するシステム全体を使えなくしてしまう、1つの重大なエラーやバグ）。
25. Bicrement （バイクレメント）
変数に2を足すこと。
26. Reality 101 Failure （現実初級講座での失敗）
プログラム（どちらかと言えばプログラムの機能）を言われたとおりに作ったものの、デプロイした時に出題内容を間違って解釈していたために、使えないプログラムを作ってしまったということが判明すること。
27. Mad Girlfriend Bug （怒った彼女のバグ）
明らかに何かおかしなことが起きているのに、ソフトウェア自体は何も起きていないと示すバグのこと。
28. Megamoth （メガモス）
MEGA MOnolithic meTHod（巨大化したモノリシックメソッド）を表す略語です。多くの場合、 神オブジェクト を含み、メソッドの長さは大抵2面以上に渡ります。ソースコードの行数が2,000行を超えたメガモスも確認されているとか。メガモスに気をつけろ！
29. Hooker Code （フッカーコード）
アプリケーションにて不安定な状態（アプリケーションの”ダウン”）を引き起こす、問題のあるコードのこと。”またサイトがダウンしたのか？ ああ、ジムのヤツはまだフッカーコードを残しているようだな”。
30. Jenga Code （ジェンガコード）
1ブロック変更するだけで、全てが崩壊してしまうコードのこと。
ここでご紹介したのは、コミュニティの賛成票を基にして、実際に新たなプログラミングの業界用語になり得ると私が考えた、業界用語30選です。ただ単に”他のプログラマがWebページに載せた面白いもの”を選んだわけではありません。その役目を果たしているのはRedditです。読者の皆さんが、他の業界用語について知りたくてたまらないというのであれば、集まった業界用語は山ほどあります。正確に言えば356個です。Stack Overflowの古株ユーザであるGreg Hewgillは「 Stack Overflowから削除された質問アーカイブ 」をメンテしていますが、この記事はまだその域には達していません。ですので、とりあえずは、 Stack Printer を見てください。またはStack Overflowで1万レピュテーションを得れば、サイトで「 削除済みの質問 」の完全版を見ることができます。
*ただし楽しみすぎないでくださいね。あなたの行動はお見通しです。
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa
関連記事
