A Philosophy of Software Designの15章要約
本内容は「A Philosophy of Software Design」の15章を要約する記事です。
過去記事
- A Philosophy of Software Designの3章要約 - なになれ
- A Philosophy of Software Designの5章要約 - なになれ
- A Philosophy of Software Designの7章要約 - なになれ
- A Philosophy of Software Designの9章要約 - なになれ
- A Philosophy of Software Designの11章要約 - なになれ
- A Philosophy of Software Designの13章要約 - なになれ
14章の紹介
他担当の方が要約した14章の内容を引用します。
- 14章 名前の選び方
- 変数やメソッドなどの名前を決めることは、ソフトウェア設計において最も過小評価されている点の一つ。
- 良い名前は一種の文書化であり、コードを理解しやすくします。また、他の文書の必要性を減らし、エラーの発見を容易にする 。
- 「もし誰かがこの名前を単独で見た場合、その宣言も文書も、この名前を使ったコードも見ないで、この名前が何を指しているのか、どれだけ詳しく推測できるだろうか?より明確なイメージを描ける他の名前はないだろうか?」という問いかけが有効
- 逆に、名前の選択が不適切だと、コードの複雑さが増し、曖昧さや誤解が生じ、バグが発生する可能性がある
- 良い名前には、「正確さ」と「一貫性」という2つの性質がある
- Red Flag: Vague Name
- 変数名やメソッド名が多くの異なるものを参照できるほど広範であれば、開発者にあまり情報を伝えず、基礎となる実体が誤用される可能性が高くなります
- Red Flag: Hard to Pick Name
- もし、ある変数やメソッドに明確なイメージを与えるシンプルな名前を見つけるのが難しければ、それは基盤となるオブジェクトがクリーンなデザインでない可能性を示唆するものです
- 一貫性については重要なことは、第一に、与えられた目的には常に共通の名前を使うこと、第二に、与えられた目的以外には決して共通の名前を使わないこと、第三に、その名前を持つすべての変数が同じ動作をするほど目的が絞られていることを確認すること
- 変数の意味を明確にするのに役立たない単語は、混乱を招くだけ
- 名前の選択は、「複雑さは漸進的である」という原則の一例である。
- 特定の変数に、可能な限り最高の名前ではなく、平凡な名前を選択しても、おそらくシステム全体の複雑さにはあまり影響を与えないが、ソフトウェアシステムには何千もの変数があり、これらすべてに良い名前を付けることは、複雑さと管理性に大きな影響を与える
- 良い名前を選ぶことは、第3章で説明した「投資マインド」の一例です。前もって少し余分に時間をかけて良い名前を選んでおけば、将来的にコードに手を加えることが容易になる
15章の要約
- 15章 最初にコメントを書く(デザインプロセスの一部としてコメントを使う)
- 概要
- コメントを書くのに最適なタイミングは、コードを書くプロセスの最初の方
- 最初にコメントを書くことで、ドキュメンテーションを設計プロセスの一部にできる。これは設計を良くする効果もある
- 遅れたコメントは悪いコメント
- ドキュメントを面倒な仕事だと考え、できるだけ先延ばしにしていると思われる
- コードが安定するころには、コードが大量にあり、ドキュメントを書く作業は膨大になり、書かれなくなる可能性が高くなる
- たとえ、コメントを書き直す自制心があったとしてもそのコメントはあまり良いものではない
- 完成したコードを見ながらコメントを書くので、コードの繰り返しになる
- 最初にコメントを書く
- やり方
- 新しいクラスでは、クラスのインターフェイスのコメントを書くことから始める
- 次に、最も重要なパブリックメソッドについて、インターフェイスのコメントとシグネチャを記述する。メソッド本体は空のままにする
- 基本構造がほぼ正しいと感じるまで、これらのコメントを少しずつ繰り返し記述する
- この時点で、クラス内の最も重要なクラスインスタンス変数の宣言とコメントを書く
- 最後に、メソッド本体を埋めていき、必要に応じて実装コメントを追加する
- メソッド本体を書いている間に、通常、追加のメソッドやインスタンス変数の必要性を発見する
- インスタンス変数の場合は、変数宣言を書くと同時にコメントを記入する
- これにより、コードが完成したら、コメントが完成します
- メリット
- より良いコメントを作成できる
- クラスを設計しているときにコメントを書けば、設計上の重要事項を記録するのが容易になる
- コーディングとテストの過程で、コメントで問題に気づき、修正することができる
- やり方
- コメントはデザインツールである
- コメントを最初に書くことは、システム設計を向上させる
- メソッドや変数を説明するコメントは、シンプルかつ完全であるべき。もし、そのようなコメントを書くのが難しい場合、それは記述しているものの設計に問題がある
- 早いコメントは楽しいコメント
- コメントを最初に書くことは、コメントを書くのが楽しくなる
- 著者にとって、プログラミングの最も楽しい部分の一つは、新しいクラスの初期の設計段階であり、クラスの抽象化と構造を具体化すること
- コメントは、設計上の決定の質を記録し、テストする方法になる
- コードを書くことよりも、優れた設計が目的であるならば、コメントを書くことは楽しいことになるはず
- 初期のコメントは高価か?
- コードの進化に伴うコメントの手直しのコストについて
- コメントを遅らせることはコスト節約にならない
- コメントを書く時間は開発時間全体の5%程度に過ぎない
- コメントを最初に書けば、コードを書き始める前に抽象化された部分がより安定し、コーディングの時間を節約できる
- コードを先に書くと、抽象化したものが進化するので、コメント優先のアプローチよりコードの修正が必要になる
感想
- コメントを後回しにして、設計の意図とかが抜けてしまうというのは同意する
- TDDとの相性はどうなんだろう、TDDはコードを書きながら設計を進化させるアプローチなので競合するかもしれない