Tidy First? ―個人で実践する経験主義的ソフトウェア設計

13章ひとかたまり

細かく分割されているがゆえに、かえって理解を妨げているようなコードに出会うことはないだろうか。必要な範囲でなるべく多くのコードをインライン化して、大きなひとかたまりにしよう。そこから整頓するのだ。

コードの最大のコストは、コードを書くことではない。コードを読んで理解することだ。先に整頓することで、たくさんの小さな部品に分けようとする方向に向かう。これは理論上は結合を減らして凝集を高め、実践的には同時に頭に入れておかなければいけないことを減らす。

小さな部品に分けようとするのは、コードを少しずつ理解できるようにしたいからだ。だが、ときには、このプロセスが間違った方向に進むことがある。小さな部品のやりとりの仕方によっては、コードが理解しにくくなるのだ。明確さを取り戻すには、まずはコードを1箇所に集めて、それから改めて、簡単に理解できる部品を抽出する。

探すべき兆候は次のようなものだ。

• 長くて、繰り返しの引数リスト。
• 繰り返しのコード。特に繰り返しの条件式。
• ヘルパールーチンのよくない名前付け。
• 共有の可変データ構造。

小さな部品に分けようとすることを踏まえると、ひとかたまりにして整頓するのは違和感がある。だが、妙に満足するのだ。私は、ずっとコードを部品単位で理解しようとしてきた。だが、私は自分の理解を疑い始めた。そこで、180度方向転換して、ひとまとめにし始めたのだ（自動リファクタリングでこれができれば役に立つが、必要なら手作業でもするつもりだ）。なんという安心感だろうか！

かたまりが大きくなるにつれて、頭のなかに形が浮かび上がってくる。なるほど……。まずこれを計算して、その結果を使ってあれを計算するんだ！ どうしてただそう言わなかったのだろうか？ そこでタイトルの質問にたどりつく。先に整頓すべきだろうか？ ...