ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

結論ルールを自分のものにする

　本書で説明してきたルールは、Sucker Punchが存在してきた四半世紀にわたる歴史の中でぼくらが学んだ教訓の精髄を抽出したものだ。ルールは、ぼくらの経験に特有なものだ。ぼくらが重要だと考えていること、つまりぼくらのプログラミング文化を反映しているのがルールだ。そして、そのプログラミング文化は、Sucker Punchが開発する類のビデオゲームを作る際に特有な、制約や特徴を反映している。

　ここまで、きみはたくさんのルールを読んできた。きみがやっている仕事に当てはまるのがすぐさま分かったルールもあれば、きみの経験とのつながりがどちらかというと薄いと感じられるルールもあるんじゃないかと推測している。そいつは、驚くようなことじゃない！ きみがやっているプログラミングの仕事が、ぼくらがやっている仕事と根本的に違うなら、ぼくらのルールの中に、きみにとって意味をなさないものがあるかもしれない。

　では、ぼくらの作品のようなビデオゲームのコードを書くというプロセスを、他と一線を画すものにしている特性とは何なのか。そしてそれが、ルールにどう影響してるんだろうか？

• まず、ぼくらのプロジェクトは長い。ぼくらの最新作である『Ghost of Tsushima』は、制作に6年ほどかかった。『Ghost of Tsushima』のコードのほとんどは、Sucker Punchの以前のゲームで動作していたコードを進化させたもの（あるいは単にそのままコピーしたもの）で、ゼロから始めたわけじゃない。ぼくらは、長期的なコード品質に重きを置いており、それはぼくらがそうせざるをえないからだ。今日書くコードが、今から10年後もまだ稼働している可能性は、十分ある。
• コーディングチームは大きく、現在30人あまりの正社員コーダーが在籍している。きみ自身の状況によって、ちっちゃいと感じるかもしれないし、すごく大きいと感じるかもしれない。個人的には、「小さい」プログラミングチームとは、1人の人間が全てのコードの詳細をくまなく把握できるようなチームと定義している。その基準に照らし合わせると、Sucker ...