ぽらろいどの日記

新しい知見を得たり、得られた知見を記録したり共有したりする場を予定しています。

初めての設計本に"a philosophy of software design"が良かった

読んだ本

読んだのは以下の第1版

www.amazon.co.jp

内容

ky-yk-d.hatenablog.com

engineers.ntt.com

感想

一言で言うと、まだコーディング経験が不足しているひとが、これからどうやって"良いコーディング"をしていけばいいかを理解するのにちょうどいい本なのかなと思った。

パッと他の設計本・記事を読んだときに、「まだ読むには早いかも……」となる要因として以下があるなと感じていたが、

  • 抽象度が高い表現が中心
    • まだ経験値が少なく、あまり理解できない
    • 凝集度・結合度、DRY原則など
  • 具体的なテクニックが中心
  • 特定の設計手法
    • まずは原則を理解したいので、まだ早い

その点、本著は以下の通りにバランスが良くて、分かりやすかった。

  • 基本的に原則論を展開している
    • より良い設計につながるような考え方のポイント、原則を示している
    • 色々なパターンに対処できる応用力に繋げられそう
  • 原則を色々な角度から示していて、理解しやすい
    • 初めの数章は、ある1つの原則を様々な角度から捉えているような感じがした
    • そのおかげで、抽象的な原則の理解を深めていきやすい
    • 難しい用語も出てこないので、考えやすい

結果的に読み終えてみて、他の本をつまみ読みしたときよりも、"より良いコーディング"について理解を深められた感じがする。

もちろん、追加で色々なテクニックをプラスで学ぶ必要があるとしても、そのテクニックがどうしていいのか・どう使えばいいのかを、ある程度理解できるようになったのではないかと思った。

+α: 個人的に嬉しかった点

個人的には、本書を通じて「流行の技法」について迷いや不安を整理できたのも良かった。例えば、3つ例を挙げると、TDD、コメント、コードの分割がある。

TDD

少しTDDを試した感触で、動作が不安なときのサポートぐらいに使いたいと思っていた一方、「TDDでコーディング当然!」という記事をよく見ていたので、自分の理解にやや不安があった。

この点に関して、著書では以下のように言われていたので、無理して使わなくていいと安心が得られたのが良かった。

Although I am a strong advocate of unit testing, I am not a fan of test-driven development. The problem with test-driven development is that it focuses attention on getting specific feature working, rather than finding the best design. (p.155 / 以下第1版)

コメント

「最善のコードとは、コメントの要らないコードだ」という意見を幾つか見ていて、一方自分の経験ではコメント書いた方が分かりやすい部分があると感じていたので、自分の理解に不安があった。

この点に関して、著書では以下のように言われていたので、コメントを書く安心が得られたのが良かった。加えて、どのように書くべき・書くべきでないか少し整理できたのが良かった。

Some people believe that if code is written well, it is so obvious that no comments are needed. (...) Nonetheless, there is still a significant amount of design information that can't be represented in code.(p.96)

コードの分割

「長すぎる関数は悪い関数」「XX行を超えたら関数を分割しろ」という意見を見ていた一方、実践して分かりにくくなってしまったことがあったので、どう理解すべきか迷っていた。

この点に関して、著書では以下のように言われていて、加えて、実際どのように分割すべきか、考え方や具体例なども提示されていたので、自分の理解を整理できて良かった。

Students in classes are often given rigid criteria, such as "Split up any method longer than 20 lines!" / However, length by itself is rarely a good reason for splitting up a method.(p.70)

以上、初めの頃は色々真に受けすぎるところがあるので、そこで理由や具体例付きで話を整理してもらえたのが嬉しかった。

まとめ

コードの書き方を理解したら、その次は本書にも"I have hypothesized that design skill is what separates great programmers from average ones"(pp.ⅶ-ⅷ)とあるとおり、いわゆる良いコーディングができることが求められるのだと思う。それに関して、本書は良いコーディングの原則を分かりやすく教えてくれるという点で、初めての設計本に適切なのではないかと思った。

まだまだ実践という意味では自分は遠いところにあるので、具体例の豊富な設計本などにも手を伸ばしつつ、レビューなどのタイミングで本書に立ちもどってみて、もっと理解できるようにしていきたい……。