無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
※アプリの閲覧環境は最新バージョンのものです。
※期間限定無料版、予約作品はカートに入りません
Posted by ブクログ
# 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章を読んだ
この本はソフトウェアコンストラクションの本だ。コンストラクションとはなにか、というと、大体はプログラミングのことだ。なぜコンストラクションという言葉に置き換えられているのか。ソフトウェア開発における各種のフェーズ、言い換えるとアクティビティにおいて、プログラミングというのは曖昧な表現になる。コンストラクションというのは、どうやらちゃんと定義があるらしい。そのちゃんとした定義の範囲での議論を行おうという意思が見て取れる。コンストラクションという聞き慣れない言葉で書かれているからと臆することはない。これはプログラミングのための本だ。さらに、タイトルが行っているように、コードが中心の本となっている。有意義な読書になるはずだ。
Posted by ブクログ
私は、マコネルをまったく信用していませんでしたが、この本で私の認識が間違っていたことが分かりました。上流設計から、コーディング、マネジメントまで、ソフトウエア開発について、ここまで網羅した本は他にないでしょう。ほとんどの指摘は的を得ており、私は、９０％以上の彼の主張に賛成します。また、ほとんどのソフトウエアプロジェクトでは、ソースコードが唯一のドキュメントであるという言い切り方は、この人が現場での経験を充分積んだプロのプログラマーであることを証明しています。エンジニアは、先人の知恵に学ぶべきであり、この人は、学ぶに値する本当のプロです。ぜひ、この本（上下巻とも）を読むべきです。
Posted by ブクログ
プログラミングでの命名規則を徹底検討
よりよいプログラミングを目指して書かれた書籍。分厚い。大量の文献が引用されており，読み応えが十分。
上下巻に分かれており，この上巻では主にプログラミングでの名前について解説されているのが印象的だった。
関数（ルーチン）の名前はどうすればいいか？変数名はどう書けばいいか？データ型やステートメントはどう使い分けるのがいいかなど，実際のプログラミングで誰しも一度は悩むような項目を扱っている。
たとえば，TotalDataとするか，DataTotalとしたほうがいいのか。
クリーンコードやリーダブルコードなど他のコーディングに関する本でもこうした項目に言及しているが，この本ほど網羅的で徹底的に議論されてはいない。おそらく，この本以上にコーディングについて徹底的に考察された本はないのではないかと思える内容だった。
p. 317の「11章 変数名の力」の冒頭の以下の言葉がこの本の本気度を伺わさせる。
「効果的なプログラミングにとって、よい名前というテーマは重要であるにもかかわらず、よい名前の作り方を10項目以上にわたって取り上げた本を読んだことはない。プログラミングに関する文献の多くは、省略形の選択に段落をいくつか割き、決まり文句でお茶を濁し、読者が自力で何とかやっていくことを期待する。本書はこれに真っ向から対抗し、良い名前に関する情報を使い切れないほど提供しようと考えている。」
値段は少々高いが，大量の文献，考察が書かれており，2005年出版とやや古いが，今でも通用するかなり有益な本だった。是非手元においておきたいと思える本だった。プログラミングするなら読んで損はしないと思う。
Posted by ブクログ
ソフトウェア開発におけるベストプラクティスを網羅的に解説したプログラマにとってのバイブル的書籍である。
著者はソフトウェア工学の第一人者であるスティーブ・マコネルで、
私の会社の机にも置いてある「SWEBOK」の構築を主導している人物でもある。
この書籍が解説している範囲的は主に詳細設計?テストで、
上巻では詳細設計?プログラミングの部分を解説している。
この書籍の良いところは、かなり具体的に例を示している点で、
例えば、コーディングの際の擬似コード(PPP)のススメや、
変数の宣言、定義等のベストプラクティスなど、
実際の実務に直ぐにでも生かせるようなテクニックを惜しげもなく教えてくれる。
これは恐らく先人たちが何十年もかけて得た知識や経験を、
この本に凝縮して詰め込んでくれたのであろう。
そんな素晴らしい知識をたかだか数千円の投資で得ることが出来るというのは、
この著者に十分感謝しなければならないと思う。
以下、上巻を読んで大事だなと思った項目を一部抜粋します。
・プロトタイプを作成するときはクラス名やパッケージ名にprototypeというプレフィックスを付けるといった標準を設けるといい。
・設計書の文書化(CRCカード、UML、デジカメ、JavaDocの使用)。
・擬似コード (PPP)の活用。
・変数は宣言時に初期化する(C++など)。
・変数は最初に使用する場所の近くで初期化する。(VBなど)。
・変数の宣言と定義は、最初に使用する場所の近くで行うのが理想的である。
・できるだけfinalまたはconstを使用する。
・クラスのメンバデータはコンストラクタで初期化する。
・すべての変数を自動的に初期化するようにコンパイラを設定する。
・変数の参照はまとめて。
・トランプデータの削除。
・グローバル変数が必要なすべてのコードでアクセスルーチンを使用する。
・ロックを使ってグローバル変数へのアクセスを制御する。
・ループは一度に確認できる程度に短くする。
・ネストは3段階までに制限する。
・ブール値とtrue、falseは暗黙に照合する。
・ド・モルガンの定理を適用して、否定語のある論理評価を単純化。
・数値を含んでいる式は数直線の順番に並べる。
・Cでは、文字を終端のnull('\0')と明示的に比較する。
・Cから派生した言語では、定数を比較の左側に置く。(但し、数直線との関係が矛盾している)。
・null文の代わりにDoNothingプリプロセッサマクロやインライン関数を作成する。
※アプリの閲覧環境は最新バージョンのものです。
ビジネス・実用
ビジネス・実用
ビジネス・実用
ビジネス・実用
ビジネス・実用
ビジネス・実用
