仮実装はいつまでも残る

ここ1年ほど、仕事で大人数が関わるゲームの開発に、プログラマとして携わっている。
人生で、この規模の人数がいる開発に関わったことがないので、日々学びだらけ。

今の仕事で一番感じているのは「仮実装は悪」だということ。かつて自分が/誰かが用意した仮実装が、後々になって牙をむくというケースが続発している。

本記事中での「仮実装」の定義

本記事中で言う「仮実装」とは、

• 動いているところを見せるために作る、バリデートなど本来必要な処理を抜かした、いい加減な実装

• 時間がない中書いた、リファクタリング必須の醜いコード
  のことを指す。
  要は、「後で直す必要があることがわかりきっているコード」のこと。

テスト駆動開発（TDD）における、テストを通すだけに用意する実装のことは、今回取り扱わない。（テスト駆動開発したことないので分からない…）
TDDユーザーには申し訳ないが、仮実装以上にしっくりくる名称が思い浮かばなかったので、許してほしい。

仮実装の功罪

仮実装をしたときは、まともなエンジニアならその瞬間は「いつか直そう」と思うはず。しかし、日々の業務に悩殺され、そのうち忘れ去られる。そのままうっかりリリースしてしまったら、大惨事を引き起こしてしまう恐れがある。

後からプロジェクトに合流したスタッフが、仮実装を仮実装と気づかず利用してしまうケースがある。こうなってしまうと最悪だ。プロジェクト全体に質の悪い仮実装が再生産され続け、いずれは手に負えなくなる。
そうしてプロジェクト全体のコード品質が落ちると、「このクオリティでいいんだ」と皆が判断し、正式な実装のクオリティも下がってゆく。

とはいえ、仮実装は必要悪であるケースも多数ある。

例えば、マイルストーンの〆直前に、どうしてもこの機能を入れたいという要望があったとする。リリース品質の実装をするには時間がかかり〆には間に合わない。だが、コード中に数値をハードコーディングすればすぐに実装出来て、動いているところを見せられる。
こういうケースなら、仮実装はすべきだ。

ゲーム開発は、試行錯誤の回数がクオリティに直結する。ゲームデザイナーの試行錯誤を増やすために、プログラマが仮実装ですばやく開発するのは、よくあることだ。

でも、その仮実装がリリースまで残ってしまったら……
プログラマが仮実装をする時は、それを将来に無くすための施策も同時にすべきだ。

仮実装がリリースされるのを防ぐ対策を考えてみた。

仮実装をリリースに含めないための方法

そもそも仮実装をしない

仮実装なんてしなければノー問題。もし仮実装をしようものなら、コードレビューの段階で絶対に弾く。
しかしながら、現実はそうもうまくいかない。
試行錯誤のための仮実装は許容されるべきだし、そもそも最初から「仮実装を認めない」完璧主義の開発スタイルは、失敗一直線なことは、多くのプログラマが理解していることだろう。

TODO: コメントを残す

コード中に、TODOコメントのような形で「ここは後から直しますよー」と分かるような印を残しておく、古くからある手法。
正しい形式でコメントを書けば、Visual StudioなどのIDEに備わる機能で、リスト表示できる。

しかし、TODOコメントはしばしば見逃される。
なぜかというと、TODOコメントが書いてあるコードは、他人から見ると不穏な香りがするからだ。「触らぬ神に祟りなし」と見なかったことにされる。

TODOコメントは、無いよりは遙かにマシだが、「リリースに仮実装を含めない」という大目的を達成するには不十分だろう。

仮実装があれば、それを直すタスクを作る

正気なソフトウェア開発なら、JiraやRedmineなどのプロジェクト管理ツールを使っているだろう。
仮実装を作ったら、「必ず」それを直すというタスクを作成するようにすれば、誰からも忘れられた仮実装が生まれることはなくなるだろう。

とはいえ、これはめちゃくちゃめんどくさい。仮実装を作ったらすぐにプロジェクト管理ツールを開きタスク（チケット）化する。開発中の脳をタスク作成の脳に切り替えるのは、なかなか辛い。
故に、プロジェクトに関わるプログラマ全員にこの「タスク作成」のルールを守ってももらうのは困難だ。「仮実装を直す」タスクが全て無くなった（Done）から、もう仮実装はないなんて、とても言えない。

意図的に関数名を長くする

自分がたまにやる手法。
仮実装を作ったら、その関数名を意図的に長くする。そうすると、その仮実装を利用した人が「これはリファクタリングした方がいい」と感じる。それで仮実装が残っているという問題意識を広めることができる。
プログラマの「リファクタリングしたい欲」を逆手に取った手法。

まとめ

色々考えてみたが、「仮実装をリリースに絶対含めない」ようにする、最高の手法は見つからなかった。
プロジェクト全体で、

• 適当な理由のない仮実装はしない

• もし仮実装をしたなら「それを直す」タスクを見える化する

• ボーイスカウトのような「来たときよりも美しく」姿勢を持って、コードを美しくし続ける
  姿勢をコードレビューを通じて浸透させていくしかないのかも。