はじめに

メソッドを切り出そうとして、
カーソルを動かしたまま手が止まることがあります。

長いから分けたい
でも、どこで切ればいいかわからない
切り出してみたけど、逆に読みにくくなった気がする

「このロジック、複雑すぎるんだよな…」
そう思っていたのですが、最近少し考えが変わりました。

メソッドを切り出せない本当の理由

メソッドを切り出せない理由は、
ロジックが複雑だからではないことが多いです。

多くの場合はこれです。

「この処理が何をしているのか、言葉で説明できていない」

説明できないものには、名前をつけられません。
名前をつけられないものは、メソッドとして切り出せません。

つまり、

切り出せない
名前が思いつかない
どこで区切ればいいかわからない

この3つは、だいたい同じところで詰まっています。

切り出せないコードあるある

たとえばこんなメソッドです。

void submit() {
  if (user == null) {
    showError();
    return;
  }

  if (!form.isValid()) {
    showError();
    return;
  }

  final data = createRequestData();
  api.post(data);
  navigateToNextPage();
}

長くはないけど、
「なんとなく全部ここにある」感じがします。

切り出そうとすると、

バリデーション？
API呼び出し？
画面遷移？

どこからどこまでが1つの処理なのか、
少し曖昧です。

コメントを書いてから、メソッドにする

ここでよくやるようになったのが、
先にコメントを書くことです。

void submit() {
  // ユーザーが存在するかチェックする
  // 入力内容を検証する
  // リクエスト用のデータを作成する
  // APIに送信する
  // 次の画面に遷移する
}

こうやって並べてみると、
「あ、もう分かれてるな」と気づきます。

このコメントたちは、そのままメソッド名になります。

void submit() {
  validateUser();
  validateForm();
  final data = createRequestData();
  postData(data);
  navigateToNextPage();
}

切り出しは、
実装の話というより、思考の整理なんだと思いました。

行数じゃなく「判断の数」で見る

昔は、

〇行以上なら切り出す
ifが多いとダメ

みたいな基準で考えていました。

でも最近は、

「このメソッドで、いくつ判断しているか」

を見るようにしています。

バリデーションの判断
APIを呼ぶかどうかの判断
画面を遷移する判断

判断が複数あるなら、責務も複数あります。

責務が複数あるなら、切り出す余地があります。

切り出すことが目的にならないようにする

メソッド分割は、
きれいに見せるためのものではありません。

読んだときに意図が伝わるか
上から読んで流れが追えるか
名前だけ見て何をしているかわかるか

これが満たせていれば、
多少長くても問題ないと思っています。

逆に、
「切り出したけど、何をしてるかわからないメソッド」が増えると、読む側はつらくなります。

メソッドを切り出せないときのサイン

最後に、自分が詰まったときのサインです。

コメントを書こうとして手が止まる
「いい感じの名前」が思いつかない

この状態のときは、
コードを書く前に、処理を言葉で分解するようにしています。

切り出せないのは、スキル不足というより、
まだ考えが途中なだけなのかもしれません。

おわりに

メソッドの切り出しは、
「慣れ」や「センス」だと思っていました。

でも今は、
考えを言葉にできているかどうかの問題だと感じています。

もし切り出せずに手が止まったら、
一度コメントを書いてみる。

それだけでも、少し前に進める気がしています。