「現場で役立つシステム設計の原則」と「レガシーコードからの脱却」を読んでUnity開発のテスト自動化への危機感UP
「現場で役立つシステム設計の原則」を読み終わって、今は「レガシーコードからの脱却」を読んでいる途中。
先日のEOF2019であったt_wadaさんの「質とスピード」、ryuzeeさんの「レガシーコードからの脱却」の資料も合わせて読むと理解が深まってくる。
内部品質であるソフトウェアの保守性を高めること
最初から作るべきものが正しく予測できて、それを一発本番の開発フローで正しく作ることが「幻想であること」がもう分かってきたので、最近はアジャイル開発がキャズムを超えてきている。
当てになりにくい「予測」よりも「対応」（=変更容易性=適応性）を高めるプラクティスが重要になってきていて、テスト自動化やドメイン駆動、モブプロなどが効果的になっている。
「現場で役立つシステム設計の原則」では、以下のような変更しやすいソフトウェアのための実践的なテクニックが分かりやすく説明されていて、基礎力向上に役に立つなぁと感じた（自分は科学系の本ばかり読んでてプログラミングの基礎力弱い）。
- データとロジックを別クラスにするのではなく、三層＋ドメインモデルを考える
- 値オブジェクトやコレクションの型を言語が用意した汎用的なやつにしがちだが、ドメインに合わせた型にして不変にもなるようにする
- 区分ごとのロジックを enumなどで実装する。C#の場合はenumに対してエクステンション使う
- 手続き型プログラミングらしい書き方とオブジェクト指向らしい書き方とを判断できるようにしておく
テスト自動化
node.jsでサーバーサイド開発をやっているときはテスト自動化をできていたけれど、Unityでゲーム開発をし始めてからはまだ自分自身でテスト自動化を実現するのに至っていない。
区分ごとのロジックをenumで実装してそれの単体テストぐらいは書けたが、これでは全然足りないし、これのメンテ自体もまだちゃんとできてない。
Unityの複雑なゲーム起動、データ読み込み、様々なinput処理、組み合わせを考慮できたテスト自動化ができる仕組みと設計を考えていかないと、「質とスピード」の悪い方のプロダクト開発に進んでしまいそうで危機感を持っている。
いきなり開発途中のでかいプロジェクトにテスト自動化を作ろうとしても超難しいので、Unityテスト自動化のプラクティスを見ながら小さいサンプルプロジェクトに何度も適用していって、徐々にどういう設計でどういう仕組みを作ればいいか勘所を探っていくしかないかなと思った。
www.slideshare.net
