プレファクタリング -- リファクタリング軽減のための新設計 ([著]Ken Pugh, [訳]木下哲也/有限会社 福龍興業, [版]オライリー・ジャパン) #2

3章を読んだ。ざっとまとめると・・・

アーキテクチャは大事(3.1)。インターフェイスはしっかり決めよう、できれば「Design by Contract」で(3.2)。入力として渡されたデータは検証しないと(これはDbCの裏)(3.3)。暗号のようなコードはやめて(3.4 & 3.5)。コピペすんな(3.6)。記録を残せ、とくに意図/理由/意思を書き残せ(3.7 & 3.8)。いきあたりばったりでエラー処理するな(3.9)。局所的な最適化に夢中になるな(3.10)。(一個飛ばして; 3.11)。ツールはプログラマの代わりにはならない(3.12)。

3.11 は「スプレッドシートの難問」。ここだけ、この章でかなり異質な印象を受ける。他の節ほどわかりやすくない。はっきり言えばわかりにくい。それでも著者の主張を読み取ってみると・・・

ここで言う「スプレッドシートの難問」とは、プログラミングの設計においてしばしば行うことになる選択が、表形式のデータに対して「行」、「列」のどちらからアクセスするかという問題でモデル化できる、ということ。

最初の2つの例(図3-1と3-2)は表形式のデータそのままでわかりやすい。ただ、それがどうした、と思ってしまいがち。一方で「グラフィックス(3.11.1)」と「誰が責任者か(3.11.2)」は、これが最初の2つの例と設計上の選択において、同じ構造を持っているということは直観的にはわかりにくい。文章で指摘されてもわからないかも。それどころか、図3-3のような表に描かれても何が言いたいのか、わからない可能性もある。

繰り返すが、この節の主張は「設計上の選択が、スプレッドシート(表)に行、列のどちらからアクセスするか、という問題と同型である」ということ。そして、正解は状況によって変わるんだということ。普遍的な解答はない、と。

プログラマにできることは、「これは典型的な"スプレッドシート問題"である。今回のシステムに対する○×△という要求を考慮して、ここでは"行"によるアクセスを選択する」という設計における選択の理由(意図)を記録しておくことだけ。そうすれば後からその記録を読んだ別のプログラマが、その意図をより明確に理解することができる。ただし「スプレッドシートの難問」モデルを知っていれば。モデルって言葉がアレなら「パターン」でも良い。