スティーブ・マコネルの作品一覧

# 1周目 読み終えた

タイトルである「CODE COMPLETE」からは、どうやって優れたコードを書くかに書かれた本であるかのような印象を与えられる。それに間違いはないけど、こういうところこうかくべきとか、直接的な指示を与えるようなものではない。最終的には品質の高いソフトウェア、すなわちコードを生み出すのが目的となる。それには、単にプログラミング言語のルールを覚えて、盲目的にコードを書けばいいというわけではない。最終的なコードに至るまでの道のりは、思っている以上に長い。この本は、それらを体系的にまとめてあって、信頼できるガイドラインとして利用できる。読み終えて、コードに対して違った見方をす...続きを読むるようになったかもしれない。大きな組織で大人数で開発する場合でも、小さな組織で少人数で開発する場合でも、一人で開発する場合であっても、役に立ちそうなことが書かれていた。


## 35章を読んだ

「さらに情報を得るには」

参考文献、というか、参考程度ではなく、読むべきであるという推奨文献の紹介になっている。著者の会社では、開発者の段階によって読まないといけないものが読書計画として組み込まれているらしい。初級、実践、プロフェッショナルという段階になっていて、この本は初級に位置している。

この本で利用された本当の意味での参考文献は、最後にリストとして大量に掲載されている。読者を誘導するためというより、情報の正確さを裏付けるためのものではあるだろうが、情報源の広さに驚かされる。


## 34章を読んだ

「ソフトウェア職人気質とは」

実質最後の章となる。これまでの長い旅の総まとめみたいな内容になっている。これから先、読み直したいけど時間がないというときは、この章をまず読むと良さそうだ。

プログラミングは芸術か科学かという問が上巻の最初の方にあった。ここで、完全な芸術でも科学でもなく、どちらにも分類されない職人技だと答えを出している。そうしたラベル付がさして重要なわけではないが、芸術家気分で、芸術作品を作るほどには独創的にはいられないし、科学者気分で、厳密な実験と検証のプロセスによってプログラミングをすることもできないことを考えれば、職人技に分類するのは的を得ている。どちらにせよ、プログラミングはプログラミングであって、どのような職人仕事とも違っている。別のところから、そのまんま仕事の鉄則を持ってくることなどできない。しかし、職人気質というと根本的なところで、何か共通するものがあると思わされる。


## 33章を読んだ

「個人の資質」

ただ資質といわれてもよくわからない。才能と混同してはいけないようだ。才能と資質はあまり関係が内容で、才能は重要ではない。自分に才能があると思い込んでいるようなのは、そこら中にありふれている。そして、たいていそれらの資質はひどいように思う。謙虚さや知的な誠実さが完全に欠けてているからだと、そういうことだと思う。自分はどうなのかというと、控えめに言っても才能も資質もなく、正式な教育を受けたわけでもなく、適正が高いとは言い難い。それでも、好き好んで楽しくソフトウェアに関わっているのだから、別にいいかと思う。

プログラマーの3大美徳という名称で、傲慢、怠惰、短気というのが知られている。謙虚さや知的な誠実さに一見相反するようにも思える。しかし、それほど相性が悪いものではないように思える。本当にだめなのは、奮闘や努力のようなものらしい。

この章は、自己啓発的な内容で、ちょっと戸惑う部分があった。普段、自己啓発など全くしないし、そのような本を読む機会がない。読みたいとも思わない。それじゃだめだということで、もし必要であるなら、この章をベースにしとくのが良さそうだ。


## 32章を読んだ

「読めば分かるコード」

コメントの書き方を中心に議論されている。ここまで徹底的にやっているのを他に見つけるのは難しいだろう。悪いコードをコメントで説明するな、コードを直せというのが基本になる。ただし、これはコメントを全く書かないでも良いということを意味するのではない。単純なget/set以外のルーチンには、その簡単な概要をつけるべきとある。ファイル、クラスなども同じで、全体像を把握するのに役立つ概要を添えるべきとなっている。コメントは多すぎても少なすぎても逆効果になりうる。常識的な範囲でやれば良いようだけど、常識というのは人によって異なるところもあり、あまり当てにならない。この章はそのガイドラインとなるだろう。

最近Pythonを少し書いているのだけど、テキストエディタにflake8というコードを検査するツール、要はLintみたいなのが統合されている。それによって、すべてのファイル、クラス、メソッドにdocstringという文書化されるコメントのようなものを記述することが要供される。エラーになるわけではないけど、書かないとその場所がハイライトされて見苦しいので、無視するのは得ではない。鬱陶しいと思わずに、良いコメントを書く練習にすると良いかもしれない。


## 31章を読んだ

「レイアウトとスタイル」

レイアウトとスタイルとは、代表的なのはインデントをどうするかとか、空白文字をどこに入れるかとか、ブロックの始まりと終わりのカッコをどこに置くかとか、そういう厄介な話。ほとんどは美的感覚や、よく見かけるコードをお手本として経験を積んでいくうちに形成される嗜好と、それほどかけ離れたものは推奨されていない。加えて、単に好みや感覚からだけ良い悪いを判断するのでなく、きっちりとなぜ良いのか、悪いのかの理由が示されている。C++のレイアウトスタイルは、開発者によってかなりばらつきがある。別々の個人やプロジェクトが、全く同じレイアウトとスタイルになっているもののほうが稀だろう。clang-formatのような整形ツールでも、細部まで細かく調整できるようになっていることからも、細部までこだわるプログラマの習性が反映されている。何も考えずにGoogleスタイルを選択するケースのほうがまれかもしれない。

この章では、きっちり理由をしめして、いくつかのスタイルを推奨している。しかし、全部に賛同できるような人はまれだろう。最初に「ここでは読者の同意をえることよりも、フォーマットスタイルの問題について検討してもらうことに重点をおいている。」と書かれている。今、自分が採用しているスタイルが本当に優れているのか意識しておくきっかけになれば良い。ある種の原則のようなものを確立して、それに一貫して従うことの方がずっと重要になる。


## 30章を読んだ

「プログラミングツール」

これまでとちょっと毛色が違う章で、話題が順に展開されていくのではなく、箇条書き的に各ツールが担当する役割を紹介していっている。具体的な製品名は挙げられていない。

あまり、あるいは全く馴染みのないもの：

設計ツール
テンプレート
相互参照ツール
測定結果を報告するツール
再構築ツール
コード翻訳ツール
データディクショナリ
コード生成ウィザード
テストツールにリストアップされているうちの多く
実行プロファイラ

最後に、画期的なツールの登場によってプログラミングが不要になるかという点にかかれている。最初にそのようなことが言われたのはFORTRANの登場で、FORTRANによってプログラマが不要になって、科学者やエンジニアが自由にプログラムを書けるようになるといわれていたらしい。実際にはそうはなっていない。現代ではAIがプログラミングを不要にするかどうかという面白い話題があるが、おそらく同じところに行き着くのではないかという感じがする。何かしら良い方向での影響はあるだろうけど、AIを利用したプログラミングスキルが求められるようになるというところでとどまるのではないかと思っている。


## 29章を読んだ

「統合」

「統合」とは一体なんなのか。「分割されているソフトウェアコンポーネントを一つのシステムに統合するソフトウェア開発のアクティビティを指す。」と書かれている。一番愚直な方法は、コンポーネントを個別に完成させて、全部出来上がったらばーんとくっつけてうまくいくことを祈るというもので、フェーズ型と名付けられている。これはほとんど良い方法ではない。どこでエラーが発生したのか、発見が困難になる。それに対して、少しずつ統合していく方法をインクリメンタル型といって、これが現実的な方法になっている。さらにインクリメンタル統合は、システムのどの部分から順番に統合していくかによって、いくつかの手法が考案されている。どれも利点と欠点があって、常に最適となるものはない。各手法をミックスさせたハイブリッドなアプローチが好まれているらしい。

統合をどのように行うかというと、デイリービルドとスモークテストによって行う方法が挙げられている。デイリービルドは、そのまんま、毎日ビルドすることで、スモークテストは、煙が出ていないかをテストするという意味で、比較的簡単な検査のことだ。デイリービルドは1日1回のビルドを推奨している。それ以上、つまりcontinuousだとやり過ぎだと書かれている。最近の流行は継続的インテグレーションで、頻繁にビルドを行うことが流行している。この本の書かれた当時はまだ地位を築いていなかったようで、もし、改訂版が出るとしたらそのことにも触れられるのだろう。スモークテストは軽視してはならず、これなしではデイリービルドは意味がないらしい。具体的な方法までは書かれてないので、気になるところだった。


## 28章を読んだ

「コンストラクションの管理」

プログラマとしては、管理しようとするものとどうやって向き合っていくかのヒントになる。そのような管理しようとする力には違和感を覚えることが多く、そうでなければ幸運だ。かといって、全く力を加えずに無秩序であるほうが良いということは意味しない。たとえプログラマ一人だけのプロジェクトであっても、自分自身でプロジェクトを管理しなければいけないわけで、その場合、管理の失敗は自分の責任であって、影響は少ないが、やはりないよりはマシだ。管理者を管理する必要があり、自分自身の場合を除いて、割と高度な人間スキルが要求される。管理と称して現場で力を振りかざしているのは、「技術的な進化が遅れているものー単細胞生物と氷河期に絶滅したマンモスの中間にある何かー程度」でしかなかった。この章でも、コードチューニングで出てきたように、測定をすることが重要だと説かれれている。測定に反対することは、プロジェクトに何が起きている知らない方が良いといっているようなものだ、とまで書かれている。ただ、プログラムの性能と違って、プロジェクトの測定というのにはあまり馴染みがない。この章は興味深い。プロジェクトが遅れたらどうするかに対して、「プロジェクトが失った時間は、取り戻すことはできない。ますます遅れるだけである。」と書かれているのは記憶に残った。


## 27章を読んだ

「プログラムサイズが及ぼす影響」

プロジェクトの規模が大きくなると、エラーの数が多くなる。このことは直感的に理解できる。しかし、さらに悪いことに、プロジェクトの規模をコードの行数で考えたとして、同じ量のコードあたりのエラーの割合、言い換えればエラーの密度も高くなるので、単純に規模に比例してエラーが増えるわけではない。例えば、1000行あたりのエラーの数は4倍以上にもなることがある。また、プロジェクトの規模が大きくなると、生産性も落ちる。エラーはコンストラクションだけでなく、それ以外のアクティビティでの方もエラーの発生が大きくなり、その増加倍率はコンストラクションよりも高い。
これらのことから、小規模なプロジェクトの実績から類推して、単純に大規模な掛け算でプロジェクトのコストを見積もると、少なく見積もることになってしまうことになる。

プログラマが50人もいるような、そんな大規模なプロジェクトに従事したことがないし、これからもおそらくないだろうからあまり危機感がわかない、というのが本音だ。


## 26章を読んだ

「コードチューニングテクニック」

前章を踏まえて、本当にコードに手を加える必要があるのかどうかかを検討した上で、必要ならばやっていく。ここでも絶対に忘れてはいけないのは、必ず測定をするということだ。測定をしていないチューニングは効果は全く見込めず、コードを見にくくして保守性を下げる効果がついてくる。測定を行って最適化が必要なポイントが明らかにする。そして、禁断の扉を開けると、チューニングを行うためのテクニックはたくさん存在している。しかし、どのようなテクニックでも画一的に適用できるものではなく、ある環境では改善するが、別の環境では待った効果がなかったり、悪化してしまうことすらある。直感は全く当てにならない。必ず結果も測定しなければいけない。この章で紹介されているテクニックは、かなり簡単に施せるものだけど、言語の環境によって効果が予測困難であることを、データで見せてくれている。個々のテクニックを道具として引き出しに入れておくことは良いことだけど、どのようなテクニックも、いつでも使えるものではないことをしっかりと認識しておくことのほうが重要だ。


## 25章を読んだ

「コードチューニング戦略」

コードチューニングとは、大雑把に言うとコードの最適化のことを指している。2章に分けられていて、この章ではどういう姿勢で望むべきか、何をチューニングするのか、その判断基準は何なのかなど、一歩下がったしてから見たガイド、要は見出しにあるとおり「戦略」が語られている。最適化に移動もうとするときに思い出される「早まった最適化は諸悪の根源である」という定番の警句が例にもれず、ここでも掲載されていた。これまで最適化を扱うところでこの名言が引用されなかったものを見たことがない。また、コードをチューニングすることよりも、要求、設計、アルゴリズムの選択を変えることの方が効果が高いことが多いこと、プログラムの実行時間の大半を占めているのがコードの僅かな部分であること、パフォーマンスの測定をせずに行うチューニングは全く持って無意味である、むしろ逆効果であることなど、直感に反するが、プログラマの間では広く浸透しているアドバイスが書かれている。さらにデータも提示されているので反論するところは殆どない。

面白い段落があった。「完璧さを追求すると、完成にたどり着けないことがある。まず完成させてから、完璧なものにする。完璧でなければならない部分は通常わずかである。」この本のタイトルるに反するようで皮肉だが、これが正しい現実の認識だろう。


## 24章を読んだ

「リファクタリング」

この章はかの有名なマーチン・ファウラーの本を要約したものになっているらしい。2019年に第2版が出版されていて、所有しているのだけど、読まないといけないなと思いつつ未読なままだ。リファクタリングという言葉は独り歩きしている感がある。少なくともその本を読んでちゃんとトレーニングを積んでからでなければ、自分は今リファクタリングをしているのだと自信を持って言うことはできないだろう。うまく行くことを願って、手当り次第に変更を加えていくだけのことをリファクタリングと呼ぶことはできない。せっかく本も買ったので、今年中に一度しっかりと取り組んでおきたい。


## 23章を読んだ

「デバッグ」

デバッグは関心の高いアクティビティだ。プログラムの誤りをすぐに見つけて、原因を特定する能力が上がれば、プログラミングの生産性もずっと向上するのに、と思わせられることが幾度もある。それ以上に、プログラムの動作を徹底的に調べ上げるというのはなかなか楽しいものでもある。ただし、これはあくまで個人的な楽しみとしてプログラミングをしている場合のみ、好意的な嗜好だといえる。納期が迫っている状況で、謎のエラーと戦うことを楽しいと思っているなら、正常さを疑われかねない。良いデバッグと悪いデバッグには10倍以上のパフォーマンス差があると書かれている。できれば良いデバッグを行う側に立ちたいものだ。


## 22章を読んだ

「デベロッパーテスト」

この本のサブタイトルは、「完全なプログラミングを目指して」だけど、プログラミングでエラーが一切発生しないことを目指すものではない。必ずエラーは紛れ込むものであって、テストは不可欠なプロセスであることを前提としている。そのテストに対する考え方は、一口で語れるような軽いものではない。単にテスティングフレームワークを採用して、ユニットテストを書いておけばいいというだけには済まない。よく知られたテストファーストの方針を推奨してはいるけど、それが全てではなく、何をテストすればいいのか、どのような手順でテストを実行すればいいのか、そもそもテストとは何かを知っておかないといけない。


## 21章を読んだ

「コラボレーティブコンストラクション」

なかなか高度な話題だ。複数人での活動になるので、一人ではトレーニングすることができない。企業で活動しているとしても、環境によってはトレーニングのためだけにそのようなことをする決定権を持たない場合もあるし、実験的に取り入れてもすぐに効果が出るとは思えないので、採用に至るまでの道のりはなかなか険しいものだろうと思われる。大きな企業では、一部を除いて、プログラマの思いつきでで現状のやり方を変えることは難しいだろう。結局の所、経営に関わる政治的な力と向き合わなければならない。この章が「コードの改良」というパートに含まれているのは皮肉だ。もちろん全てが悪いことばかりではなく、積極的かつ慎重にソフトウェアの品質を高めるためにとっくにこの古い本に書かれているようなことはとっくに実行済みで、より優れた方法を開発している集団や組織もたくさんあるだろうけど。


## 20章を読んだ

「ソフトウェアの品質」

品質と言っても様々な特性がある。ある特性は別の特性と結びつきがあって、一方を上げると別の方が下がるということもあり、すべての特性を同時に完璧にすることができない。

品質を改善するコストを下げるためには、できるだけ早い段階、つまり、コ
ンストラクションより前の段階ででエラーを検出するのが良い。

というようなことが書いてあった。久しぶりに、約3ヶ月ぶりに読み進めるので微妙に飲み込みが悪い。


## 下巻 はじめにを読んだ

上と同じ内容と思われる。
コンストラクションの重要性、コンストラクションに関する書籍が殆どないこと、研究において軽視されている状況などについての鋭い指摘がなされている。

マコネル本。
読んだ後に自分のプログラムを見返すと色々と粗が気付いた本。
とはいえ、最近は言語やツールチェーンで救ってくれる所が増えたので、ざっと押さえておくと良いレベルなのかも。(C言語とかは別)

もう古典だけどたまに見返す位に参考になる本。
下巻はデバックとかチューニングとかなので上巻より見る頻度は低いけど。

# 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章を読んだ

この本はソフトウェアコンストラクションの本だ。コンストラクションとはなにか、というと、大体はプログラミングのことだ。なぜコンストラクションという言葉に置き換えられているのか。ソフトウェア開発における各種のフェーズ、言い換えるとアクティビティにおいて、プログラミングというのは曖昧な表現になる。コンストラクションというのは、どうやらちゃんと定義があるらしい。そのちゃんとした定義の範囲での議論を行おうという意思が見て取れる。コンストラクションという聞き慣れない言葉で書かれているからと臆することはない。これはプログラミングのための本だ。さらに、タイトルが行っているように、コードが中心の本となっている。有意義な読書になるはずだ。

下巻で扱われるのはコードの改良、システムの考察、そしてソフトウェア職人気質だ。

テスト、コラボレーティブな開発(ペアプログラミング)にコードチューニング、リファクタリングが一つの書籍という体系に纏められているのは改めて素晴らしいことだ。「コンプリート」の名の通り、優れたコードコンストラクションを実現するために必要な要素がギュッと詰まっている。たとえばよりよいコメントの書き方、Lint使用の推奨など現代のプログラミングの礎となっている。

もちろん、時代柄古びてしまっているところはある。
それを補ってあまりあるほど本書は魅力的であり、また現代のエンジニアにとっても変わらず必修科目であるといえる...続きを読むだろう。