諺にもあるように、「古いコードを恥じない人はプログラマーとして成長していない」。私もその通りです。私は40年以上前に趣味でプログラミングを始め、30年前にプロとしてプログラミングを始めたので、それなりに失敗もしてきました。 とてもコンピュータサイエンスの教授として、私は学生たちに、自分自身の、私の、そして他人の失敗から学ぶように教えています。謙虚さを保つためにも、そろそろ自分の失敗を共有する時が来たと思っています。誰かの役に立つことを願っています。

3位 - MicrosoftのCコンパイラ

学校の先生は、『ロミオとジュリエット』は悲劇とは言えないと考えていました。登場人物たちは悲劇的な罪を犯しているのではなく、ただティーンエイジャーらしく愚かな行動をしているだけだと。当時は先生の意見に賛成できませんでしたが、今では彼の意見に一理あると感じています。特にプログラミングに関しては。

MITで86年生を終えた頃、私はまだ若く、人生においてもプログラミングにおいても未熟でした。その夏、私はMicrosoftのCコンパイラチームでインターンシップをしました。最初はプロファイリングのサポートといった定型的な作業を担当していましたが、その後、コンパイラの中で最も楽しいと思っていたバックエンドの最適化を担当するようになりました。特に、分岐文のxXNUMXコードを改善する必要がありました。

あらゆるケースに最適なマシンコードを書くことを決意し、私は飛び込みました。値の分布の密度が高い場合は、それらを 遷移表公約数がある場合は、それを使って表を密にしました（ただし、除算が ビットシフト（すべての値が2の累乗になった時点で、再度最適化を行いました。値のセットが条件を満たさない場合は、複数の最適化されたケースに分割し、既に最適化されたコードを使用しました。）

悪夢でした。数年後、私のコードを引き継いだプログラマーが私を嫌っていたと聞かされました。

学んだ教訓

David Patterson と John Hennessy が「Computer Architecture and the Design of Computer Systems」で述べているように、アーキテクチャと設計の主な原則の 1 つは、一般的に、物事をできるだけ高速に動作させることです。

一般的なケースを高速化する方が、まれなケースを最適化するよりも効果的にパフォーマンスを向上させます。皮肉なことに、一般的なケースはまれなケースよりも単純な場合が多いのです。この論理的なアドバイスは、何が一般的なケースであるかを理解し、それを理解していることを前提としています。そして、それは慎重なテストと測定を通してのみ可能です。

弁明すると、私は分岐ステートメントが実際にはどのようなものなのか (たとえば、分岐がいくつあるか、定数がどのように分散されているか) を把握しようとしましたが、その情報は 1988 年当時は入手できませんでした。それでも、実際のコンパイラが私の人工的な例に対して最適なコードを生成できなかったときは、特別なケースを追加すべきではありませんでした。

経験豊富な開発者を呼んで、よくあるケースを一緒に考え、具体的に対処すべきでした。そうすればコードは少なくて済みましたが、それは良いことです。Stack Overflowの創設者ジェフ・アトウッドが書いたように、プログラマーの最大の敵はプログラマー自身です。

あなたの善意はよく分かっています。私たち皆もそう思っています。私たちはソフトウェアを書き、コードを書くのが大好きです。それが私たちの性分なのです。どんな問題もダクトテープとハック、そして少量のコードで解決できると思っています。プログラマーにとって認めたくないことですが、最高のコードとは存在しないコードです。新しい行はすべてデバッグし、メンテナンスし、理解する必要があります。新しいコードを追加するときは、他の選択肢が尽きているため、ためらいと嫌悪感を持って行うべきです。多くのプログラマーはコードを書きすぎて、それが私たちの敵になっているのです。

よくあるケースをカバーする、もっとシンプルなコードを書いていたら、必要に応じて更新するのもずっと楽だったでしょう。結局、誰も対処したくないような混乱したコードになってしまいました。

2位：ソーシャルネットワーク上の広告

私が Google でソーシャル メディア広告 (Myspace を覚えていますか?) に取り組んでいたとき、C++ で次のようなコードを書きました。

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

プログラマーならすぐにこのエラーに気づくでしょう。最後の引数はiではなくjであるべきです。ユニットテストではこのエラーは検出されず、テスターも同様でした。実行は完了しましたが、ある夜、私のコードはサーバーに送信され、データセンター内のすべてのコンピューターがクラッシュしました。

何もひどいことは起こりませんでした。グローバルリリース前にコードは単一のデータセンター内でテストされていたため、誰も何も壊しませんでした。SREエンジニアがビリヤードを少しの間中断し、小規模なロールバックを行ったことを除いては。翌朝、クラッシュダンプが添付されたメールを受け取り、コードを修正し、エラーを明らかにするユニットテストを追加しました。プロトコルに従ったため（そうでなければコードはリリースをパスできなかったでしょう）、他に問題は発生しませんでした。

学んだ教訓

多くの人は、このような重大なミスをすると、間違いなく犯人は解雇されるだろうと確信していますが、これは真実ではありません。第一に、すべてのプログラマーはミスを犯しますし、第二に、同じミスを二度犯すことはめったにありません。

実際、優秀なエンジニアだったあるプログラマーを知っています。彼はたった一つのミスで解雇されましたが、面接でそのミスについて正直に話したため、致命的とはみなされず、Googleに採用され（そしてすぐに昇進しました）、その後すぐに昇進しました。

ここに 言う IBMの伝説的な社長、トーマス・ワトソンについて:

約100万ドルの政府発注が発表されました。IBM社、いや、トーマス・ワトソン・シニア個人は、どうしてもこの案件を受注したかったのです。しかし、営業担当者は受注できず、IBMは入札に敗れました。翌日、ある従業員がワトソン氏のオフィスを訪れ、彼の机の上に封筒を置きました。ワトソン氏は封筒を見ることすらしませんでした。従業員を待っていた彼は、それが辞表だと分かっていたのです。

ワトソンは何が悪かったのか尋ねた。

営業担当者は入札について詳細に説明し、犯してしまったミスや避けられたはずのミスを指摘しました。最後に「ワトソンさん、説明させていただきありがとうございます。この注文がどれほど必要だったか、どれほど重要だったか、よく分かっています」と言い、立ち去ろうとしました。

ワトソンは玄関で彼に近づき、彼の目を見つめて封筒を返して言った。「どうして君を手放せるだろうか？君の教育に100万ドルを投資したばかりなのに。」

「もし間違いが本当に教訓になるのなら、私はもう達人だ」と書かれたTシャツを持っています。実際、間違いに関しては、私は博士号を持っているようなものです。

1位: App Inventor API

本当にひどいミスは、膨大な数のユーザーに影響を与え、公になり、修正に長い時間がかかり、避けられたはずの人たちによって犯されます。私の最大のミスは、これらすべての条件を満たしています。

悪いほど良い

私は読む リチャード・ガブリエルのエッセイ 90年代に大学院生としてこのアプローチについて学び、とても気に入ったので学生にも課題として出しています。もし覚えていないようでしたら、思い出してみてください。短い内容です。このアプローチは、「正しく行いたい」という欲求と「悪い方がよい」というアプローチを、シンプルさを含めた様々なレベルで対比させています。

当然のことですが、設計は実装とインターフェースがシンプルであるべきです。インターフェースのシンプルさは実装のシンプルさよりも重要です。

悪いほど良い：設計は実装とインターフェースがシンプルであるべきです。インターフェースの容易さよりも、実装の容易さの方が重要です。

ちょっと忘れましょう。残念ながら、何年も忘れていました。

App Inventor

Googleで働いていたとき、私はチームの一員でした App Inventor初心者向けのオンラインドラッグ＆ドロップ開発環境 Android開発者の皆さん、2009年のことでした。夏に教師向けのワークショップを開催し、秋には教室でその環境を使ってもらえるように、アルファ版を期日までにリリースしようと急いでいました。私はTI-99/4でゲームを作っていた頃を懐かしく思い、スプライトの実装を志願しました。スプライトとは、他のソフトウェア要素と連動して動くことができる2次元のグラフィックオブジェクトのことです。スプライトの例としては、宇宙船、小惑星、ボール、パドルなどがあります。

オブジェクト指向のApp InventorはJavaで実装したので、オブジェクトは山ほどあります。ボールとスプライトの動作は非常に似ているため、X、Y、Speed、Headingというプロパティ（フィールド）を持つ抽象スプライトクラスを作成しました。衝突判定や画面端からの跳ね返り判定など、同様のメソッドを備えています。

ボールとスプライトの主な違いは、描画されるものが何であるか、つまり塗りつぶされた円かラスターかです。スプライトを先に実装したので、画像が配置されている場所の左上隅のx座標とy座標を指定するのは理にかなっています。

スプライトが動作するようになったので、ボールオブジェクトを非常に少ないコードで実装できると判断しました。唯一の問題は、ボールを囲むアウトラインの左上隅のx座標とy座標を指定するという、実装者の観点から最も簡単な方法を選んだことです。

実際、数学の教科書や円について言及している他の資料で教えられているように、円の中心の x 座標と y 座標を指定する必要がありました。

これまでの失敗とは異なり、今回の失敗は同僚だけでなく、何百万人ものApp Inventorユーザーに影響を与えました。彼らの多くは子供だったり、プログラミング初心者だったりしました。彼らは、ボールが動くアプリケーションを開発するたびに、膨大な労力を費やさなければなりませんでした。他の失敗は笑い話で思い出すのですが、今回の失敗は今でも汗水たらして思い出します。

10年経って、つい最近になってようやくこのバグを修正しました。「修正」ではなく「修正」です。ジョシュア・ブロック氏が言うように、APIは永遠だからです。既存のプログラムに影響を与えるような変更はできないため、OriginAtCenterプロパティを追加しました。このプロパティの値は、古いプログラムではfalse、将来のプログラムではtrueです。ユーザーは当然ながら、原点を中心以外の場所に置くことを誰が考えたのかと尋ねるでしょう。一体誰が？10年前にちゃんとしたAPIを書くのが面倒だったプログラマーです。

学んだ教訓

APIに取り組む際（ほぼすべてのプログラマーがいつかは取り組むことになるでしょう）、Joshua Blochのビデオで概説されている最良のアドバイスに従うべきです。優れたAPIを作成する方法とその重要性"または この短いリストの中で:

• APIは大きな利益と大きな害をもたらす可能性がある優れたAPIはリピーターを生み出します。悪いAPIは永遠の悪夢となります。
• パブリックAPIはダイヤモンドのように永遠です全力を尽くしてください。正しく行うチャンスは二度とありません。
• APIノートは簡潔に クラスとメソッドのシグネチャと説明を1行以内でまとめた1ページ。これにより、最初の段階でAPIが完璧でなくても、簡単に再構築できます。
• ユースケースを説明するAPIを実装する前、あるいは仕様策定に取り組む前に、必ず確認しましょう。こうすることで、全く機能しないAPIの実装や仕様策定を避けることができます。

もし仮に簡単なシナリオで要約を書いていたら、おそらく間違いを見つけて修正できたでしょう。もしそうでなければ、同僚の誰かがやってくれていたでしょう。広範囲に及ぶ影響を持つ決定は、少なくとも1日はじっくり考える必要があります（これはプログラミングに限ったことではありません）。

リチャード・ガブリエルのエッセイ「Worse Is Better（悪い方がよい）」のタイトルは、たとえ不完全な製品であっても、他の人が完璧を追い求めて長い時間を費やす中で、市場に最初に参入することで得られる優位性を指しています。スプライトのコードを振り返ってみると、正しく動作させるためにそれ以上コードを書く必要はなかったことに気づきました。私の考えは完全に的外れでした。

まとめ

プログラマーは毎日ミスを犯します。バグだらけのコードを書いたり、スキルや生産性を向上させるようなことを試さなかったり。もちろん、私が犯したような大きなミスを犯さなくてもプログラマーになることはできます。しかし、自分のミスに気づき、そこから学ぶことなしに、優れたプログラマーになることはできません。

自分はミスが多すぎてプログラミングに向いていないと感じている学生によく出会います。IT業界ではインポスター症候群（詐欺師症候群）が蔓延していることは重々承知しています。私が挙げた教訓を皆さんに学んでいただければ幸いですが、肝心なのは、誰もがミスを犯すということです。恥ずかしいミス、おかしなミス、ひどいミスなどです。もし今後、この記事を続けるための材料が足りなくなったら、きっと驚き、そしてがっかりするでしょう。

出所： habr.com