はじめに
良いコード/悪いコードで学ぶ設計入門（ミノ駆動本）を読み、悪いコードがどれほど悪影響をおよぼすのか、良いコードでどれだけ改善できるのかを実証していくために実際にゲーム作ってみました。
今回は悪いコードをピックアップして実装に取り入れ、クソゲーになってしまう原因を紹介していきます。
読むべき人
- ミノ駆動本を読んだけどいまいちピンとこなかった人
- 悪いコードのヤバさが分からない、良いコードのメリットが実感できない人
- 部分的なコードでは現実感が湧かなかった人
前提
本記事は JAVA のコードで例を提示していますが、考え方に関する内容なので JAVA を書いたことがなくても問題ありません。
身に付くスキル
- 保守や変更がしやすいコードを書くための考え方
参考資料
仙塲 大也. 良いコード／悪いコードで学ぶ設計入門保守しやすい 成長し続けるコードの書き方
内容
今回作成したゲームの実際のコードになります。
https://github.com/kdr250/good-code-bad-code-sample
こちらのコードでクソゲーになってしまっている原因を現場でありそうなシチュエーションで解説していきます。
仕様変更で新技追加！
PM ) ◯◯くん、このゲームで新しい技を追加することになったから、実装お願いできるかい？
◯◯ ）承知しました！追加しておきます！
.....
◯◯ ）よし、魔法系の技だからMagicManagerクラス見ておけばいいか。..追加完了。実行!!
.....
◯◯ ）ん？ダメージゼロ..なぜだ...
ミノ駆動本の中に6.2.5条件分岐を１箇所にまとめるという章があります。
その中に以下文章が書かれています。
ソフトウェアシステムが選択肢を提供しなければならないとき、そのシステムの中の1つのモジュールだけがその選択肢のすべてを把握すべきである。
この内容は、「同じ条件文を散乱させないようにしましょう。」という考え方で、散乱させてしまうと起こりうるミスとしては「条件文が書かれている場所が全て把握できず、新規で機能実装をする時などに条件文に条件を追加し忘れてしまう。」などが挙げられます。
こういったミスが起こりうるコードはできるだけ避け、共通の処理は１箇所にまとめることで仕様変更が楽で運用しやすいコードになります。
おわりに
今回は
- 6.2.5 条件分岐を１箇所にまとめる
をピックアップして実際に悪いコードが発生させる悪夢を紹介していきました。
こういった作りになってしまっているコードは世の中に溢れてしまっていると思います。
あるべき構造を理解して実装やリファクタしていくことで、悪魔のいない世界になることを願っています。