2015/02/25 giveryさんのLt会で発表した資料です。

1. 仕様立ちぬ
「キレイに書かねば」
僕らがコードをキレイに書かないといけない理由
～DDDの適用話～
© 2015 gloops inc.

2. 菊池 翔（Kikuchi Kakeru）［左の写真はFaceBookから］
1989/05/26（age 25）
社会人3年目（でもgloopsは2社目）
開発ではこんなのと関わってます
・C# ・Javascript ・Resharper ・Git（bitbucket）
・SqlServer ・Redis ・IIS ・Jenkins ・Qiita ・JIRA etc…
Native開発では
・Unity とか （Webの部署なので詳しくは知らない…）

3. ソーシャルゲーム開発を行ってます
あれやこれや
やりたい仕様が山積みです…。
いろんな人が絡みます。
急な変更よくあります。
変更をミスるとトラブル…。
企画
デザイン
開発
イラスト
テスター
カスタマーサポート
インタラクティブデザイン

4. ～とてもじゃないが触りたくない実装例～
とあるゲームで似たようなことありました事件簿
ではライトニングトークの本題に入ろう

5. ちょっと攻撃できるようにしたいんだけど
ほーい

6. あ、会心の一撃とゆらぎが欲しい
おう

7. 魔法攻撃もいけるよね？
おう？

8. 魔法攻撃は会心とかゆらぎ無いけど
おう…

9. 魔法攻撃は属性あって弱点とかね！
What’s?!

10. スキルの効果で威力が上がるでしょ！
敵もある程度の耐性がつくからね♪
コンボで徐々にダメージが増えていくだー
強すぎるとまずいから、一部の魔法は下方修正するように…
回復も同じロジックでやってよ
Oh！Jesus！

11. 企画者は無理難題をおっしゃる
本当にそうなのか？
開発者が無理というとそこで進化が止
まります。
なるべくたゆまない仕様変更には耐え
られるように！
そうだ！キレイに書いてみよう！

12. 単一責任の原則：
オブジェクトは１つの責任（役割）のみを持つ
⇒ やることは一つのほうが迷わないよね
クラス、メソッドのスリムアップ！
オープン・クローズドの原則：
拡張に対して開いていて、修正に対して閉じている
⇒ 追加はしやすく、追加しても他に影響がない

13. リスコフの置換原則：
派生型はその基本型と置換可能でなければならない。
⇒ 代替的に使われるオブジェクトの振る舞いが変わらない
オープン・クローズドに親しい関係ですね
依存関係逆転の法則：
上位のモジュールは下位のモジュールに依存してはならない。
どちらのモジュールも「抽象」に依存すべきである。
⇒ 具体的なクラスに依存してはいけないよってことです

14. 一例として「Layered Architecture（層状アーキテクチャ）パターン」
DDD（ドメイン駆動設計）
UI（ユーザ・インターフェース）・プレゼンテーション層
アプリケーション層
ドメイン層
インフラストラクチャ層
Htmlなどユーザと触れ合う画面
［MVCでいうところのView］
ドメインの作業を調整するだけ
［MVCでいうところのController］
ルールの層。さっきの攻撃計算Coreはここ
［MVCでいうところのModel］
上位レイヤを支える一般的な技術。
C#とかSqlServerとか。

15. やることがはっきりしてる！
⇒ UIは表示等、インフラストラクチャはテクノロジー
ユーザに見せる方法が変わるならUI層を新規構築
例）WebじゃなくてNativeでゲーム出したいんだけど。
テクノロジーを変えたいときはインフラストラクチャを修正
例）SqlServerだったけどMysqlに乗り換えるよ。
修正・変更に対して強い実装を！

16. なんてことを日々考えながら仕事してます。
もちろんゲームに対しての議論なんかも盛んです。

17. エンジニアとして働くにはなかなかよい環境が整っています。
参考［HRナビさん］：http://hrnabi.com/2014/08/25/3100/

18. 開発・ゲームが好きな人は是非是非！
http://gloops.com/recruit/