博士

やあ、ロボ子。今日は関数分割について話すのじゃ。

ロボ子

関数分割、ですか。なんだか難しそうですね。

博士

難しくないぞ！記事によると、関数が長すぎるからって安易に分割するのは良くないらしいのじゃ。

ロボ子

なるほど。見た目だけで判断しちゃダメってことですね。

博士

そうそう。論理的な理由でリファクタリングを検討するべきなのじゃ。認知複雑性(CC)を意識して、上限を超えないようにするのも大事だぞ。

ロボ子

認知複雑性、ですか。初めて聞きました。

博士

簡単に言うと、コードを理解するのにどれだけ頭を使うかってことじゃ。CCが高いとバグを生みやすくなるからの。

ロボ子

それは気をつけたいですね。関数を分割する前に、ロジックを簡素化するのも大切なんですね。

博士

その通り！関数分割にはコストもあるからの。局所性とか線形性とか、コンテキストオーバーヘッドが低下する可能性があるのじゃ。

ロボ子

関数名が曖昧だと、複雑さを移動させるだけになっちゃうこともあるんですね。

博士

そう！不要な結合度を高める可能性もあるからの。でも、メリットもあるぞ！コードの重複を減らせたり、ビジネスロジックを標準化できたり、テストがしやすくなったり、依存性の注入が楽になったり。

ロボ子

テスト容易性は重要ですね！

博士

じゃろ？行数だけで分割したり、関数のシグネチャが不明確な場合は避けるべきじゃ。重複が偶然の場合も要注意じゃな。

ロボ子

可読性を上げるためのテクニックもあるんですね。コードをブロックに分割したり、変数名を適切につけたり、コメントを追加したり…。

博士

そう！Martin Fowlerのリファクタリングの例も参考になるぞ。`statement.js`を分割して、文字列の要約と作成を分離したのじゃ。

ロボ子

`amountFor`を`calculatePrice`にリネームするだけでも可読性が向上するんですね。

博士

じゃろ？関数分割は、コードの複雑さを減らすための手段じゃが、安易にやるべきではないのじゃ。可読性、保守性、テスト容易性を総合的に考えて判断するのじゃ。

ロボ子

肝に銘じます！

博士

重複を避けるのは大事じゃが、過度に排除しようとすると複雑になることもあるからの。関数分割はあくまで手段、目的はコードの品質向上じゃぞ！

ロボ子

よくわかりました。今日はありがとうございました。

博士

どういたしまして。最後に一つ、ロボ子。関数型プログラミングって知ってるか？

ロボ子

名前だけは…。

博士

関数型プログラミングは、関数を第一級オブジェクトとして扱うプログラミングパラダイムのことじゃ。…って、ロボ子、寝てる！？