10. 「何か」は分かるが「なぜ」が分からないコメント

プログラミング入門コースでは、早い段階かつ頻繁にコメントを記述することを生徒に教えます。プログラムを書き始めた初期段階（ごく単純なコードであっても、時に理解し難いことがあります）では、これは実際に役立つことなのですが、習慣にとらわれてしまうプログラマが多くいます。

上記のコードが何をするのか分かりますか？

私は分かりません。

問題は、多くのコメントがそのコードが 何をする のかを説明していますが、 なぜ そのコードが書かれているかが説明されていません。では、異なるコメントが書かれた同じコードを見てみましょう。

こちらの方が分かりやすいですね。何が起きているのかを完全に理解できるとは言えませんが、最低でもなぜこのコードが必要なのかが文脈から判断することができます。

コメントは、構文を理解してもらうためにではなく、読み手がコードを理解しやすいように書きましょう。あなたのコードを読む人は、forループに関する基礎知識を持っていると考えて良いでしょう。しかし、彼らはそのコードがなぜ機能するのか、なぜそのコードを使うかに至った経緯は理解していないでしょう。

9. 妨害

一般的に、プログラマはフェラーリのように即座に始動できるタイプではなく、機関車のように始動に時間をかけるタイプだと思います。何かを始めるまでに時間は要しますが、一度軌道に乗ってしまえば驚くほどの仕事量をこなすことができます。とは言え、絶えず顧客や同僚によって思考が妨げられてしまえば、軌道に乗る（もしくは“集中力を保つ”）ことが大変難しくなります。

8. 仕様の変更

Wikipediaでは、 仕様の変更 は「プロジェクトの仕様に起こる制御できない変更」と定義されています。仕様の変更は、要求する側からみると単純であることが多いのですが、プログラマからしてみると、それはものすごく複雑で時間を要する作業なのです。継続的な仕様の変更によってプロジェクトのスケジュールをめちゃめちゃにするには、一見当たり障りのない文字をちょっと付け加えるだけで十分です。

1. バージョン1:　ある位置を示す地図を見せる
2. バージョン2:　ある位置を示す3D地図を見せる
3. バージョン3:　ある位置を示す3D地図を見せ、ユーザが自由に視点を移動できるようにする

7. プログラミングを理解していないマネージメント

そこには いくつかの特権 があるようです

マネージメント業務は簡単なことではありません。部下にはイライラさせられることもあります。気まぐれな者もいれば、虚弱な者もいます。そして、みんなが一番になりたいと思っています。大勢の部下を満足させ団結させるには、課題が山積みです。とは言え、部下がやっている仕事を上司が理解していなくても良いということにはなりません。上司が部下の基本的な業務内容を把握することができなければ、部下は、仕様の変更や非現実的な締め切りを課せられることになり、両者の間にさまざまな不満を生むことになります。この問題は、プログラマから多く寄せられる不満であり、懸念材料にもなっています（このこっけいな 漫画 がその1つです）。

6. アプリケーションのドキュメント化

先に言っておきますが、アプリケーションのドキュメントを生成するジェネレータが多く存在することは、私も承知しています。しかし、私の経験から言わせてもらうと、それらは他のプログラマが読むために、APIのドキュメントを生成するということだけに有効的です。もし、日常的に人々が利用するアプリケーションをあなたが作っているのであれば、素人でも理解できるドキュメントを作成する必要があります（例えば、アプリケーションがどのように機能するのかやトラブルシューティングガイドなどです）。

プログラマがドキュメントを作成するのをどれだけ恐れているかを見るのは難しくありません。公開されているオープンソースをちょっと見てみればよいのです。すべてのプログラマが常に必要としている手助けの1つが、ドキュメント化なのです。

すべてのプログラマに代わって、いつでもどこでも「 誰か代わりにやってくれない？ と私が言ってあげられます。

5. ドキュメント化されていないアプリケーション

私は、みんなが偽善者ではないと言っているのではありません。プログラマは自分が行っている作業に対して、常にサードパーティ製のライブラリやアプリケーションを使用するように依頼されます。これを行うには、 ドキュメントが必要になります。 残念ながら、6番目でお話したように、プログラマはドキュメントを書くことを嫌っています。私たちはその皮肉な状況を認識しています。

APIが持つ機能の半分も理解できない中で、サードパーティ製のライブラリを利用することほど苛立たしいことはありません。 poorlyNamedFunctionA()とpoorlyButSimilarlyNamedFunctionB()の違いはいったい何なのでしょう？　PropertyXにアクセスする前にnullチェックを実行しなくてはいけないのでしょうか？　おそらく、試行錯誤しながら判断していかなくてはいけないでしょう。

4. ハードウェア

データベースサーバーが突然クラッシュした場合やRAIDドライバが正常に機能しない場合のデバッグを依頼されたことのあるプログラマは、ハードウェアに起きる問題が厄介であるということを知っています。コンピュータを扱うプログラマなのだから、その問題の解決方法を知っているのは当たり前という間違った認識があるようです。確かにあるプログラマにとって、それは間違いではないかも知れません。しかし、大多数のプログラマはその解決方法を知らないことが多いですし、私たちの大部分は、コードがアセンブリに変換された後どうなるかを知らないか気にかけません。思ったとおりにコードが作動してくれれば、私たちはもっと高度な業務に集中することができるのです。

3. 曖昧さ

「Webサイトが壊れた」。「機能Xが正常に作動しない」。 曖昧な依頼は、対処に悩まされます。 私がいつも驚かされるのは、依頼人にその問題を再現してほしいとお願したときに、彼らがひどく苛立つことです。彼らには、「壊れたから直してほしい」だけでは、情報が 不十分 だということを理解してもらえないようです。

ソフトウェアは、（ほとんどの場合）決定論的です。そうなるように書いているからです。ただ「問題を解決して！」とお願するのではなく、プロセスのどの部分がおかしいのかを見つけ出させることで私たちの機嫌を取ってください。

2. 他のプログラマ

プログラマ同士が常に良い関係であるとは言えません。驚きですが事実です。その理由を10個出すのは非常に簡単です。ここでは、同僚のプログラマを悩ませるプログラマの共通する特徴をいくつか挙げてみます。詳細については別の記事で紹介したいと思うので、ここでは控えさせて頂きます。

• 敵意があるのかと思わせるくらい気難しい。
• システムアーキテクチャについて議論する時と、とにかく仕事をやっつけてしまわねばならない時がある、ということを理解してくれない。
• 効果的なコミュニケーションが取れない、または専門用語を勘違いしている。
• 自分の役割を十分に果たすことができない。
• コードベースやプロジェクトに対して無関心である。

最後に言い忘れていましたが、プログラマを一番悩ませることは・・・

1. 6か月後の自分のコード

くしゃみをしないで。バグがあるようです。

自分が作った昔のコードを見て、顔をゆがめたことはありせんか？　なんてバカなんだ！ この 私がなんで こんなコード を書いたのだろう？　燃やして！　火をつけて燃やして！

安心してください。そう思ったことがあるのはあなただけではありません。

実際のところ、日々変化を遂げているのがプログラミングの世界です。今日、最良だと思っていたことが、明日にはそうでなくなっていることもあるのです。完璧なコードを書くのは、単に不可能なんです。コードを判断する基準が毎日のように進化しているのですから。今は完璧と思っていても、のちにあざ笑われるかもしれないという事実と向き合うのは非常に困難なことです。これはとても耐えがたいものです。なぜなら、どんなにすばらしい最新のツールやデザイン、フレームワーク、ベストプラクティスを下調べしていたとしても、私たちが追い求めているものは少しずつ手の届かないところに行ってしまうという感覚が常にあるからです。
私にとって、これがプログラマでいることの最も頭を悩ませる事実です。プログラミングの弱点は、常に改善が必要であるということです。しかし、私たちは、まるで完成したあとにすぐに壊されてしまう 砂曼荼羅 と同じであるという気がしてなりません。