「プログラム」とは

エンジニアにとって、魔物であり、敵であり、愛すべき対象。

昼メロ系の愛憎劇に出てくる登場人物と接するような気持ちで相対することを求められる、取り扱いの難しい子。

命令をすれば、たとえそれが、この処理を100万回繰り返しなさいという、人間に向かって命令したら「あなたは鬼ですか」と思われそうなことでも、言われたとおりにやってくれる素直な子である。

ただし、Cドライブをフォーマットしなさいとか、他社のサーバに対して秒間1,000回のアクセスを実行しなさいといった、人間であれば「えっ、そんなことしていいんですか？」と立ち止まってくれそうな命令でも、言われたとおりにやってしまう恐ろしい子でもある。

あまりにも素直にこちらが命令したことを実行してくれるので、実装をしている際にプログラムに対して少しは空気を読んでほしいと思ってしまうこともあるもの。でも、プログラムが勝手に空気を読んでif文の結果をFALSEで返したとかいう下手なことをしたりすると、それはそれで腹が立つような気がするもの。

ただし、最近のプログラミング言語は、「使われていないメモリがあったので解放しておきました」とか、「同じ文字列が使われていたのでメモリ共有しておきました」とか、「関数のオーバーヘッドが気になったので、インラインで扱っておきました」といった良い空気の読み方もしてくれているので、侮れないもの。

「低級言語／高級言語」とは

プログラミング言語のジャンル分け（？）をする時に使うことがある言葉。低級言語のほうがよりマシン語に近く、高級言語のほうがより人間が使う言葉に近い。

低級言語のほうが学習にコストがかかるし記述量も多くなりがちだが、その分、高級言語には決してできない圧倒的に速いプログラムを記述できたりもする。そのため、低級言語を使える人のほうが高給取りである場合が多いような気もするもの。

低級言語に慣れ親しんだ人々の中には、バイナリコードを見て何かを感じることができるような種族が存在するらしい。筆者のような甘い高級言語の世界で育ってきた人間には、とんと理解できない境地である。

どこまでが低級言語と呼ばれ、どこからが高級言語と呼ばれるかという明確な定義は存在しない。C言語はアセンブリよりも高級言語と言えるが、Javaよりも低級言語と言える。とりあえずはCPUやメモリを直接制御できる言語であれば低級言語と呼んでいいようだ。

「オブジェクト指向」とは

Java案件がちまたに溢れ出したころに末端の現場にもだいぶ広まった、プログラムを組むうえでのアプローチ方法の１つ。

機能をオブジェクトとして捉えることで、再利用性を高める、みたいな考え方で、最近の言語は大体これを実現するための機能を有しているもの。PHPのように生まれた当初は対応してなかった言語も、徐々にその仕組みを取り入れるようになっており、今ではPerlやCOBOLですら対応するようになっているというから驚きである。

ただ、言葉だけはやたらと飛び交っているけど、実際の現場では、その手法を理解している人は思いのほか少ないような気がしてならないもの。

基本的にプログラムというものはifとforがあれば後は力押しで書けるものなので、ナントカ指向とか呼ばれるものについては、差し迫って勉強する必要がなかったりすることが、詳細な知識まで全体に伝わらない要因の１つなのではないかと思われる。

上流レベルでインターフェースをしっかり作って、下流でそれに対して実装してもらうといった使い方をするのであれば、現場全体のコードの流れが共通にできて可読性が上がるが、うっかり現場の末端レベルで１人でそれっぽいクラス構成を作ってしまったりすると、ほかの人がそのコードを触る際に「読みづらい」とか「改修に手間がかかる」といったクレームが発生することになるので注意が必要である。

「アスペクト指向」とは

比較的新しい言葉。通称、AOP。

横断的関心事とかいう、パッと見、分かりづらい日本語で解説されることが多いたくさんのクラス（＝横断的）で、同じような記述を書く必要がある（＝関心事）場合のアプローチ方法の１つ。

オブジェクト指向で頑張って重複のないクラス構成を作っても、例えばすべてのクラスに同じようにログクラスの初期化処理が入っていたり、同じような例外処理が入っていたりと、コードをデザインする人間の立場から見ると、省略したい気持ちがふつふつと沸きあがるようななんか歯がゆい感じがする記述が発生する場合がある。

アスペクト指向は、そんな重複のない美しいコードをお望みの贅沢なデザイナーさんの願望をかなえてくれるかもしれない一品である。

ただし、実際に開発現場でアスペクト指向と出合える機会はまだ少なく、実際に使用することを希望しても実績の少なさから却下されることも多いので、現状ではあまり知っていても役に立たない知識かもしれないもの。

コメント

プログラム内に記述される注釈のこと。

コンパイラやインタプリタにとっては読み飛ばすだけの意味のない文字列だが、プログラミング言語よりも日本語や英語のほうが読みやすいと感じる人間にとっては意味のある文字列。

「このクラスにはこんな機能が実装されています」とか「以下の記述はこういった処理をしてます」といった説明を、日本語（たまに開発者は日本人しかいないのにわざわざ怪しい英語を使う場合もある）で書いておくことによって、後で誰かがそのソースを読んだ際の可読性を高めてくれる効用がある。

コメントはプログラマの精神衛生にも深くかかわってくる場合もある。

他人が作成したコメントが一切入ってないソースの改修を依頼されると、1行ずつ記述を追いかけなければいけなくなるため、読み始めて30分で鬱になるし、コメントに「//条件に引っかかった場合はfalseを返す」と書いてあったのに実はtrueが返ってましたとかいうトラップが多数しかけられていると、徐々に人間不信になっていってしまうので注意が必要だ。

コメントは良質なドキュメント代わりになることもある。 ソース1個ずつに対して概要説明ドキュメントとかを作っていたりすると、非常に労力がかかるし、実際のところそんな説明を一生懸命Excelで書いても誰も読んでくれないとか、誰も保守してくれないとか、いつの間にか紛失するといった事態に見舞われることが多い。

そのため、下手な資料を残す時間があったら、その労力をコメントの精査に充てたほうが、いろんな人が幸せになったりすることもあるかもしれない。

うっかり1つのモジュールを書きかけのまま長期休暇を取ってしまったりすると、休み明けには当然のように、休み前に書いていたことなんてこれっぽっちも覚えていないという現実に直面することとなる。

筆者のような忘れっぽい人間は土日挟んだだけで先週やっていた作業が何だったか、完璧に忘れる自信がある。

そんな僕ら忘却プログラマにとっては、休暇に入る前の最後の数分を利用して、「TODO取得データのINSERTと、異常系処理が未実装」などといった記述をコメントに残しておくと、休み明けのボケきった頭を仕事モードに切り替える助けになってくれたりするかもしれない。

バックスラッシュ

スラッシュ（/）を垂直方向に反転させた文字。

欧米の人たちにとっては、ファイルパスを見るたびに目にすることになるなじみ深い文字だけど、日本人はさまざまな歴史的な理由みたいなもの（後述）のせいで、あまりお目にかかることがないもの。

エンジニア的には、日本語環境で開発しているうえでは目にすることも少ないが、英語のソフトウェアを使用している時に見かけたり、円マーク（￥）を見た時に心の目にはバックスラッシュが映っているということは、結構あるかもしれないもの。

日本人がバックスラッシュを目にしない理由は、昔々、まだコンピュータが今のように大容量でなく、Unicodeなんて規格が影も形も存在しなかったころにまでさかのぼる。

当時はまだコンピュータの性能は低く、ソフトウエアエの国際化対応のような要求も少なかったので、各国が使う文字の事情に合わせるために１文字のデータ量を増やすというUnicode的な発想は現実的ではなかった。そのため、文字に使われる７ビット（128種類）のうち、決められたいくつかのコードは各国で自由に割り振ってもよいというルールが存在していた。

そこで日本では、海外でバックスラッシュを割り振っていたところに、国内でよく使われる円マーク（￥）を割り振ることになった。

それがいけなかった……。

その時に作った円マークの風習は、数十年の時を経た今でも残り続けている。もしその規格を変更すれば、使用しているパソコンの環境によっては、日本中のシステムで円マークを表示している箇所に、バックスラッシュが表示されてしまうという嫌な現象が発生してしまう。そのため、今のところこの風習は消えることなく残り続けている。

コンピュータの規格は、一度決まってしまったことを覆すのは難しいという現実を、目に見える形で私たちに伝えてくれる、メッセージ性に富んだものであると言えば聞こえもいいような気がする。

○○以上、○○未満

プログラムを組むうえで、非常によく出てくるロジック。○○の部分に入るのは数値である。「友達」とか「恋人」が入るような話を取り扱っているわけではないので注意。

例えば、「指定価格以上が入力された場合はエラーメッセージを表示する」とか、「敷居値未満のデータを一覧にして表示する」とかといった使い方で、仕様書によく出てくる言葉である。

「以上」は指定された値を含み、「未満」は指定された値を含まないということは、小学校の算数で習うような話ではあるが、仕様書ではそれなりの頻度でこの部分が間違っていて、その値を含まないのに「以下」と書いてあったりすることがあるような気がするもの。

条件が複数絡んでいて、マトリックス図でも書かなければとても状況を把握できなくなるような場合には、こっちは「以上」で、こっちは「超える」で、こっちは「以下」で、こっちは「未満」で、と話していると、設計した本人ですら「これはどっちだっけ……」と混乱するようになったりするもの。