よく言われるように、古いコードを恥じないのであれば、プログラマとして成長していないことになります。私もこの意見に同意します。 私が趣味でプログラミングを始めたのは 40 年以上前、専門的に始めたのは 30 年前なので、間違いもたくさんあります。 とても。 コンピューター サイエンスの教授として、私は学生たちに、彼らの間違い、私の間違い、そして他の人の間違いから学ぶように教えています。 謙虚さを失わないよう、自分の間違いについて話す時期が来たと思います。 誰かの役に立つことを願っています。

XNUMX位 - Microsoft Cコンパイラ

私の学校の先生は、登場人物には悲劇的な罪はなく、十代の若者らしく愚かな行動をとっただけなので、ロミオとジュリエットは悲劇とはみなされないと信じていました。 当時、私は彼の意見に同意しませんでしたが、今では、特にプログラミングに関連して、彼の意見に一片の合理性が見られます。

MIT の 86 年目を終える頃には、私はまだ若く、人生においてもプログラミングにおいても経験が浅い状態でした。 夏に、私は Microsoft の C コンパイラ チームでインターンをしました。最初はプロファイリングのサポートなどの日常業務を行い、その後、コンパイラの最も楽しい (私が思っていた) 部分であるバックエンドの最適化に取り組むことを任されました。 特に、分岐ステートメントの xXNUMX コードを改善する必要がありました。

あらゆるケースに最適なマシンコードを書こうと決意し、私は真っ逆さまにプールに身を投じました。 値の分布密度が高かった場合は、 遷移表。 公約数がある場合は、それを使ってテーブルをより緊密にしました (ただし、それを使用して割り算ができる場合に限ります)。 ビットシフト）。 すべての値が XNUMX の累乗になったときに、別の最適化を実行しました。 値のセットが条件を満たさない場合は、それをいくつかの最適化可能なケースに分割し、すでに最適化されているコードを使用しました。

それは悪夢だった。 何年も経ってから、私のコードを引き継いだプログラマーが私を嫌っていると告げられました。

学んだ教訓

David Patterson と John Hennessy が『Computer Architecture and Computer Systems Design』で書いているように、アーキテクチャと設計の主な原則の XNUMX つは、一般的に物事をできるだけ早く機能させることです。

一般的なケースを高速化すると、まれなケースを最適化するよりも効果的にパフォーマンスが向上します。 皮肉なことに、一般的なケースは、まれなケースよりも単純であることがよくあります。 この論理的なアドバイスは、どのケースが一般的であると考えられるかを知っていることを前提としています。これは、慎重なテストと測定のプロセスを通じてのみ可能です。

私を弁護するために、私は分岐ステートメントが実際にはどのようなものであるか (分岐の数や定数がどのように分散されているかなど) を把握しようとしましたが、1988 年にはこの情報は入手できませんでした。 ただし、現在のコンパイラーが私が思いついた人為的な例に最適なコードを生成できない場合は、特別なケースを追加すべきではありませんでした。

経験豊富な開発者に電話して、よくあるケースが何なのかを一緒に考え、具体的に対処する必要がありました。 書くコードは減りますが、それは良いことです。 Stack Overflow の創設者 Jeff Atwood が書いているように、プログラマーの最大の敵はプログラマー自身です。

私たち全員がそうであるように、あなたも最善の意図を持っていることは知っています。 私たちはプログラムを作成し、コードを書くのが大好きです。 そのように私たちは作られています。 私たちは、どんな問題もダクトテープ、手作りの松葉杖、そしてひとつまみのコードで解決できると考えています。 プログラマーにとってそれを認めるのはつらいことですが、最良のコードは存在しないコードです。 新しい行はそれぞれデバッグとサポートが必要であり、それを理解する必要があります。 新しいコードを追加するときは、他のすべての選択肢が使い果たされているため、気が進まず嫌悪感を持って追加する必要があります。 多くのプログラマーはコードを書きすぎるため、それが私たちの敵となっています。

一般的なケースをカバーする単純なコードを作成していれば、必要に応じて更新するのがはるかに簡単になったでしょう。 私は誰も対処したくない混乱を残しました。

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

私が 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 である必要があります。 単体テストではエラーが明らかにならず、レビュー担当者も同様でした。 打ち上げが実行され、ある夜、私のコードがサーバーに送信され、データセンター内のすべてのコンピューターがクラッシュしました。

悪いことは何も起こりませんでした。 世界的な公開前にコードは XNUMX つのデータセンター内でテストされていたため、誰にとっても問題はありませんでした。 SRE エンジニアがしばらくビリヤードをやめて、少しロールバックしない限りは。 翌朝、クラッシュ ダンプが記載された電子メールを受け取り、コードを修正し、エラーをキャッチする単体テストを追加しました。 私はプロトコルに従っていたので、そうでなければ私のコードは単に実行に失敗するだけでしたが、他には問題はありませんでした。

学んだ教訓

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

実際、私の友人にプログラマーがいますが、彼は優秀なエンジニアでしたが、たった一度のミスで解雇されました。 その後、彼は Google に採用されました (そしてすぐに昇進しました)。彼は面接で犯した間違いについて正直に話しましたが、それは致命的とは考えられませんでした。

ここに 言う IBMの伝説的なトップであるトーマス・ワトソンについて：

約XNUMX万ドル相当の政府命令が発表された。 IBM Corporation - というかトーマス・ワトソン・シニア個人 - は本当にそれを手に入れたかったのです。 残念ながら、営業担当者はこれを行うことができず、IBM は入札に敗れました。 翌日、この従業員はワトソン氏のオフィスを訪れ、机の上に封筒を置きました。 ワトソン氏はそれを見ようともしなかった。彼は従業員を待っていたので、それが辞表であることを知っていた。

ワトソンは何が問題だったのかと尋ねた。

営業担当者は入札の経過について詳しく話した。 彼は避けられたはずの犯した間違いを挙げた。 最後に彼はこう言いました。「ワトソンさん、説明させてくれてありがとう。 私たちはこの命令がどれほど必要だったかを知っています。 彼がどれほど重要だったかはわかっています」と言い、出発の準備をしました。

ワトソンはドアのところで彼に近づき、目を見つめて次の言葉を書いた封筒を返しました。 私はあなたの教育に XNUMX 万ドルを投資しました。

私は「失敗から本当に学ぶことができるなら、私はすでに達人だ」と書かれた T シャツを持っています。 実際、エラーに関して言えば、私は理学博士です。

XNUMX位：App Inventor API

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

悪いほど良い

私は読む リチャード・ガブリエルのエッセイ 私はこのアプローチが XNUMX 年代に大学院生だったときに聞いたことがあります。私はそれがとても気に入っているので、学生たちにも尋ねています。 よく覚えていない場合は、小さなことなので記憶を更新してください。 このエッセイでは、「正しくやりたい」という願望と「悪いほうが良い」というアプローチを、シンプルさを含むさまざまな方法で対比させています。

どうあるべきか: 設計は実装とインターフェイスがシンプルである必要があります。 インターフェイスのシンプルさは、実装のシンプルさよりも重要です。

悪いほど良いです。設計は実装とインターフェイスがシンプルである必要があります。 実装の単純さは、インターフェイスの単純さよりも重要です。

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

App Inventor

Google で働いていたとき、私はチームの一員でした App Inventor、意欲的な Android 開発者向けのドラッグ アンド ドロップのオンライン開発環境。 それは 2009 年のことでしたが、私たちは夏に教師向けのマスター クラスを開催し、秋の指導時にこの環境を使用できるように、アルファ版のリリースに間に合うように急いでいたのです。 私は TI-99/4 でゲームを書いていたことを懐かしく思い、スプライトの実装を志願しました。 知らない人のために説明すると、スプライトは、移動して他のソフトウェア要素と対話できる XNUMX 次元のグラフィック オブジェクトです。 スプライトの例には、宇宙船、小惑星、ビー玉、ラケットなどがあります。

オブジェクト指向の App Inventor を Java で実装したため、そこには大量のオブジェクトが存在します。 ボールとスプライトは非常によく似た動作をするため、プロパティ (フィールド) X、Y、Speed (速度)、Heading (方向) を持つ抽象スプライト クラスを作成しました。 衝突や画面の端からの跳ね返りなどを検出する方法は同じでした。

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

スプライトが機能するようになると、非常に少ないコードでボール オブジェクトを実装できると判断しました。 唯一の問題は、ボールを囲む輪郭の左上隅の x 座標と y 座標を示すという、(実装者の観点から) 最も単純なルートを選択したことです。

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

私の過去の間違いとは異なり、今回の間違いは私の同僚だけでなく、何百万もの App Inventor ユーザーに影響を与えました。 彼らの多くは子供か、プログラミングに全く慣れていない人でした。 ボールが存在する各アプリケーションで作業するときに、多くの不必要な手順を実行する必要がありました。 他の失敗を笑いながら思い出すと、この失敗は今でも汗ばみます。

XNUMX 年後、ようやくこのバグにパッチを当てたのはつい最近のことです。 Joshua Bloch が言うように、API は永遠であるため、「修正」ではなく「パッチ」が適用されます。 既存のプログラムに影響を与える変更を加えることができないため、古いプログラムでは false の値、将来のすべてのプログラムでは true の値を持つ OriginAtCenter プロパティを追加しました。 ユーザーは、開始点を中心以外の場所に置くことを誰が考えたのかという論理的な質問をするかもしれません。 誰に？ XNUMX 年前、あまりにも怠惰すぎて通常の API を作成できなかった、あるプログラマーへ。

学んだ教訓

API に取り組むとき (ほぼすべてのプログラマーが時々やらなければならないことがある)、Joshua Bloch のビデオ「」で概説されている最良のアドバイスに従う必要があります。優れた API を作成する方法とそれが非常に重要な理由"または この短いリストの中で:

• API は大きな利益と大きな害の両方をもたらす可能性があります。。 優れた API はリピーターを生み出します。 悪いものは永遠の悪夢になります。
• パブリック API はダイヤモンドのように永久に残ります。 全力を尽くしてください。すべてを正しく行う機会は二度とありません。
• API の概要は簡潔にする必要があります — クラスとメソッドのシグネチャと説明が XNUMX 行以内で記載された XNUMX ページ。 これにより、最初は完璧な結果が得られなかった場合でも、API を簡単に再構築できるようになります。
• ユースケースの説明API を実装する前、またはその仕様に取り組む前に。 こうすることで、完全に機能しない API の実装と指定を回避できます。

もし私が人工的なスクリプトで短いあらすじでも書いていたら、おそらく間違いを特定して修正したでしょう。 そうでないなら、私の同僚の誰かが間違いなくそうするでしょう。 広範囲に影響を与える決定は、少なくとも XNUMX 日は考える必要があります (これはプログラミングに限らず当てはまります)。

リチャード・ガブリエルのエッセイのタイトル「Worse Is Better（悪いほど良い）」は、誰かが完璧な製品を永遠に追い求める一方で、たとえ不完全な製品であっても、最初に市場に投入することで得られる利点を指します。 スプライト コードを振り返ってみると、正しくするためにさらにコードを記述する必要さえなかったことがわかりました。 誰が何と言おうと、私は大間違いでした。

まとめ

プログラマーは、バグのあるコードを書いたり、スキルや生産性を向上させる何かを試したくないなどの理由で、毎日間違いを犯します。 もちろん、私のように重大な間違いを犯さなくてもプログラマーになることはできます。 しかし、自分の間違いを認識し、そこから学ばなければ、優れたプログラマーになることは不可能です。

私は、間違いが多すぎてプログラミングには向いていないと感じている学生に常に出会っています。 IT 業界で詐欺師症候群がいかに一般的であるかを私は知っています。 私が列挙した教訓を学んでいただければ幸いですが、重要な教訓を覚えておいてください。私たちは誰でも間違いを犯すものです。恥ずかしいこと、面白いこと、ひどいことです。 将来、記事を続けるのに十分な資料がなかったら、私は驚き、動揺するでしょう。

出所： habr.com