はじめに
本記事はミノ駆動本を読んでクソゲー作ってみたの続きです。
上記記事の内容のクソゲーでは、同じ条件文が複数のクラスに存在していたことが原因で機能追加時に処理が漏れてバグっていました。
この悪魔を退治する方法はクラスの責務をハッキリさせて、処理をかくべき場所をハッキリさせてあげることかと思います。
今回はあのクソゲーを神ゲーにするため、悪いコードの課題の検証をして改善するためのモデリングをしてリファクタしていきます。
※ 神ゲー = 保守運用しやすく、バグが発生しにくいゲーム
身に付くスキル
- 保守や変更がしやすいコードを書くための考え方
参考資料
仙塲 大也. 良いコード／悪いコードで学ぶ設計入門保守しやすい 成長し続けるコードの書き方
内容
今回作成したゲームの実際のコードになります。
https://github.com/kdr250/good-code-bad-code-sample
前回のコードの課題
-
前回の悪いコード編の課題はモデリング全くしてなかった。その結果、凝集度の低いコード設計になってしまっていて、運用時に修正漏れが発生しやすくなってしまっていた。
-
とりあえずどんな処理でもかけるなんでもクラスが存在していた。(UIクラス)
モデリングとは
動作原理やしくみを簡単に理解・説明するために、物事の特徴や関係性を図式化したものをモデル、モデルをつくる活動をモデリングと呼びます。
上記は、13章の冒頭に記載されている内容になります。
動作原理やしくみを簡単に理解・説明するために、物事の特徴や関係性を図式化したものをもう少し具体的にしてみます。
悪いコードの設計
悪いコードの課題の検証するためにクラス図を用いて状態をイメージしていきます。
クラス図
MagicManagerクラスは存在していたが、各メソッドの中でそれぞれ技ごとに条件分岐をしてそれぞれの値を返す構造になっていました。
そのため、処理自体がUIクラスのattackPowerメソッドの中でダメージを計算するために条件分岐をしなけなばならなくなっていました。
結果として、それぞれのクラスの中で各技の処理が必要になり、複数箇所に条件分岐が存在して条件文の追加漏れが発生してしまいました。
良いコードの設計
課題解決のための分析仮説
悪いコードから良いコードにリファクタする改善ポイントを２点具体的に考えました。
-
MagicManagerクラスの各メソッドの中でそれぞれ技毎に条件分岐してそれぞれの値を返す構造になっている点。 -
UIクラスの中でdamageがプリミティブ型として処理されている点。
上記を踏まえ、モデリングをしていきます。
モデリング
モデリングして大きく変わった点
- それぞれの技を各モデルとして定義しました。
- 攻撃力を定義し、ヒットポイントで与えるダメージをモデルとして定義しました。
クラス図
モデリングした内容をに合わせてリファクタした実装のクラス図です。
それぞれの技をエンティティとして扱うことで条件分岐をする必要がなくなりました。
また、Damageクラスを定義したことでHitPointとして与えるダメージが型安全になりました。
ダメージの計算自体はPlayerBattleStatus.totalAttackPower()に実装しています。
実際にダメージを与える処理はPlayerDomainService.attackEnemy()で定義しています。
期待した効果が得られたか
モデリングをしたことで必要なモデルが整理されたためクラスの目的がハッキリし、処理やプロパティが整理されたことで、どこにどういった処理が書かれているかわかりやすくなりました。
その結果、凝集度が高い設計になり、仕様変更時に処理の追加漏れを防ぎやすくなったのと同時にコードが読みやすくなり、新規参画者の実装理解しやすい神設計に生まれかわりました。
その後...
◯◯ ）PMさん！新しい技を追加完了しました！
PM ) お！ありがとう！
◯◯ ）ついでにいい感じにコードをリファクタしておきました！
PM ）さすがだねぇ、君みたいなエンジニアがいてくれると助かるよ！頼りにしてる！
◯◯ ）😤（ドヤ）
おわりに
今回は
- 13章 モデリング - クラス設計の土台 -
をピックアップして実際にリファクタリングすることで悪いコードが発生させる悪夢の退治方法の一部を紹介していきました。
あるべき構造を理解して実装やリファクタしていくことで、悪魔のいない世界になることを願っています。