4. 最初に知るべきこと
Updated at: 2015-08-16
すべてはトレードオフ
君は完璧なゲームを作ることができない。 何故なら完璧なゲームなど存在しないからだ。 世の中にはリッチな大作アクションが好きな人もいれば、シンプルなパズルゲームが好きな人もいる。 大衆にウケるようなものを目指すと、売れはするが、全体的に可もなく不可もなくといった仕上がりにはなりがちだ。 逆に特定のターゲットに向けてトガった作品を作れば、一部の人の心を大きく動かすことはできるが、 誰にでもすすめられるようなものにはならないだろう。
何を当たり前のことを、と思うかも知れない。だが当たり前のことを敢えて言語化することは無意味じゃない。 同じような話で、あらゆる技術分野をマスターすることは、人間に与えられた有限の時間では不可能だ。 何を、どういう順番で、どれくらいの時間を使って勉強していくかは、君が選ぶんだ。
仕事においても大小様々なトレードオフの判断が求められる。 品質・コスト・納期の頭文字をとった QCD なんかは代表的な例だ。 普段のコーディングにおいても、アルゴリズムを実装するとなれば CPU とメモリが天秤にかけられる場面は多い。 （参考：時間と空間のトレードオフ）
トレードオフが避けられないのはわかった。重要なのは、何かを選択した時に、 何故それを選択したのかを説明できるようにしておく ことだ。 場合によっては「時間をかければもっと完璧にできるけど、費用対効果が悪いから、今回はこれでいく」 みたいな選択が正解になることもある。
Key Idea:
仕方なくそうするのと、分かっててそれを選んでいるのとでは、大きく違う。
費用対効果、優先度、緊急度、こういったキーワードを手に、トレードオフと向き合おう。
Hint:
たくさんあるトレードオフの中で、その時最適なものを選んでいくことが、 エンジニアリングの仕事であるとも言える。
抽象化がカギ
プログラミングを勉強していると、よく 抽象化 って言葉が出てくると思う。 実際、プログラマの武器でありプログラミングの本質のひとつは抽象化であると僕は思う。 デザインパターン なんかは分かりやすい好例だ。
最初のうちは特定の技術用語（オブジェクト指向だとか、OpenGL だとか） だったり、具体的な実装（Unity でアレをどう動かすのだとか）に目が行ってしまうと思うけど、 慣れてきたら 一体何が本質的な問題なのか を考えてみてほしい。 そうして「こういう問題に対して、こういうパターンで解決している」という具合に 具体的な言葉を省いた 大枠で考えられるようになったら、そこで経験したパターンは君の道具になる。 同じような問題に出くわしたときに、同じように対処できるようになるだろう。
Key Idea:
本質を見抜くと、抽象化できる。
抽象化して捉えられると、応用ができる。
「仕事がデキる人」がデキるのは、こうした応用のパターンをいくつも持っていて、 それを頭で考えずにスッと引き出せるからだ。 「具体的」な言語の文法やツールのコマンドを覚えるのも、 最後には抽象的な知識を得るためのステップだと考えよう。 君が使っている言語やツールは、5 年後には廃れて無くなってしまっているかもしれない。 だがそこで抽象的な知識を得ていたなら、それは新しい環境でも活かせるだろう。
参考文献
達人プログラマー
ピアソンエデュケーション
2000 年の出版でもはや古典となってしまった感もあるが、広く読まれてきたであろう名著。 残念ながら 2014 年に絶版となってしまったようだが、もし手に取ることがあれば読んでおいて損はない。
あらゆる二重化を避けよ、という DRY原則 を始め、 ソフトウェア開発における考え方の基本がまとめられている。
