プログラマーを怒らせる10のこと

プログラマーは比較の特殊な集団であり、長期間コンピューターと向き合ってきたことで身につけた性格や気性も比較の近いものです。もちろん、人間である以上、性格もあれば気性もあります。それでは、プログラマーを激怒させる10のことを見ていきましょう。一方でプログラマーの共通点を見ることができ、もう一方でプログラマーの欠点も見ることができます。いずれにしても、これらが皆さんの日々の仕事の助けになることを願っています。

第10位プログラムのコメント

プログラムのコメントは本来良い習慣だ。ベテランのプログラマーが初心者を指導するとき、必ず「コメントを書くように」と教えるものだ。そこで初心者たちはもちろん先輩の言いつけに従う。ただ、彼らはプログラムコメントについて誤解しているかもしれない。そのため、私たちはよくプログラムの中で次のようなコメントを見かける。

このようなコメント——「何か」だけをコメントし、「なぜ」をコメントしない——を見るたびに、あなたはきっと腹が立つだろう。「誰が書いたプログラムコメントだ？」と、文句の一つも言わなければ気が済まないだろう。プログラムコメントは、他人に自分の意図や考えを伝えるものであり、プログラムの構文を伝えるものではない。これはプログラムの可読性と保守性のためだ。コメントのためにコメントするようなコメントは、明らかにコメントではなく、挑発であり、他人を怒らせるのは言うまでもない。

r = n/2;  //r是n的一半
 
 //循环，仅当r- n/r不大于t
 while ((r-n/r) <=t){
     //… …
     r = 0.5 * (r-n/r); // 设置r变量
 }

第9位邪魔が入る

プログラマーがプログラミングアルゴリズムの思考に没頭しているとき、あるいはひらめきが湧いてプログラムを書いているときに、他人の邪魔が入るのは非常に苦痛なことだ。もし絶えず中断されると、人は一気に苛立ち始めるかもしれない。このような状況で中断する人は非常に無礼である。中断された人は関数呼び出しのようなもので、戻るときにはブレークポイントの現場を復元し直す必要がある。もちろん、人間はコンピュータではないので、現場の復元は通常非常に苦痛なプロセスであり、極端な場合には最初から思考を探し求めて、少しずつブレークポイントに戻らなければならないかもしれない。

そのため、静かで邪魔されない時間が必要なとき、一部のプログラマーは誰にも見つからない場所に行くか、机の上に「現在カーネルプログラムを実行中、中断不能、お静かに願います、ありがとう！」という横断幕を掲げて皆に知らせる。仕事に没頭しているプログラマーが中断されるのは、それほど大きなコストなのだ。当然、中断されて腹を立てる人も少なくない。

第8位要件変更

この件は言うまでもないでしょう。プログラマーであれば、要件変更に直面するたびにたいてい無力感を感じるものです。一度や二度ならまだ受け入れられるかもしれませんが、頻繁に変更されては耐えられません。アジャイル開発には、プログラマーが要件変更を楽しめるようにする方法論があるそうですが、本当かどうかはわかりません。とはいえ、今日は机を作れと言われ、明日は机を食卓に変えろと言われ、明後日は食卓をダブルベッドに変えろ、その翌日はベッドを丸太小屋に変えろ、そして丸太小屋を高層ビルに変えろと言われたら。ああ、誰だって怒ってしまいます。あの人たちはたった30分の会議で何でも決定できるのに、その後ろにいる何十人ものプログラマーは何百時間もの大変な作業を背負わされるのです。もし私なら、神獣草泥馬の助けを借りて気を晴らさなければならないかもしれません。

しかし、これはまさに、プログラマーはユーザーとのコミュニケーションの仕方を知らず、ユーザーもプログラマーとのコミュニケーションの仕方を知らないということを示している。プロジェクトに仲介者（例：PM）がいて調整しなければ、プロジェクト全体は「まったく噛み合わない」状態になり、ユーザーもプログラマーも互いに腹を立ててしまうだろう。ユーザーが腹を立てる事例をいくつか挙げるとすれば、プログラマーのあの頑固なまでに技術実装の観点だけから物事を考える方法は、おそらくトップ5に入るだろう。

第7位　マネージャーが技術を理解していない

素人が専門家を指導する事例など少なくないだろう？上司の一言は、正しいかどうかに関わらず、すべて正しいので、我々は従わなければならない。どんなに愚かで間違った決定であっても、従わざるを得ない。プログラマーは実はマネージャーが技術を理解していないことを怖がっているのではない。最も怖いのは、技術を理解していないマネージャーが技術を理解しているふりをすることだ。最も腹立たしいのは、理屈を主張して上司の権威に挑戦しても、上司はあなたを異端視することだ。ああ、そんな上司を思い出すと、罵るどころか、殴りたくなる衝動さえ湧いてくる。

実のところ、マネージャーはチームのサポーターに過ぎず、チームを助け、悩みや困難を取り除くべきです。チームに命令を下すのではありません。実に管理はとても簡単です。分かっているなら手伝ってやればいいし、分からないなら部下を信じて、任せてやればいいのです。一番恐ろしいのは、技術を理解しておらず、しかも部下を信頼しないマネージャーです。ああ、これは本当にプログラマーの痛みです。

第5位ドキュメントがない

ユーザードキュメントは本来、それほど怖がられるべきものではない。これらのドキュメントは、我々が開発するソフトウェアに関するあらゆる話題を記録するものだ。我々はユーザーがどの程度のコンピュータ操作の基礎知識を持っているかを知らないので、このようなドキュメントを書くときには、ユーザーは何も知らないと仮定しなければならない。そのため、最も明確で美しい言葉で、最も豊富なドキュメントを書く必要がある。コピー＆ペーストの操作一つとっても、五、六のステップに分けなければならないかもしれないし、IPアドレスを設定する操作一つとっても、スタートメニューから一歩一歩説明しなければならないかもしれない。プログラマーにとって、開発中はほぼ毎日自分たちが開発したソフトウェアを使っているので、最後には吐き気を覚えるほどにうんざりしてしまうかもしれないが、それでも最も簡単な部分からこれらのドキュメントを書かなければならない。当然、彼らをいらいらさせやすく、プログラマーにこのようなドキュメントを書かせると効果は非常に良くないかもしれない。したがって、このようなユーザードキュメントは、専門のドキュメント担当者が作成・保守すべきである。

第6位ユーザードキュメント

前の項目で述べたように、プログラマーはそもそもドキュメントを書くのが好きではない。そして技術者の表現力や文章力は一般のにあまり良くないので、ドキュメントの出来も非常に悪い。オープンソースコミュニティのドキュメントを見れば分かるかもしれない。しかし、我々の愛すべきプログラマーが、その一方で最も腹を立てるのはドキュメントがないことだ。もちろん、先ほど言ったのはユーザードキュメントのことで、ここで言うのは開発に関するドキュメント、例えば設計ドキュメント、機能仕様、保守ドキュメントなどである。とはいえ、基本的には同じである。とにかく、一方では我々のプログラマーはドキュメントを書きたがらず、他方では我々のプログラムはドキュメントがない、ドキュメントが少なすぎる、あるいはドキュメントが理解できないと文句を言われる。はは。どうやら文句を言うことにも再帰があるようだ。アジャイル開発はソフトウェア開発におけるドキュメントを減らすことができると言われている。彼らはコードをドキュメントやビューのように書くことができると言われているが、本当かどうかはわからない。しかし、私はあまりにも多くのプログラマーがドキュメントがない、少なすぎる、ひどすぎると文句を言うのを聞いてきた。この点に関しては、やはりプログラマー自身が悪いと言える。

第4位デプロイ環境

プログラマーはソフトウェアを開発しているが、我々のプログラムがどのような環境に配備・インストールされるかはわからない。例えば、ネットワークの違い、RAID構成の違い、BIOSの違い、オペレーティングシステムの違い（WinXPとWin2003）、アンチウイルスソフトの有無、他のプログラムとの互換性、システム内のスパイウェアやウイルスなどである。もちろん、ソフトウェアにエラーが発生すれば、それがプログラムの問題であれ環境の問題であれ、結局は自分の問題であり、すべて解決しなければならない。そのため、プログラマーは単にプログラミングをしているだけではなく、多くの場合、優れたシステム管理者でもある必要がある。最終のに問題の原因が環境の問題であると確認されるたびに、プログラマーは怨みを抱くかもしれない。

第3位問題報告

「私のソフトウェアが動かない」「プログラムにエラーが出た」——こうした問題報告を聞くたびに、プログラマーはいつも苦痛を感じます。なぜなら、そんな問題報告は何も言っていないに等しいのに、プログラマーはそのエラーを処理しなければならないからです。明確な問題の記述もなく、問題を再現する方法も示されていません。感覚のには、当然どこか問い詰められているように感じられます。さらに、時には見下したような、叱責するような口調が混じっていることもあります。もちろん、プログラマーは基本的に個性が強く、強引にも甘言にも動じないタイプなので、そういう口調で問題を報告されると、たいてい言い返してしまいます。もちろん、後で自然と不愉快なことが起こります。ですから、プログラマーとユーザーのコミュニケーションを支援するカスタマーサービス部門が必要なのです。

第2位プログラマー自身

プログラマーを怒らせるのは、おそらくプログラマー自身かもしれない。プログラマーは「互いに見下し合う」傾向があり、彼らは基本的に皆、自分の才能を恃んで傲慢であり、常に自分が一番優れていると思っている。プログラマー同士は、ほぼ毎日のように喧嘩し、一度喧嘩になれば顔を真っ赤にして激しく言い争う。彼らの間では、常に自分たち自身に怒らされているのだ。

技術的な見解の相違。例えばLinuxとWin、VC++とVB、ViとEmacus、JavaとC++、PHPとRuby、などなど。何でもかんでも争う。
ベテランの新人に対する軽視。常に一部のプログラマーは他のプログラマーを見下しており、話し方には傲慢さと叱責が混じっている。新人が質問に行っても、ベテランたちはいつも無視したり、素っ気なかったりする。
技術の面で相手の面子を潰す。どういうわけか、プログラマーはいつも相手の面子を潰す。誰かが特定の技術を誤解しているのを聞くと、彼らはいつも人前で大声で指摘したがり、他人の「間違い」を使って自分の「博学」を示し、他人の「無知」を証明しようとする。
軽蔑を好む。彼らは軽蔑を好む。実のところ、この世に完璧なものは一つもなく、良いところがあれば悪いところもある。難癖をつけるのはあまりにも簡単だ。プログラマーは特に他人を軽蔑するのが好きで、どんなものであれ、彼らはいつも人の長所を見ずに短所ばかりを見る。彼らの口癖は「ひどい」「駄目」などである。

プログラマーは長期間コンピューターと向き合い、書いたコードをコンピューターがいつも真面目に実行してくれるため、長い間にプログラマーは天狗になりがちです。しかし、この世界の多くの物事は、コンピューターのように正しい命令を入力すれば正しく動くというほど単純ではないことを、まだ知らないのです。プログラマーは、いつになったら成熟できるのでしょうか……

第1位　プログラマー自身のコード

どれだけ当時の自分の設計や書いたコードが美しく素晴らしいものだと思っていても、しばらくしてから振り返ってみると、必ず自分の愚かさを感じるものです。もちろん、他人のコードを保守しなければならないときは、保守しながら他人のコードをさんざん罵ることになるでしょう。かつて自分がどれほど得意げに、自分の設計やコードがどんなに完璧かについて話し合っていたか覚えていますか？ところが、2年も経たないうちに、学校を卒業したばかりの学生があなたのコードを保守する過程で、あなたのコードにあれこれ指摘し、あなたの面目を完全に丸つぶれにしてしまうのです。ふっ。もちろん、自分の設計やコードが常に最高だと思っている人もいますが、それはかなり静的で固定された見方で問題を見ていることになります。プログラミングの世界はいつも変化が速いものです。多くのことは、実際にやってみて初めて慣れるものであり、慣れて初めてより良い方法が分かるのです。これは段階を踏んで進んでいくものです。ですから、物事に慣れ親しめば親しむほど、以前に自分が作った設計やコードを振り返ると、必ず自分の浅はかさや愚かさを感じるようになります。もちろん、他人の設計やコードを見れば、罵り始めることもあるでしょう。