読書記録: Code Complete 上 …

読み終えるまでの目安: 10分

目次

• どんな人におすすめ？
• 本の情報
• 読んだ感想
• メモ
  • ソフトウェアの複雑化を回避するための工夫
  • 関数を細かく分けることのメリット
  • 設計は反復的なプロセスである
  • 設計を再検討するタイミング
  • 変数を使うときに気を付けること
• 最後に

どんな人におすすめ？

この本はこんな人におすすめ！

• 理解しやすいコードにするための工夫を学びたい人
• ソフトウェアを複雑化させないために、設計プロセスで意識すべきポイントを学びたい人
• ウォーターフォール開発のそれぞれの工程で意識すべきポイントを学びたい人

本の情報

読んだ感想

まずいいところから

コーディングの具体的なプラクティスが紹介されていた
これだけだとよくあるかもしれないが、驚いたのは研究論文や統計などを裏付けとしていること
しかもその数が尋常ではない
500件くらいあるのでは…？

設計についても有用なアドバイスが豊富に取り上げられていた
ただ、設計に焦点を当てた本を今まで読んでこなかったので、他の本と比べた相場感を伝えることはできない

次に、自分には合わないと思ったところ

まず和訳が微妙だった
表現するのが難しいけれど、少なくともスッと頭に入ってくる文章ではない
思想が伝わってくるようなものではなく、英文を日本語に訳しただけのような印象を受ける
良書といわれているが、それは原文の評価なのだろう

また、しかたないが情報・背景が古い
第2版が出版されたのは 2005年のようで、ウォーターフォール開発を中心に解説してある
現在主流になりつつあるアジャイル開発についてはあまり触れられていなかった

メモ

ここからは気になった内容について触れていく

ソフトウェアの複雑化を回避するための工夫

• 循環依存は避ける
• 情報を適切に隠蔽する
• グローバル変数には常に関数を通してアクセスする

関数を細かく分けることのメリット

• 単純に処理を理解しやすくなる
• パフォーマンスのボトルネックを発見・改善しやすくなる

設計は反復的なプロセスである

最初から優れた設計ができるとは思わないほうがいいとのこと

本当に共感する
「これでいける！」と思った設計でも、いざコードを書き始めてみると「いや…微妙かも…」となったりする
そうでなくとも、一通り書き終えてから「ここもっとよくできるな」と気付くこともあるはず

設計して、書いてみて、設計を再考してみて、また書いて、…というのを繰り返してようやく優れたアーキテクチャになるということ

設計を再検討するタイミング

設計を見直すタイミングとして、著者は「適切な関数名が思いつかないとき」を挙げていた
うまく命名できないのであれば、それはおそらく人間にとって理解しにくい分け方になっている

変数を使うときに気を付けること

• 1つの変数には 1つの目的を
  悪い例: 変数 pageCountの値は印刷するページ数を表すが、-1の場合はエラーが発生したことを表す
• 短い変数名を見つけたら、他に最適な名前がないか考える
  研究によると、平均 10-16文字の変数名だとデバッグにかかる時間が最も短くなるらしい
  (スコープの小さい変数は短くてもいいかも)

最後に

コーディングの具体的なプラクティスだけでなく、設計に対する姿勢についても多くの知見が含まれていた

ただ、読む前に大きな期待していたこともあって、和訳がイマイチという点は残念だった

いいところも悪く感じたところも紹介してきたが、当然ながらここまでの全てはあくまで私の目を通した情報となっている
数ある意見の 1つとして受け取ってもらい、少しでも読者の参考になれば嬉しく思う