Posted by ブクログ
2022年12月22日
# 1周目 読み終えた 2022-12-22
第一部はプログラミングの前段階のよう感じで、これは期待していたようなコードの本なのかと、とっつきにくいところがあった。
しぶしぶ読んでいくと、なるほど、確かにプログラミングの本であって、必要なスキルだと分かった。
むしろ自分にとっては、この第一部こそ重...続きを読む要で、定期的に読み直す必要がありそうだと感じた。
この本では要求やアーキテクチャに続く、ソフトウェアの設計やプログラミングをソフトウェアコンストラクションと呼んでいて、第一部を除くとほぼ全てがコンストラクションに当てられている。
第一部以降は、徹底的にコードを解剖して、詳細な議論が展開される。
それらの多くは全く新しい考え方や技法というわけではなく、プログラミングを繰り返すことで徐々に身についてくることでもあり、基礎的かつ実際的なものとなっている。
そういうの整理して、まとめ上げたというところに価値がある。
驚きの新発見はないだろうけど、自身の経験から得られた考え方を、まだ漠然としたものであれば、それを裏打ちして強固なものにしてくれる、という本だった。
まだ上巻なので、あと半分残っている。
## 19章を読んだ
「制御構造の問題」
この章の主題は、複雑さにどう立ち向かうか、ということになる。
とにかく単純に、単純にできればいいのだけど、限度もある。
複雑さは制御構造によってもたらされるところが大きい。
深いネストや込み入った条件がが代表格となる。
それならば、複雑さを軽減させるために制御構造に注目するのは自然なことだ。
制御構造を完全に除去することは不可能で、それは白紙のプログラムと変わらない。
できる範囲で頑張ることになる。
歴史的には、構造化プログラミングの方法が提案されて、解決の糸口が見えたかに思われたが、今ではほとんど廃れてしまったようだ。
しかし、その考え方には有用なものもあるし、一度は学んでおく価値がある。
## 18章を読んだ
「テーブル駆動方式」
これまでとはちょっと色合いが違う章。
9章の疑似コードによるプログラミングと色合いが近い。
基礎的なところよりも一歩先を行った手法、考え方を提案している。
考え方としてはそれほど突飛したものではない。
似たような方法でプログラミングした経験はあるだろう。
このように名前がつけられることでその方法がパターン化され、プログラミングのときに、そういうやり方でやっているのだと自覚できる、ということに価値がある。
また、単純なテーブルへの置き換えでは対応できないケースも、キーをどうにか変換することによって対応できる可能性を見せてくれている。
## 17章を読んだ
「特殊な制御構造」
return、再帰、gotoとある。
returnは特殊とまではいかないように思える。
そもそも、returnしなければ関数から値を返すことはできない。
ここで言っている特殊なreturnとは、ルーチンの途中で処理を終了してしまうためのreturnを指している。
この手法によって読みやすくなることは多々あり、よく使っている。
一つのルーチンには一つのreturnのみしか使わないという主張を聞いたこともあるが、あまり賛同できない。
再帰のところで、階乗やフィボナッチ数に再帰を使うのは問題外、そんなプログラマがいたら別の誰かを雇うと書いてあって、ギクリとした。
再帰については慎重になるべき、単純なループで可能ならそうするべきだと書かれている。
gotoは最後の手段とある。
本番のコードでgotoを使ったことはない。
いつか本当に必要なときが来るのだろうか。
## 16章を読んだ
「ループの制御」
前章と前々章が短かったので、この章は少し長く感じた。
ループの出口によって3つケースがある。
先頭と末尾はwhileとdo-whileなど対応するもがあるので、認識していた。
新たな視点は、ループの途中に出口があるというパターンは盲点だった。
途中が出口だと指示する特別な構文を用意している言語はないかと思われる。
ただ、if cond then break といったようなループを抜け出るステートメントがループの途中にあるようなものを、先頭と末尾にあるパターンと同列に扱う。
こういうパターンには何度も遭遇してきた。
はっきりとこれが出口だ、と認識するかしないかの違いは大きい。
なんとなくループの途中でbreakすると不安な気持ちになっていたのだけど、これは出口が途中にあるループなのだから、そのよう書いても問題ないのだと自信をもつことができる。
ループ変数の名前はi、j、kだけではだめだともっともな主張をしている。
マトリックスを表現する二次元配列とかで、i、jの方がむしろ分かりやすいかと思って多用してきたけど、再考したほうがいいかもしれない。
## 15章を読んだ
「条件文の使用」
ifとcaseの話。
およそ感覚的にひどいと思われるコードはだいたい実際にひどい。
変な感覚を養っていなければ、自身の感覚でおや?と思うところがあれば、それは見直したほうが良いコードの兆候となっている。
そんな風に感じた。
caseのフォールスルーは使うべきではないし、if-elseでは正常なケースを最初に持ってくるべきだというのは、自分の習慣と一致している。
本来到達するはずのないelseやdefaultにassertを置いたり、エラーにしてしまおうという考え方をする状況によく遭遇して、それが良い考えなのか自信がなかったのだけど、この章ではそれはやっても良い、と後押ししてくれた。
## 14章を読んだ
「ストレートなコードの構成」
短い章だった。
一連の手続きの流れを明確にするのが目標。
あまり意識していなかったところでもある。
+ 依存性を明らかにする。ルーチンの名前、引数、コメントをよく考える。
+ 実行順序が問題にならない手続きもある。関連性のあるものをまとめて書く。
+ コードは上から下に読めるようにする。
## 13章を読んだ
「特殊なデータ型」
特殊なデータ型とは何かというと、構造体、ポインタ、グロバールデータを指しててそう言っている。
この本の方針からするとそうなるということで、必ずしも一般的にこのように分類がされているというわけではないだろう。
ポインタのところで喚起されている注意やテクニックは、今でも古びていないのだろうか。
今となっては古びたところも見られる。
少なくともauto_ptrを使うというアドバイスはもう期限が切れている。
SAFE_NEWやSAFE_DELETEマクロは、今のC++ではあまり良い解決策とは思えない。
ポインタの問題をなんとかして、少しでも悲劇の可能性を軽減することに効果があるのかどうか、いずれにしても、完璧な方法というのは存在しない。
これまで何度も出てきたことは、実装の詳細レベルではなく、問題領域のレベルでコードにするということ。
それと、言語の中でではなく、言語の中へプログラミングするということ。
どういうことかと言うと、大体は、言語が提供する機能の範囲でプログラミングするのではなく、問題のある機能を避けて、欠落している機能を補うことを規約で定めるといった感じになる。
これで第3部の変数は終わり。
## 12章を読んだ
「基本的なデータ型」
驚きの新事実といった類のものはない。
なんとなくでプログラミングしても、自然と身についていくこととも言える。
新たな発見がないとしても、文章化されることには大きな意味がある。
なんとなくそうしているという態度を改めて、良い習慣をはっきりと認識して、基礎を強固にする効果が得られる。
例えば、絶対にマジックナンバーを使わない、徹底的にリテラルを排除して名前付き定数にする、そして、なぜそうするべきなのか理由を定着させておく。
第3部は4章も使って変数だけを扱っている。
どの章も、基本的だがあまり文章化されてこなかったことを改めて解説することに重点を置いている傾向がある。
## 11章を読んだ
「変数名の力」
良い名前をつけるというのは永遠のテーマだ。
この章は変数の名前だけの話をしている。
ルーチン名やユーザー定義型などは含まれない。
そのはずなのだけど、無関心ではいられない。
変数名にある規則、例えば大文字で単語の区切りを表すとか設けた場合、ルーチン名やユーザー定義型の名前などの規則と区別できて矛盾しないものでないといけない。
この章では、規則を重視している。
凝った名前をつけるのではなく、規則性のある名前を推奨している。
ちょっと風変わりな規則も紹介されていたりする。
そういうのを除くと、広く認識されている内容ではないかと思う。
短い変数名には強く反対している。
ほとんどの場合はそれに賛成できるのだが、Go言語のような、長い名前に賛成していない言語もあったり、現状、確実に支持されている基準というわけでもないかもしれない。
## 10章を読んだ
「変数の使用」
目新しいことはあまりないく、広く普及しているアドバイスと一致するものになっている。
基本に忠実で、その根拠をはっきりとさせ、きれいに整理した内容になっている。
例えば、変数は初期化する、使用する場所の近くで宣言する、スコープを短くする、グローバル変数を使わないといった感じ。
あとは、変数に複数の意味を持たせないというのは、意図的にやることはなかったと思うが、意識したことなかった。
この章を一言で言い表すと、「変な変数の使い方をするな」ということになる。
変数の使い方だけを解説した章を設けた本というのはあまりないだろう。
この章では、変数の名前の付け方は扱っていない。
次の章でそれだけで1つの章を使うという、贅沢な構成になっている。
## 9章を読んだ
「疑似コードによるプログラミング」
Pesudecode Programming Processを略してPPPと言うらしい。
クラスやルーチンを作成する効果的な方法として推奨している。
初めて聞いた。
テスト駆動開発のように、通常のコーディングの手順を大胆に変更する、アグレッシブな方法だ。
疑似コードは、アルゴリズムを説明するときなどによく用いられる。
説明目的ではない、通常のコーディングで用いることはあまりしたことがない。
色々良い効果が得られるようだが、特に目についたのは、疑似コードがそのままコメントとして残るという点。
コードそのものが説明的であるべきという習慣に従っていたら、過剰にコメントをつけない習慣がついてしまった。
それを矯正する目的で試してみたい気が湧いた。
PPPはどういう位置づけなのかというと、同列のそれ以外の方法と比較すると分かりやすく、そしてそれらのほうが有名だ。
テストファースト開発
リファクタリング
契約による設計
ハック
最後のハックというのは、何も体系化された方法を採用しないという方法で、今の自分はここに当てはまるかもしれない。
## 8章を読んだ
「防御的プログラミング」
基本はエラーの扱い方の話だけど、エラー処理に限った話ではない。
信頼できない入力に対してどうするかなどの話も含まれる。
防御的プログラミングという名前はそのまま、プログラミングに対して防御的になることという意味で、うまく言い表している。
こういう風に名前があることで、考えないといけないこと、実践しないといけないことが認識できるようになる。
アサーションを積極的に活用するように推奨している。
ただし、アサーションは絶対起こるはずのないことに対して検査することで、エラーと区別しないといけない。
例外もエラーを扱う手段として考えられるが、例外の使用には中立的な立場をとっていて、現実的で同意できる。
C++の場合、コンストラクタとデストラクタで例外を投げてはいけないと言っている。
デストラクタでは決して投げてはいけないのは常識化している。
コンストラクタまでそうなのかということは聞いたことがなかった、本当なのだろうか。
開発版と製品版でエラーにどう対処するかが大きく異なってくる。
製品版について特に参考になることが書かれている。
開発段階でアサーションでを活用するよう書かれているのに、ユニットテストを活用するようには書かれていないことが、少し不思議に思った。
事前条件と事後条件について、Stroustrupの本で読んだことがあって知っていたのだけど、その出典があって、契約による設計と呼ばれる手法の一部であると知った。
エラー処理について、堅牢性と正当性のどちらを優先するかというのも決めないといけないということを知った。
## 7章を読んだ
「高品質なルーチン」
コンピュータそのものを除けば、ルーチンはコンピュータ・サイエンス最大の発明だと言っている。
前章がクラスだったので、クラスから一つ階段を降りた、詳細の段階としてルーチンを扱っているのかと思ったら、そうではなかった。
クラスと同等に、高品質なルーチンを書くことを重要視している。
内容としては、基本に忠実であって特別おかしなことはない。
凝集度の概念と分類は欠落していたので、これを機に覚えておこう。
processInputのような曖昧な、広い解釈ができる名前、動詞は避けるべきというところで、全く同じ名前を使ったことがあるのでぎくりとした。
一番重要なところをあげるとすると、クラスと同じように、ルーチンも複雑さを緩和するために作成するということ。
## 6章を読んだ
「クラスの作成」
オブジェクト指向に基づいた設計を行うべき立場からと言うより、歴史的にプログラミングの中心となるものが進化してきて、現段階ではそれがクラスであるという立場に立っているように感じた。
オブジェクト指向の熱烈な支持者ではなく、クラスによってうまく問題を解決できるから採用しているといった現場主義な立場といってもいい。
もちろんクラスを用いる以上は、オブジェクト指向から完全に切り離すことはできない。
なので、オブジェクト指向について学んだことがあるなら、主流となっているガイドラインや原則にだいたい沿ったものとなっている。
興味深いのは、ソフトウェア開発の歴史は、マシン命令→ステートメント→ルーチン→クラス、と進化してきたという解釈だ。
クラスが広く使われるようになって、20年ほど経過している。
もうクラスから新しい何かにシフトしようとという動きがあっても良い頃合いで、それにひそかに期待している。
## 5章を読んだ
「コンストラクションによる設計」
設計についてちゃんと学んだことがない。
独立した開発プロセスとして設計を行った経験なくても、プログラミングにおいて誰もが自然と行っていることが、全部でなくても少なくとも部分的には、思い当たるだろうことが書かれている。
理想から出発した方法論ではなく、現場の経験から生まれた一種のパターンのようなものを整理したものといえる。
唯一の正しい方法があるわけではなく、こうすればうまくいくというようなことが書かれているわけではない。
氷山の一角と言っているけど、自分にとってはこの章だけでも十分ヒントになる。
1ヶ月に1回くらい読み直しても良いくらい。
## 4章を読んだ
とても短い章。
これから先、長い旅の幕開けを予感させる。
言語の選択。
言語の「中で」ではなく、言語の「中へ」プログラミングする。
どういうことか、まだ実感できない。
言語が規定する範囲でプログラミングするのではなく、実現したいことが先に立って、それを言語が提供するツールで実現する。
## 3章を読んだ
概略
+ 上流の必要性とやり方の話。
+ 要求とアーキテクチャ。
+ 反復性と高いプロジェクトと、逐次性の高いプロジェクト。
+ 要求やアーキテクチャで紛れ込んだ欠陥の発見が、あとのフェーズで発見されるほど修正のコストは高くなる。
コンパクトにまとまっている。
この本はコンストラクションをメインに扱う本だが、それでもコンストラクションの前の準備として、要求やアーキテクチャの話は欠かせないといった理由で扱っているのだろう。
それほど大きなプロジェクトを一人で上流からコンストラクションまでこなしたことがないため、実感がわかないところでもある。
正直、めんどくさい、という感想を抱いている。
## 2章を読んだ
メタファ
ソフトウェアを書く、というのはあまり良いメタファではないとしている。
ソフトウェアは手紙を書くように書くのとはちょっと様子が異なる。
人月の神話で使われたのが、普及したきっかけらしい。
アクリーション (accretion) というメタファもある。
真珠。
ソフトウェアを構築するというメタファもある。
建築との比較。
## 1章を読んだ
この本はソフトウェアコンストラクションの本だ。
コンストラクションとはなにか、というと、大体はプログラミングのことだ。
なぜコンストラクションという言葉に置き換えられているのか。
ソフトウェア開発における各種のフェーズ、言い換えるとアクティビティにおいて、プログラミングというのは曖昧な表現になる。
コンストラクションというのは、どうやらちゃんと定義があるらしい。
そのちゃんとした定義の範囲での議論を行おうという意思が見て取れる。
コンストラクションという聞き慣れない言葉で書かれているからと臆することはない。
これはプログラミングのための本だ。
さらに、タイトルが行っているように、コードが中心の本となっている。
有意義な読書になるはずだ。
ソフトウエア開発の方法論を幅広く網羅した入門書。上巻は設計やプログラミング、下巻はテストやデバッグを扱う。1993年発行の第1版を、Webアプリケーションの普及などを踏まえて大幅に改定した。著者はソフトウエア工学の第一人者で、知識体系「SWEBOK」の構築を主導する。計1200ページを超える大部だが、ソフト開発プロセスを建築設計にたとえるなど、難解になりがちな内容を分かりやすくまとめている。
ソフトウエア開発の方法論を幅広く網羅した入門書。上巻は設計やプログラミング、下巻はテストやデバッグを扱う。1993年発行の第1版を、Webアプリケーションの普及などを踏まえて大幅に改定した。著者はソフトウエア工学の第一人者で、知識体系「SWEBOK」の構築を主導する。計1200ページを超える大部だが、ソフト開発プロセスを建築設計にたとえるなど、難解になりがちな内容を分かりやすくまとめている。
