https://qiita.com/KyoheiOkawa/items/223368639b9a67c289d9
Unityを使用したソシャゲ開発・運用に関わって４年目になります。 そこで感じたプログラミングをする上で大切だと思ったことをピックアップしてまとめていきます。 あくまで私が感じたことなので、一般的に正しいとは限らないのでご了承ください。
同じ処理を何度も繰り繰り返し書かずに、共通化するということです。 とても当たり前のことですが、こちらを守るのは意外と難しいことだと感じています。
自分が書いたコードでしたら、共通化した部分を覚えているのでそこまで難しいことはないかもしれません。 しかし、実際の開発で一人だけで書いていくことは少ないので、他人が共通化した部分を利用していく必要があります。 チーム開発ではDon't repeat yourselfはもちろん守らなければなりませんが、Dont't repeat ourselfである必要があります。
共通化！これもあれも共通化！と血走ってもいけないと私個人的には感じています。 例えばインゲームのリザルトを共通処理で作ったとします。 イベントが始まり、 リザルト途中で獲得報酬のポップアップ出したい！ リザルトページにイベントポイント関連の内容をはさみたい！ リザルトからの遷移先を変えたい！！ と要望がきたら共通処理の中にイベント用の分岐を入れる必要が出てしまい、影響範囲も広くよくわからないコードに変化していってしまいます。
こちらの動画がとても分かりみ深いです。
こちらは私もあまり実現できていない内容なので、どちらかというと理想になります。 マスタデータ,リソース読み込み,通信などは共通認識がほぼほぼあるはずなので、共通基盤を使わずに独自の実装に走る人は殆どいないと思います。 文字列操作や日付周りの共通処理などから共通認識が怪しくなってくると感じています。 こちらはUtilityなどで処理をまとめ、あちこちに定義している場所が散らからないようにして、チームにしっかり共有する。そして、コードレビューを徹底する必要があります。
共通化はエンジニアだけではなくて、UI・仕様の段階で画像やテキスト、ボタンなどの作りを決め、更にそれらを利用するヘッダー・ポップアップ・アイテムアイコン・カードユニットなどの作りを共通で決めて使っていくのが理想的です。
様々な箇所に同じような分岐を入れていくのはよくありません。 処理のまとまりを一つの場所で管理して、それぞれの場所で分岐を書かないようにするために、DIやストラテジーパターンを導入を検討します。
良い例がなかなか思いつかないですが、オセロを例に上げてみましょう。
通常モード時は ・緑色の盤面 ・制限時間なし ・アシスト表示あり
ハードモード時は ・赤色の盤面 ・制限時間あり ・アシスト表示なし
対応する箇所で分岐を書いて愚直に対応して行くことも可能ですが、それぞれのモードで何が変わるかコード上で把握するのが難しくなってきます。 さらにモードが増えていくと、分岐が肥大化して収集がつかなくなりそうですね。 ServiceLocatorパターンを利用すると、インターフェースに実態を登録できるので、それぞれの処理では分岐を書かず、インターフェースを通して処理を実行するだけで済みます。 実態を登録するときだけ分岐を書けば良くなるので、最小限の分岐を最初に書いて終わりです。