CODE COMPLETE 第2版 上 完全なプログラミングを目指して

  • 日経BP
3.96
  • (78)
  • (54)
  • (72)
  • (4)
  • (2)
本棚登録 : 1198
感想 : 50
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・本 (628ページ)
  • / ISBN・EAN: 9784891004552

作品紹介・あらすじ

米ソフトウェア界の第一人者Steve McConnellが執筆した名著「Code Complete」(1993年発行)の第2版。Jolt賞を受賞した初版の内容を受け継ぎ、さらに新しいトピックを盛り込んで、プログラミングのベストプラクティスを集大成した待望の書です。上巻は「ソフトウェアコンストラクション」から始まり、変数名、データ型、ループ、条件判定、ルーチン、クラスなど、高品質なプログラムを作成するための基本的なテクニックを解説します。初心者はもちろん、経験豊富なプログラマにも開眼のテクニックを実践的に紹介。著者Steve McConnellのプログラミングに対する見識と経験のすべてが詰め込まれた、価値ある1冊です。

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • プログラマ志望の人にはぜひ読んで欲しい。
    プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
    学生のうちに読んでおくのがいいかもしれません。

    goto文論争など基本的な情報の資料にもなっています。
    すでにプログラマになっている人は、C言語プログラマだけに限らず、多くの方が読まれているとよいと思います。
    会社が、本当にプロを養成するつもりなら、必ず読めというと思います。
    会社が、読む時間を工面してくれるはずです。

    会社が、一時的な金儲けだけを目指している場合には読めと言われないかもしれません。
    プロとしての仕事を目指すのではなく、顧客の対応の時間を重視しているなら、読む時間を工面してくれなかもしれません。

    そういう場合は隠れて読んで、3年たったら別の会社に行くのがいいかもしれません。
    いずれにしても、プロとしてプログラムに向き合う時に必要なことがいろいろ搭載されています。

    ps.
    最初は全部理解しようと肩肘はらずに、気軽に読み進んだ方がいいかもしれません。
    仕事で関係がありそうな話題になったときに、もう一度読み直してみましょう。

  • ソフトウェアの設計に関する内容から始まり、プログラムを実際に書くときに気をつけることを、項目に分けて説明している。

    プログラミングをし始めた頃は、何も考えずにプログラムを書いてしまう人が多いと思うが、それにブレーキをかけてくれる本がこれである。
    最初に酷いソースコードを紹介し、その後に良いコードを示してくれるため、悪いコードと良いコードを知ることができる。
    章の最後にはチェックリストがあるため、読み終わった後でも、このチェックリストを確認すれば、どのようなことに気をつければよいかを、簡潔に知ることができる。

    最初の100ページくらいはソフトウェア設計について書かれている。
    ソフトウェアを作り始めたばかりの人は、設計をあまりせずに、すぐにコーディングを行ってしまう人が多いと思うが、それが今後のソフトウェアの品質にどのように悪影響を及ぼすかを、教えてくれる。

    分厚く、全部読むのにはそれなりの時間がかかってしまうが、プログラムを書き始めてしばらく経った人は、ぜひ読んで欲しい本である。
    私はこの本を読み、ソフトウェアの設計をする事が重要であることを知り、自分が書いていたソースコードの問題点を再確認することができた。
    あえて欠点を挙げるとすれば、本が厚く読むのにちょっと時間がかかると言うことだろうか。
    もう少し、コンパクトにしてもらえたらよかったなと思う。

  • プログラミングの全てが、体系的にまとめられている。
    まさに、バイブル!
    いつも手元に置いて、目を通したい本だ。

  • すぐれたプログラミングとはどのようなものか論理的かつ明快に書かれており、かつ具体的なコードが裏付けをもって書かれている。
    文法は覚えてなんとか書き始めたものの、その先を超えたノウハウ、実践的な知識を得られる貴重な本。
    この上巻は直接コードを書くためのノウハウが詰め込まれている。

  • 図書館から借りて読んでいるところです。ぶ厚いのに、これでまだ下巻が続くのかと思うと気が遠くなります(笑)

    • kaizenさん
      がんばれ。これを超えればプロだと言われるかも。
      がんばれ。これを超えればプロだと言われるかも。
      2011/10/22
  • #図書館員の推し事(おしごと)企画/「ゆるコンピュータ科学ラジオ」を推す!

    金沢大学附属図書館所在情報
    ▼▼▼▼▼
    https://www1.lib.kanazawa-u.ac.jp/recordID/catalog.bib/BA7176045X?caller=xc-search

  • 昔仕事で読んだ本。業界ではよくある「より綺麗なプログラムを書く本」だ。この手の本は、数年に1回バズる印象を私は持っている。
    この本はマイクロソフト公式を売りにしている。どこまで社内で活用されているかは分からないが、しっかりした内容はさすがあのソフトウェア"Windows"を作っているだけある、と思わせる構成。

    一つ一つは深い話ではない。されど、それを組織で徹底して意識統一できるかが重要な気がしている。

    上巻は基礎・高品質なコーディング・変数・ステートメント。

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

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

  • プログラミングを行う上で、おそらく熟達したプログラマーであれば自明であるような作法が丁寧に解説されている。
    そして自明でありながら、最初からここに書かれていることを遵守したコードを書いていた、という人は少ないのではないか。

    それぞれの現場で蓄積されたノウハウや事情が醸成するその現場のその時点では正しいもの。
    ここでたびたび紹介される「怖いコード」は、そういったかつて正しかった・正しいと信じられていたものが風化した残骸なのだろう。

    VBの例が頻出することからもわかるように、時代を感じさせる記述は多々ある。コードの読みやすさでいえばリーダブルコードだったり(これもいくぶん昔の本だが)、設計ならDDDやクリーンアーキテクチャだったり現代に即したものがいくつかある。

    しかしコンピュータサイエンスの研究に根ざした網羅的な書籍として、依然本書はエンジニアの書庫に鎮座しておくべき存在だ。

全50件中 1 - 10件を表示

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

  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×