10. コメントが説明するのは「何を」であって「なぜ」ではない
入門レベルのプログラミングコースでは、学生に頻繁かつ早い段階でコメントを書くように教える。プログラミング学習の初期段階では、この方法が確かに非常に効果的であることは否定できない（最も単純なコード行でさえちんぷんかんぷんだから）。しかし、多くのプログラマーは、ひよっこからコンピューターの達人に成長した後も、この習慣を引きずっている。
r = n / 2; // 让 r 等于 n 除以 2
// 当 r - (n/r) 大于 t 时进行循环
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半
}
上のコードの意味、分かった？
四文字で言えば、五里霧中。
上記の問題は、コメントはたくさんあるのに、なぜこのコードを書いたのかが説明されていないことです。次に、上記と同じコードを別のコメントに置き換えると、その効果はまったく違ってきます。
// 使用牛顿-Raphson算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
だいぶ良くなったでしょう！まだこのコードの意味を完全に理解してはいませんが、少なくともコードは簡潔になり、すっきりしました。
コメントを書くのは、読者がコードを理解するのを助けるためです。ここでは、コードを読むすべての人が、forループがどのように動作するかについて基本的な理解を持っていることを前提としています。彼らがよく分からないのは、あなたのコードがどのように機能するのか、あるいはなぜあなたがこの実装方法を選んだのかです。
9. さまざまな邪魔
ほとんどの場合、プログラマーの思考はフェラーリというより列車のようなもので、ゆっくりと動き出す必要があります。つまり、集中状態に入る前に準備（ウォームアップ）が必要だということです。しかし、一度完全に没頭すると、多くの人が感心するようなコードを効率的に書き上げることができます。ただ残念なことに、この状態に達するのは非常に難しく、なぜなら私たちの思考は常にクライアントや同僚によって邪魔されるからです。
8. スコープクリープ
ウィキペディアでは、スコープクリープを「プロジェクトの範囲内で制御不能な変更」と定義しています。スコープクリープは、比較の単純な要求を、極めて複雑で時間のかかるタスクに拡張してしまいます。一見便利で無害な要求を利用して範囲を拡大し、少しずつプロジェクトのスケジュールを壊していくのです
- バージョン1：現在地の地図を表示
- バージョン2：現在地の3D地図を表示
- バージョン3：現在地の3D地図を表示。飛行ナビゲーションに使用できるほどの精度で。
7. 管理層はプログラミングを理解していない
もちろん例外もあります。このタイトルはあくまで個人的な体験に基づくものであり、もし似たような人がいても、それはまったくの偶然です。
まず、管理は簡単な仕事ではないことを認めましょう。部下はあなたを嫌うでしょう。彼らの傷つきやすい心は時には傷つけられることもあります。さらに、大勢の人々の団結と結束を維持することは、山のように重い任務です。しかし、任務が困難だからといって、管理者が部下に対して基本的な理解を持たなくてもよいというわけではありません。管理層が仕事の本質を把握できないと、スコープクリープが発生し、納期を過ぎ、挫折感や落ち込みなどを引き起こします。これは、多くのプログラマーが日常業務で頻繁に不満を言い、不安を感じる根本原因です。
6. ドキュメントを書くこと
確かに、ドキュメント生成ツールはたくさんあります。しかし、私の経験から言うと、これらのツールは、他のプログラマーが参照するためのAPIドキュメントを生成するのにもっぱら適しています。あなたが開発するソフトウェアが、多くの人々が日常生活で使うものであれば、素人でも理解できるドキュメントを書くのが最善です（例えば、アプリケーションの動作方法やトラブルシューティングガイドなど）。
まあ、一部のプログラマーはこれをやりたがりません。よくあるのは、オープンソースプロジェクトをざっと見て、その後、助けを得るためにドキュメントを探し続けることです。
私は自信を持って言えますが、どこでもほとんどすべてのプログラマーが、ドキュメントを書くように頼まれると、「他の人に書いてもらえないの？」と言うでしょう。
5. ドキュメント不足のプログラム
まあ、私はプログラマーが口先だけの人間だと言ったことは一度もありません。プログラマーはプロジェクトでサードパーティのライブラリやアプリを使うことをよく求められます。そのため、どうしてもドキュメントが必要になります。しかし、上の項目で述べたように、プログラマーはドキュメントを書くことを嫌います。まったく矛盾していて厄介ですね！
サードパーティのライブラリを使う必要があるとき、APIの少なくとも半分が何に使うのか分からないほど、これ以上に気が滅入ることはありません。関数poorlyNamedFunctionA()とpoorlyButSimilarlyNamedFunctionB()の違いが分かりますか？PropertyXにアクセスするとき、最初にnullテストを行う必要がありますか？ドキュメントがなければ、自分のテストとエラーレポートによって結果を知るしかないでしょう。ああ、なんてこった！
4. ハードウェア（いつもパソコン修理の人だと思われる）
データベースサーバーの奇妙なダウン現象のデバッグを頼まれたり、RAIDドライブが正常に動作しない問題を解決するよう頼まれたりして、最後に原因がハードウェアだと分かれば、どんなプログラマーでもorzと苦痛でたまらないでしょう。ところで、どこから来た誤解なのか分かりませんが、人々は、プログラマーという一日中パソコンをいじっている連中なら、パソコンの修理方法も当然知っていると思っています。まあ、確かに修理できるプログラマーもいます（おそらく大学時代に女子を口説くために磨いたスキルでしょうか？）。しかし、保証しますが、ほとんどのプログラマーは修理方法を知らないか、プログラムがコンパイルされてマシンコードになった後、どのように動作するかにはまったく関心がありません。
私たちは何を気にしているのでしょうか？気にしているのは、自分たちが作ったものが要件を満たしているかどうかです。そうすることで、より高次のタスクの解決に集中できるのです。
3. 曖昧模糊
「ああ、私のウェブサイトが壊れた」「XX機能が動作しない」といった曖昧な要求が最もつらいものです。特に驚くのは、非プログラマーに問題を再現してもらうように頼むと、彼らが怒り出すことです。彼らは、「パソコンが壊れた。早く直して」という一言だけでは、私たちが作業を始められないことを知らないのでしょうか？私たちにはもっと多くの情報が必要なのです。
ソフトウェアの動作は、ほとんどの場合、手がかりを追うことができます。私たちもそのやり方が好きです。私たちに合わせて、どのステップで問題が発生したのかを特定するのを手伝ってください。単に「直して」と言うのではなく。
2. 他のプログラマーとの付き合い
プログラマーは他のプログラマーとよく馬が合いません。驚いたふりはやめましょう。心の中ではもう認めているでしょう、親愛なるプログラマーの皆さん。このことについての例は、すぐに十個は挙げられますし、別にブログ記事を書くことさえできます。そこで、この記事では、同僚とうまくやっていくのが難しい理由をいくつか挙げるだけにします。
気性が荒く、態度が友好的でない。
システムアーキテクチャを議論すべき時と、作業を開始すべき時が分かっていない。
効果的にコミュニケーションできず、誤解されやすい専門用語を使う。
自分のことをうまく処理できない。
コードベースとプロジェクトに対する興味が乏しい。
これはまだ最悪ではありません。もう一つ、重量級の「プログラマーキラー」、No.1がこの後に控えています……
1. 6ヶ月後に自分のコードを見直す
くしゃみをしないで。バグを見つけた。
以前書いた自分のコードを見返して、思わず胸を叩いて地団駄を踏んだことはありませんか？自分はなんてバカだったんだ、こんなクソみたいなコードを書いてしまってと悔やんだことはありませんか？消せ、消せ、全部消せ！
まあ、安心してください。これはあなただけに起こることではありません。
私たちのプログラミングの世界は絶えず変化しています。今日は最高の技術でも、明日には時代遅れになるかもしれません。私たちは永遠に完璧なコードを書くことはできません。なぜなら、評価の基準も時代の進歩とともに絶えず高くなっているからです。今はどれほど完璧に見えるコードでも、すぐに人々の嘲笑の的になるかもしれません。
これは確かに、思わず落ち込んでしまいます。なぜなら、最新かつ最高の開発ツール、デザイン、フレームワーク、開発手法をどれだけ学ぼうとしても、私たちは常に最新の技術トレンドより一歩遅れているからです。私にとって、これはプログラマーとして最も悔しいことであり、これ以上に悔しいことはありません。だから、これをNo.1にしました。私たちにできるのは、技術を絶えず更新することだけです。しかし時々、自分は砂像を作る職人のように、壊しては作り直しているような気がします。えへへ。