直近の小規模PJで「設計の壁」にぶつかった話

はじめに

NEアドカレ6日目、よろしくお願いします！
NE株式会社が自分たちの興味あるテーマについて自由に書いていきます。

概要

直近の小規模PJにて、初めて設計から携わることが出来ました。
今までは実装を任される事が多く、設計は実務で初経験だったので多くの学びがありました。
この記事ではそれについて書いていきます。

今はコーダーをやっているが、設計に興味がある方に読んでいただけると嬉しいです！

最初の設計：小規模故の甘い見積もり

当初の要件は、非常にシンプルなものでした。
この時の自分の感想は

• この程度の処理なら大丈夫だろう
• 開発自体でずっこける事は絶対にないだろう

特に何も考えていなかった自分は、甘い考えを持っていました。

立ちはだかった壁：仕様追加による煩雑化

前提、今回のプロジェクトはログイン時のセキュリティ強化が要件でした。
一見するとシンプルな要件に見えましたが、楽観的な考えのまま進むと、
仕様変更・追加仕様が降ってきた時に、その場その場での対応を重ねて行くと
いつの間にか煩雑なコードが出来上がってしまいますね。

私の場合、設計当初見えていなかった見落としがある事が、開発途中に発覚しました...

1. 新規登録ユーザーの除外: 新規ユーザーの初回ログインは、不審なアクセスと判定しない
2. パスワードリセット後の考慮: リセット後のログインの扱いが難しかった

それぞれに適応して行く中で、設計の事を考えずソースコードを書いていくと、
以下のようなコードが生まれてしまいました。

# コントローラー
class Users::Controller
  hogehoge() <- 最上位メソッド
end

def hogehoge()
  # nullチェックやログ処理など...
  hugahuga.mainMethod() <- メインの機能を書くメソッド
end

def self.mainMethod()
  if 新規ユーザー?
      # 新規ユーザーに対する処理 (処理のベタ書き)
      # ここではメールを送信しない
  end

  # 既存ユーザーの処理
  if 不審なアクセス？
      # 不審な端末だった場合 (処理のベタ書き)
      # ここでメールを送信する
  else 
      # 信頼出来る端末だった場合 (処理のベタ書き)
  end
end

改善案：目的ごとにメソッド化し、可読性をあげてみる

hogehoge()の中に全てが詰まっているので、見やすくはあるんですが、
単一責任の原則に則った書き方が出来るのが理想だと思っています。

(処理のベタ書き)の部分を、それぞれメソッド化すべきでした。
新規ユーザーに対する処理は、このメソッドを呼ぶだけ。
既存ユーザーに対する処理は、このメソッドを呼ぶだけ。のような...

こちらは、可読性やテストのしやすさも更に優れている気がしますね。

# コントローラー
class Users::Controller
  hogehoge() <- 最上位メソッド
end

def hogehoge()
  # nullチェックやログ処理など...
  hugahuga.mainMethod() <- メインの機能を書くメソッド
end

def self.mainMethod()
  if 新規ユーザー?
      新規ユーザー用① 呼び出し 
      新規ユーザー用② 呼び出し
  end
  
  if 新しい場所からのログイン？
      不審な可能性のあるリクエスト用① 呼び出し
  else 
      信用できる端末からのログイン用① 呼び出し
  end
end

このように実装した事で、「新規ユーザーにもメールを送りたい」となった時に、
メール送信メソッドを新規ユーザー②の下で呼び出すだけで対応出来るようになりました。

「行いたい処理を可能な限り切り分けて、仕様変更にも呼び出しのみで対応」　
これが、今回のPJで私が学ぶべき最大のポイントでした。

まとめ

初めて設計を行った経験から、以下の3点を強く意識するようになりました。

• 小規模PJこそ油断大敵：
  • 「簡単だから」と設計で油断すると、少しの仕様追加で破綻し、
    コストがより多くかかってしまう可能性があります。
• 変更は必ず起きる前提で設計する：
  • 「仕様が変わっても耐えられるか？」という変更容易性の視点で、
    常にチームで設計について対話する必要があると感じました。
• ロジックの切り出し：
  • 行いたい処理を可能な限り切り分けて、仕様変更にも呼び出しのみで対応可能にする

おわりに

プロジェクトが大きくなればなるほど、
この「切り出し」の重要性と難易度は上がっていくのだと思います。
まずは「小さな変更に強い設計」を意識するところから、一歩ずつ成長していきたいです。

明日の記事もお楽しみに！