翻訳者から
翻訳が少し緩いことをおaびします。 私はアイデアをできるだけオリジナルに近づけるように努めましたが、同時にテキストをもう少し結び付けました。 オリジナルでは、これは転写であり、非常に複雑です。
また、「コンピュータサイエンス」というフレーズの翻訳がないこともおpoび申し上げます。 ロシア語には適切なフレーズがありません。 あらゆる種類の「コンピューターサイエンス」と「コンピューターサイエンス」は、信用を失った概念か、意味のない翻訳の代用物です。 「コンピューターサイエンス」という英語の概念には、ロシア語への翻訳では「コンピューティング、情報処理、コンピューティングデバイスの科学」のような歴史的なしゃれが含まれています。 元の「コンピューターサイエンス」のままにしておく方が良いと思います。 いずれにせよ、この形式では、このフレーズを使用すると、オリジナルで表現されている多様性から適切なコンテキストを選択できます。
なぜ私はこのテキストを翻訳することに決めたのですか（それは短く、啓示であまり飽和していないため） これはカーマックのパフォーマンスだからです。 そして、結局のところ、彼はソフトウェア開発業界の重要な人物です。 以下に書かれていることは、ソフトウェア開発の理論と実践の分離を示しています。 結局のところ、これらの考えがそのような開発者を訪問し、QuakeConに提出された場合、通常のアプリケーションプログラマの心の中では何が起こっているのでしょうか？
転写の著者、アンドリュー社から
私はコンピューターゲームには特に熱心ではありませんが、それでもプログラミングの趣味です（レンダリングアルゴリズムから始めました）。 そのため、 QuakeCon 2012でJohn Carmackがテープで話しているのを見たとき、私は彼に耳を傾けるべきだと思いました。 突然、コンピューターゲームの作成について何か新しいことを学びましたか？
実際、「すべてのプログラマーの中で最もプログラマー」が、ソフトウェア開発が社会学の応用面であることに最近気付いたという話を聞きました。 10分間、彼は開発者のエラー、プログラミング言語の開発、静的分析、コードテスト、開発者トレーニング、費用便益分析に関連する人的要因について話しました。
以下は、このスピーチの私の転写です。 エラーについては事前におaび申し上げます。
ジョン・カーマックによるスピーチ
ゲームを高速化するために（実際、これが私たちを前進させるものです）、Doom 4コードで多くのミスを犯しました。 させて これらのエラーは、何らかの形で過去に残ります。 しかし、ゲームを高速にしたいという願望は必須です。 6年ごとに新しいゲームをリリースすることはできないからです。
ソフトウェア開発について話すと... E3で1つのインタビューを行いました。私は絶えず勉強していて、毎年新しい年にプロの観点から自分自身よりも成長していると言いました。 インタビュアーはまだ驚いていました。どうやって20年間自分自身で成長できたのでしょうか？ しかし、実際、私は自分自身のスキルの面でも、ソフトウェア開発のチームプロセスのダイナミクスの理解の面でも、自分よりかなり貧弱に成長していました。 おそらく、私は意図的にこの瞬間に何年も注意を払わなかったのです。なぜなら、あなたは、自分が一種の科学者でありエンジニアであるという誘惑があり、抽象的な概念があること、証明可能なものがあることを断固として宣言するからです。しかし、そこには客観的です。 これが「コンピューターサイエンス」です。 科学。
次に、この瞬間が何であるかを説明します。
現実には、そうではありません。 「コンピューターサイエンス」では、アルゴリズムを「自分のもの」として話すとき、あなたは科学者です。 アルゴリズムを最適化すると、エンジニアになります。 しかし、アルゴリズム（科学的部分）と最適化（工学的部分）は、プログラミングプロセス自体と比較するとささいなことです。
最適化とアルゴリズムのみを扱うプログラマーはほとんどいません。 プログラマの90％は通常のルーチンを実行します。 スケルトンを歩かせる肉。
彼らがどのように、何をしているのかを理解し始めたとき、私は彼らの仕事に科学がなく、エンジニアリングも、オブジェクトアプローチでさえないことに気付きました。 ご存知のように、これらのプログラマーの一人は、彼は猿として働いているとさえ言っています-彼はいくつかの小さな応用問題を解決する愚かなコードを書いています。
あなた（そして正直に言って私）は、私たちがスマートエンジニアであり、優れたソフトウェアを書くための学術的な方法があると考えるのが好きです。 しかし、これをすべて見るほど、学問的な問題はそうではないことを理解します。
科学ツールを使用して、測定、再現、評価、検証を行い、何かを測定および再現できます。 その後、特定のアルゴリズムを選択し、場合によってはそれらを最適化することもできます。 しかし、次に行う他のすべては、科学や工学とは関係ありません。 それ以外は、プログラマー間の社会的相互作用の問題です。 あるいは、異なる時点で自分自身と一緒にいるプログラマでさえも。
ここでは、例えば、関数型プログラミング、ラムダ計算、モナドについて話し始めることができます-それはすべて美しく、非常に科学的なものです。 しかし、これはすべてあなたが開発しているものに正確には影響しません。 はい、これらの「テクニック」と便利な機能により、抽象的な開発者が作成した特定のクラスのエラーを排除できます。 しかし、あなたは知っています、純粋な関数型言語を使用して私ができることはすべてです（そして、これはあなたが知っているように、最も学術的、科学的、厳密に形式化された問題解決方法です）-これはすべて、変換先のアセンブラーコードに正確に変換されます一部のBASICまたは選択した他の何かに実装された同様のソリューション。
これに関して、私は長男と一緒に例を挙げたいと思います-彼は今、プログラミングを学んでいます。 私は実際に考えていました-そして、7歳で彼にHaskellのような何かを教えたくないですか？ これらの考えをこれ以上動かさないように十分な常識を持っていたことは良いことです。 そして、私はHaskellをあまり知らないので、プログラミングをゼロから学んでいる他の人に教えることができなかったからではありません。 いや
私は、これはすべて、プログラミングコミュニティでは不当に暗示され、当然のこととされている、真に基本的な知識の上にある人為的な階層化にすぎないことを発見しました。
関数型プログラミングから構造型プログラミングに戻ったとしても、その間やサイクルからコンピューターの動作を説明するまでのプログラミングコースのこのセマンティックウールはすべて、たとえばフローチャート上のセマンティックアドインにすぎません。
「これなら、これ、そうでなければこれ、これではない。」 特定の目的でwhileループまたはforループを使用する理由の説明。 これらは、ソフトウェアを開発するときによくある間違いを避けるのに役立つ規則です。 さらに、そのようなすべての合意と説明は、コンピューター内部で実際に起こることとは何の関係もありません。 彼らは人々がよくある間違いをするのを止めることだけを意図しています。 すべての人によって、絶え間なく持続的に行われるこれらの間違い。
プログラマーがある程度の頻度でミスをしなければならないことに気づくまでに長い時間がかかりました。 昨年、特定された何百もの問題を取得した結果、静的解析に精通し、すべてのコードを実行したという事実について多くのことを話しました。 そして、これは非常にクールです-今、あなたは物語を上げ、「見て、ここで私は間違いを犯した」と言って、間違いが犯された場所をみんなに見せることができるからです。 誰もが自分自身を見て、注意します。 うーん、これを防ごうと思います。」 これは良いことですが、問題は影響ではなく原因にあります。 構文で何かを誤って実装できる場合、この「何か」は誤って実装されます。 そのため、静的分析を入力することに加えて、言語ツールの表現力をより強く制限し、それによってプログラマーが間違いを犯さないようにしたいと考えています 。
最近では、毎日のコード検査を実施し、変更点について調査し、チームとの議論を示唆する何かを探し始めました。 私は小さなコードを見て、エラーがどこにあるかについて話します。 実際、生きているコードのバグを示すことは、それほど大きな社会的悪ではありません。 生きたコードは作成者に安心感を与えますが、可視性でエラーの性質を示し、コマンドでさらに広がることを防ぎます。 これは、個々のコード検査よりもはるかに効果的です。 チームはすでにマスターしていると思うし、一般公開で間違いを犯しても不快感を感じることはない。
さらに、一部の非自明な場合（たとえば、関数パラメーターにconst指定子を配置する場合）、客観的に視点を明確にすることができます（「このリダイレクトはキャッシングのリストです」、「指定子の欠如により、そのようなコンピューティングリソースが消費されます」、 「これらのリソースを測定できます」）-同時に、可能な限り理由付けられた説明を行います。 実際、 特定の主題分野での経験と長年の仕事により、問題に遭遇し、それについて話すことがよくあります。 そして、人々はあなたの言葉に応えて、「いいえ、私はこれを見ていません。 いいえ、私にとってこれは問題ではありません。 私はそのような過ちを犯しません 。 」
ありふれた人間の悪に対処できる科学がないことに気づくほど、これらの悪を克服する何らかの方法を見つけたいと思いました。 結局のところ、私たち全員が最高の開発者になり、最高の製品をリリースし、私たちの仕事を最大限にしたいようです-しかし、同時に、同じことをする何十人もの交換可能な労働者を訓練します。 結局のところ、私たちは仕事をしていることを知っています。 私たちは人々が行き来することを知っています。 私たちは、プロジェクトの新しい人々がコードを見て、その目的とスタイルの規則を理解していないことを知っています。 そして、おそらくそれをすべて良くしたり悪くしたりする方法があることを知っていますが、これらの方法を形式化することは非常に困難です。
私はこれらの方法を探すためにますます多くの時間を費やしています。 たとえば、NASAソフトウェア開発ラボのレポートを見て、開発中のほとんどの製品の価値と目的をまだ理解していませんでした。 多かれ少なかれ価値のある製品はすべて完全に自動化され、人間の介入なしに分析や計算を実行したか、何らかの決定を下しました。 最初は、プロジェクトが成長するにつれて、コードベースの量がNASA製品にますます近づき、NASAが使用するのと同じ方法を使用する必要があると考えました。 しかし、残念ながら、NASAのレポートとプロジェクトのコードベースのサイズを見ると、3〜40万行のコードを持つプロジェクトは「大」と呼ばれます。 ゲームエンジンにはさらに多くのコードがあります。 一般に、ゲームエンジン（コンピューターゲームを活気づける）は、月への往復飛行を制御したり、シャトルを制御したり、SkyLabを動作させたり、軌道ステーションで動作させたりするソフトウェアよりも複雑です。
真実はどこか近くにありますが、NASAの方法論にはありません。 それらのアプローチを使用すると、非常に正確なコードを取得できますが、生産性は非常に低くなります。 残念ながら、私たちの仕事は費用便益分析に基づいており、この場合、「完璧主義者になることができますが、出力は必要なソフトウェアではなく、期限は切れます」と書かれています。 他方、もしあなたが速く働いたら（おそらくあまり注意深くないかもしれませんが）、かなりクールな製品を手に入れることができます。 そして、短時間で。 しかし、ここでは、適切なツールを使用して適切に構造化された作業を行うことで問題が発生します。この問題を解決することなく、すぐに「クール」なソフトウェアを手に入れることができるからです。 残念ながら、ワークフローを構築するための2つのオプションの間で妥協案を選択する上で、私たちはまだ成長する余地があると思います。
私たちは、コードが生きる理由と方法を知っています。 真剣に、私たちは10年を楽しみにしています。 私は、彼らが今書いたコードは（もちろん、特定のゲームに焦点を合わせていないなら）10年は生きることができると言っています。 そして、このコードは何百人ものプログラマーによって使用されます。 彼らはそれを読み、何らかの方法でそれに対処しますが、これは重大な責任です。 私は、過去に残るものと私たちが生き続けるものとの分析と分離のために、非常に厳しい要件を作らなければならないと確信しています。 残念ながら、これに加えて、マルチレベルAPIの開発には膨大な数のニュアンスがあり、他にも多くの明白でないものがあります-そしてそれらはすべて、巧妙で創造的なアプローチを必要とします。 このような繊細な素材を扱うツールをもっと増やしたいです。 そして、私はそのようなツールが私たちと共に現れるのに多くの時間を費やします。