はじめに
メソッドを切り出そうとして、
カーソルを動かしたまま手が止まることがあります。
- 長いから分けたい
- でも、どこで切ればいいかわからない
- 切り出してみたけど、逆に読みにくくなった気がする
「このロジック、複雑すぎるんだよな…」
そう思っていたのですが、最近少し考えが変わりました。
メソッドを切り出せない本当の理由
メソッドを切り出せない理由は、
ロジックが複雑だからではないことが多いです。
多くの場合はこれです。
「この処理が何をしているのか、言葉で説明できていない」
説明できないものには、名前をつけられません。
名前をつけられないものは、メソッドとして切り出せません。
つまり、
- 切り出せない
- 名前が思いつかない
- どこで区切ればいいかわからない
この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を呼ぶかどうかの判断
- 画面を遷移する判断
判断が複数あるなら、責務も複数あります。
責務が複数あるなら、切り出す余地があります。
切り出すことが目的にならないようにする
メソッド分割は、
きれいに見せるためのものではありません。
- 読んだときに意図が伝わるか
- 上から読んで流れが追えるか
- 名前だけ見て何をしているかわかるか
これが満たせていれば、
多少長くても問題ないと思っています。
逆に、
「切り出したけど、何をしてるかわからないメソッド」が増えると、読む側はつらくなります。
メソッドを切り出せないときのサイン
最後に、自分が詰まったときのサインです。
- コメントを書こうとして手が止まる
- 「いい感じの名前」が思いつかない
この状態のときは、
コードを書く前に、処理を言葉で分解するようにしています。
切り出せないのは、スキル不足というより、
まだ考えが途中なだけなのかもしれません。
おわりに
メソッドの切り出しは、
「慣れ」や「センス」だと思っていました。
でも今は、
考えを言葉にできているかどうかの問題だと感じています。
もし切り出せずに手が止まったら、
一度コメントを書いてみる。
それだけでも、少し前に進める気がしています。