開発におけるKISSの原則

私たちが解読したPixonic DevGAMM Talksからの次のレポートは少し哲学的です-これはKonstantin Gladyshevによるスピーチです。 彼は1C Game Studiosのリードゲームプログラマーであり、個々の機能ではなく、製品全体のコンテキストで開発の複雑さを管理する原則について話しました。 そして、例を挙げて、開発の主な目的が、すべきでないことを決定することである理由を示しました。 その他のレポートについては、記事の最後にあるリンクをご覧ください。





私は北について話をしたかったが、何をすべきかについての哲学的報告書を作成することにした。 私は、Postal III、Indestructible、War Robotsに取り組み、現在は1CおよびWargamingのオンラインセッションシューティングゲームであるCalibreをやっています。







なぜ私たちはKISSについて話をすることに決めたのですか？ なぜなら、20年以上の経験やCTOを持っている先輩でさえ、しばしば何かを作り続け、発明し続けるからです。 そして、あなたはそれをもっと簡単にする必要があります。 実際、YAGNI（あなたはそれを必要としません）と哲学のビットについての詳細があります。



私は、「find x」のような完全にばかげた解決策について話しているのではなく、多かれ少なかれ単純な解決策について話しているとすぐに言わなければなりません。







なぜそれが難しいのですか？ それはすべて善意から始まり、ご存じのように地獄に至る。 これについての漫画があります。







この理由はほぼ同じですが、私はそれらを異なる方法で呼び出しました：

• ユニバーサルソリューション 。 ある種の機能があり、すぐにライブラリを作成します（100万件の追加ケース）。 そして、突然私たちの射手は農場に変わりますか？ または、「次回はまったく同じシューティングゲームをもう1回行います」。 ほとんどの場合、変更されることはありません。
• 将来の証拠 。 ほぼ同じこと-これらは存在しない問題です。 「そして、すぐに100万人のユーザーがいる場合、22台の中間サーバーに耐える必要がありますか？」など。 獲得を開始するには、1台のサーバーで十分です。
• 間違ったツールを使用する 。 当てはまらず、妄想にとらわれないツールを使用するとき。
• そして誰もが時期尚早の最適化を知っています。

彼らがキャリバーを作ったときの例がありました。 私たちを助けてくれた人たちは、すぐに最新のC ++でスーパーシリアライザーを作ることにしました。



その結果、テンプレートが必要な場所、必要な場所、またはフラグを作成したかどうかを実際に理解していないため、部分的な状態を送信するのは不便でした。 この定型コードにあったバグは、作者でさえ時間の経過とともに理解できませんでした。







その後、わずか2時間でプログラマーの1人がこのすべてを1ページのCコードで書き直しました。 そして、それは素晴らしく機能しました。



別の例。 Postal IIIがあり、それはSourceエンジンで作成されました。 このような開かれた世界があり、地図、三人称カメラ、窓のある1階建てのアメリカンスタイルの家の間を歩くことができます。 その結果、BSP全体が機能しませんでした。 それは非常に長い間考えられていました、窓のためにそれは百万のセクターになって、まだ何もしませんでした。 大量のメモリを消費し、長時間ロードされていました。







エンジンが作られたHalf-Lifeは一人称シューティングゲームであり、3番目からは、いくつかのことを行うのが不便でした。 Half-Lifeの有用なものはすべて私たちに合わなかった。 また、第三者から登る必要があるなどの理由で、大量のアニメーションが行われることになっています。 エンジンを変更する必要がありましたが、オプションはありませんでした。



すべてが悪く、難しいが、彼らは私たちを押したときに何をすべきか？ 第一に、適切な順序で機能を実行することです。事前に最適化することが問題の1つであるためです。 一部の人は、ドレスを縫う前にストラシックを貼り始めますが、ストラジックが干渉するため、縫うことができません。



最初に最も単純なチップを作成して、動作するようにし、安定化してから最適化します。 他のすべてが間違っているのはこの順序です。







視覚化により、最小限の操作性、つまり MVP（最小の実行可能製品）。







次に、その可能性を評価します。 ゲームデザイナーが機能を考え出し、プログラマーが「私はうまくやる、悪いことはしないので、すぐにファンキーなゲームデザインを描く」と言います。 しかし、彼はどのように知っていますか？ 彼はプレイしなかった、それが良いか悪いかを知りませんでした。 したがって、理想的には、フィーチャーを作成し、通常であればプレイし、さらにそれを実行します。 普通じゃない-捨てられて、残念ではない。



千年前、孫子は100の戦いに勝つことはピークではなく、ピークは戦いなしで勝つことだと言いました。 つまり できないことをしないでください。



安定化。 機能を作成し、不要な追加なしでさらに安定させました。 あなたは、木の上で、ロープで、車輪が必要ですか？ ぶら下がっています。 これ以上。







したがって、機能が変更されるべきであることが突然発見された場合（将来の証拠なしで）-再起動します。 ただ試して、安定させ、先を推測しようとしないでください。 あなたはまだ推測しません。



まあ、時期尚早の最適化。 これは常に悪いことです。 最後に最適化する必要があります。この機能が重要であることが確実な場合、最適化する必要があり、近い将来根本的に変更されることはありません。







最適化は特殊な​​ケースのセットだからです。 原則として、コードの可読性が悪化し、抽象化が壊れ、移植性も大幅に悪化します。







松葉杖は本当に悪いので、これは挑発的なスライドです。 しかし、ここでは、退屈な機能やプロトタイプがたくさんあり、すべてが悪く、すべてが崩壊するように見える状況が示されています。 しかし、これはそうではありません。 見てください-これは型枠であり、コンクリートが注がれています。そして、「割れ目」が乾いている間に支えられます。 つまり 状況は絶対に正常です。その後、パニックなしで「クランチ」は削除されますが、すぐには削除されません。



簡単に哲学について。 普遍的に有効なソリューションはありません。 フレームワークを100年前またはすべての機会に作成しようとしないでください。







仕事を上手くこなす小さなピースをたくさん作ってください。 できるだけ早く不要なものを捨て、それをサポートしようとしないでください。 そして、コードを書くときは、明示的にします。 時には、反射や他の何かではなく、手でシリアル化する明示的なコードを書くほうが良い場合があります。 必要のない依存関係アクションを使用することも悪い考えです。 読むのは非常に難しく、実行時のエラーの半分です。 明示的は暗黙的よりも優れています。 そして、誰かが何かを理解していなかったり、完全に忘れてしまった場合でも間違いを避けるために、できるだけシンプルにします。



ブルース・リーが言ったように、シンプルさが最高の芸術です。 かつて彼がジークンドーを教えた俳優が彼に尋ねました：「あなたの格闘技ジークンドーの本質は何ですか？」 その瞬間、ブルース・リーは財布を落とし、俳優がそれを拾い上げ、ブルース・リーは言った。

聴衆からの質問

「時期尚早な最適化は悪だと言っていました。」 プロジェクトが始まったばかりのときに時期尚早のテストを書くことは価値がありますか？



-私の理解では、早すぎるものはすべて有害です。 テストでは、私はあまり強くありません。ゲーム開発（多くの場合）では、テストが開発の終わりに近づくからです。 最初は、すべてが急速に変化するため、テストの作成中に、ゲームデザイナーはすべてを変更します。 2時間で何が変わるかをテストすることにエネルギーを費やすのは良くないと思います。 これは、安定化段階で行う必要があります。 しかし、プロトタイプ段階ではありません。 しかし、チームがテストをすばやく作成できる場合、これはおそらく良いことです。 そうでない場合は、いいえ。



-松葉杖は削除されるとおっしゃいましたが、素晴らしい論文があります-一時的なものよりも永続的なものはありません。 私たちは皆ゲーム開発に携わっており、締め切り、プロデューサー、新機能などがあります。 松葉杖を片付けている状況をどれくらい頻繁に見ましたか？ そして、彼らはそれらをゼロにしましたか？



-おそらくゼロではありません。 プロジェクトが稼働している場合、常に松葉杖を使用できます。 それらが体系的にクリーニングされれば、すべて機能します。 つまり 機能を作成しました-すぐに修正されました。



-つまり 社内に特定のプロセスを構築する必要がありますか？ 松葉杖の公式クリーニングフェーズの種類は？



-はい、これはタスクに含めるべきだと思います。 つまり タスクのプロセスでリファクタリングする必要がある場合は、リファクタリングします。 おおまかに言って、リファクタリングという言葉でさえも、そうではありません。それはタスクの中にあります。



-実際にこれを行うことができますか？ プロデューサーのところに来て、新しいイテレーションを計画する際に、クリーンアップ、リファクタリングなどに2週間かかると言います。 そして、彼はビジネス価値はゼロだと言います、今私たちは機能xをします、そしてあなたは仕事の後の夕方にそれをきれいにします この状況になるには？



-成功しました。 プロデューサーは、あなたが是正している債務があることを、タイムリーに知っています。 新しいリリースがあるわけではなく、新しい機能は1つもありませんが、ここには何らかのリファクタリングがあります。 適切なプロデューサーを選択するだけです。



「経験を積むと、理解はよりシンプルになります。」 しかし、初心者プログラマーは、複雑で怖い、大規模で巨大なシステムを作成しようとします。 質問：難しい「いいえ」を除いて、これを防ぐ方法は？



-これは学習の問題だと思います。 どのソリューションが機能するか、機能しないソリューション、およびその理由をできるだけ早く示す必要があります。 経験があり、なぜこれを行う必要がないのかを説明できる場合は、多くの例を挙げるだけで十分に機能します。 すべてを簡単にするために、独自の例を使用して常に監視します。 プロトタイプを作成して、より頻繁に書き換えるようにします-頻繁に書き換えるときは、あまり書く必要はなく、より簡単に書くことができます。



-既にいくつかのプロジェクトで使用されている非常に複雑なものがあり、この複雑さはもはや役に立たず、むしろ干渉する場合-簡単なソリューションに切り替えるのはどれくらい簡単ですか？



-私の意見では、もう一度やり直してください。 理想的には、最初からまったく別のチームです。 ほとんどの場合、機能の80％を非常に迅速に回復します。 新しくてきれいなライブラリ。 そして、あなたは追いつくでしょう。



-たとえば、ゲームロジックの強力なシリアライザーとエディターがありますが、ここではかなり時代遅れです...



-これらは同じ不便なツールです。 快適に。 たとえば、Unity。



-コードの計画を教えてください。どのくらい詳細ですか？ メインプログラマは、すべての小さな問題、すべてのタスクを解決しますか？



-私たちにはそのような無秩序があり、多くの人々ではなく、かなりフラットな構造です。 私たちは皆を信頼し、誰がプロトタイプを採用し、誰が採用しないかを単に配布します。 任意の人物を指定できます。

Pixonic DevGAMM Talksとのさらなる講演

• Consulを使用したステートフルサービスのスケーリング （Ivan Bubnov、DevOps at BIT.GAMES）;
• CICD：ダウンタイムなしの分散クラスターシステムへのシームレスな展開 （Egor Panov、Pixonicシステム管理者）;
• Quake Championsゲームのバックエンドプラットフォームでアクターモデルを使用する練習 （Roman Rogozin、バックエンド開発者Sabre Interactive）。
• Tacticoolモバイルオンラインシューターメタサーバーアーキテクチャ （Pavel Platto、PanzerDogのリードソフトウェアエンジニア）;
• ECS、C＃ジョブシステム、SRPがアーキテクチャへのアプローチをどのように変えるか （Valentin Simonov、Unityのフィールドエンジニア）;
• クライアントとサーバーの一般的なゲームロジック （Pixonicの副技術責任者、Anton Grigoriev）。
• Cucumber in the Cloud：製品ストレステストにBDDスクリプトを使用 （ALICE Platformのテクニカルプロダクトマネージャー、Anton Kosyakin）。