デザインパターンについて

この1年でGameWithの開発部で関わった設計手法、特にデザインパターンを中心に説明する、という話でした。

GoやUnityなど色々と未経験の技術を経験してきた中で、設計手法なども以前より意識しながら開発するようになりました。GameWithでは以下のような様々な設計手法が採用されています。

アーキテクチャ
- クリーンアーキテクチャ(Go言語など)
- MVPアーキテクチャ(Unityなど)
デザインパターン
- シングルトンパターン
- ステートパターン
- ストラテジパターン
- オブザーバーパターン

様々な設計手法を採用していますね！

デザインパターンの目的を一言でいうと、パターンに名前があることで効率よく設計意図を相手に伝えられる、というのがあります。「この機能このパターンで実装するとよさそう！」のようなことをすぐ伝えたり、理解したりできる、ということです。

デザインパターンは、プログラミングにおいて繰り返し現れる問題、解決策に名前が与えられた23個のパターンです。再利用性の高い実装、設計方法をまとめたものです。

ja.wikipedia.org

実はデザインパターンにも元になった考え方があって、パターン・ランゲージというものになります。1970年に建築家のクリストファー・アレグザンダーが住民参加のまちづくりために提唱した知識記述の方法です。

「パターン」には以下のようなフォーマットがあります。

Context（状況）
Problem（問題）
Solution（解決）

上記のセットに名前をつけることで、その名前が共通で認識されて言葉として機能します。デザインパターンの目的もこの考え方からやってきた、ということです。結構面白いですね。

デザインパターンでパターン・ランゲージのフォーマットを適宜それぞれの機能に考え方として入れ込むことで、柔軟に処理を切り替えられたり、方法が増えても拡張しやすく出来た例も紹介してくれました。

いろいろな設計手法を知ったり、実践したり詳しく調べたりすることで、その根本を知ってうまく活用できる、という良い例だな、と思いました。

Flutter開発でMelos使ってみた話

Melosとはモノレポ支援ツールです。

モノレポは複数のパッケージを持つプロジェクトで、各プロジェクトでコード共有をうまく行えるようにする構成のことを指します。

現在開発中のプロジェクトでは似た機能を備えたアプリを複数開発しており、モノレポ構成でMelosを採用したそうです。

1コマンドで各プロジェクトのセットアップが完了し開発効率の向上に貢献できたとのこと。

プロジェクトの構成としては共通コードはcoreパッケージに配置し、各パッケージはcoreを参照して利用するようにしています。

今後限られたいくつかのアプリでのみ利用されるようなコードが必要となった場合は、別プロジェクトとして各プロジェクトの依存として利用する想定とのことです。

アプリは近日リリース予定とのことなので是非チェックしてみてください！

開発コスパの理想と現実

攻略ツールを作る上でのディレクションについて、攻略記事を書いているライターの理想を実現することと、開発側とのすり合わせが難しいという話でした。

開発工数をなるべく抑えたコスパの良い開発をしたいのですが、記事ライターとしてはユーザー満足度を重視したいため、意見が対立しがちです。また、攻略ツールはゲームによってユーザーの特性やUIの特徴などもあり、ライターの方からそう言った部分で、ツールの仕様に対してこだわりが出ることがあります。これは全力を尽くしているからこそ全部やりたいと思っているだけで、素晴らしいことだと思っています。そして、その実現のために開発時にいくつか注意していることがある、と言うことでした。

最適解はまだ見つからないですし、今後も追求し続ける形にはなるのですが、ツールの勝ち筋を明確にし、攻略側で最低でも欲しい必須要件のヒアリングをする。ワイヤーやデザイン、開発中のプロトタイプをステークホルダー内で段階的に確認していく。より上位の人にもできるだけ確認するように心がけたとのことです。とは言えやはり完成物を触るとイメージとの食い違いはありうるので、ある程度のバッファは事前に考慮に入れているとのことでした。