「達人プログラマー―システム開発の職人から名匠への道」 とその関連商品

インパクトのあるタイトルと黒々とした表紙から、ギーク向けの本と思ってました。
が、読んでみるとソフトな内容。
プログラマとして知っておくべき、気をつけるべき、そして実践するべき内容が上手くまとめられており、「そうそう、そうなんだよねー」とウンウンしまくり。
もっと早く読めばよかったという気もするが、若い頃に読んでも実感が湧かなかったろうな。
挿入されているお話も面白く、新人研修などの講師になったら話のネタに使えそうだわ。
（生徒がこの本を読んでいませんように・・・） (殿下/2007-05-02)

もっと早く読むべきだったと後悔しています。
達人の仕事振りを説いた１冊です。

この本のキーワードとなる言葉は、
１、割れ窓をなくす
２、蛙の煮物
３、伝達しよう
４、ＤＲＹ原則
５、直交性
６、自動化
７、絵画の制作のやめ時を知る

プログラマーでこの本を読んでいなかったら、
急いで読みましょう。
それ位、知らないと恥ずかしいです。 (なか/2007-04-23)

この本には、プログラミングの原則が、詳細かつ分かりやすく記述されている。
それらは、プログラミングをする上での、ごくごく当たり前の事柄なのだが、意外に実践できていなかったりする。

新人プログラマなど、とりあえずは動くものが作れるが、品質がいまいちな人たちに、最も読んでほしい本である。 (卍/2007-02-21)

タイトルは「達人プログラマー」だが、実際の内容は、
システム開発に携わるエンジニアが心がけておくべき内容だと思う。
この本に以下のような記述がある。
ソフトウェアの無秩序さは加速度的に増大する。
そのため、質の悪い設計を行わない、または修正することが出来ない理由を明記するなど最初の無秩序を作らないことが重要である。
これはごく当たり前のことだが、分かりやすい例で書かれているため、知識として身につけ易くなっているところがこの本の良いところだと思う。 (3cr/2003-12-25)

本書の内容は、仕事のできる上級プログラマたちのノウハウ集である。
書かれている内容は、ある意味当たり前とも言える内容だが、この当たり前のことを実践できていれば、相当効率の良い仕事ができるのは間違いない。
もう１ランク上のプログラマになるためには、必読の本といえる。
このような優れたノウハウ集を、書店で簡単に手に入れられるとは、いい時代になったものだ。
なお、本書の内容を役に立たないと思う方は、実践経験が不足しているのだろう。
折角のノウハウも、実体験に照らし合わせて読むことができなければ、本当の価値を見出せずに終わるかも。
逆に、今まで何度も痛い思いをしてきた方にとっては、「そうそう！」と頷きながら読めるに違いない。 (/)

この本には、質のよいプログラムを書くことが出来るようになるよう、
70個のヒントを示しながら、良いプログラミングの方法を教えている。
自分も早くこのような本にめぐり合えていたら、と思う。
ヒント38：抽象概念はコード上に、詳細はメタデータ上に書くこと、
など、示唆に富むヒントから基本的なヒントまで、すべて為になった。
いろいろなレベルの方にお勧めできる本です。 (kaizen/2008-07-09)

伝える事柄さえ正しければ、伝える方法は何でも良いというのが間違いであることは、うすうす気がついていました。車の両輪というほど大事なものであることは、本書を読んで初めてきがつきました。そうだったんだ。
ヒント１１： DRY　Don't　Repeat Yourself。

１０　曳光弾
はずかしながら、読めませんでした。
ネットで探したら、「えいこうだん」とのことで、英語はTracer ammunition。
飛びながら光の軌跡を残す弾丸のことのようです。

どきっとしたのは「ヒント２７：仮定せずに証明すること」。
しまった。やられたと思いました。星５つ。
(袴田彰礼/2001-03-16)

システム開発者が何気なく実行していたことが 書かれていて、素晴らしい書籍である。 優秀なエンジニアを目指す方は必読すべき。 その上、ソフトウェアエンジニア以外の職種にも 摘要できる内容である。 (本音のレビューアー/2003-10-22)

プログラムに関する本、というより、プログラマーを職業とする（したい）人の為の本。
啓蒙的な内容なので、技術書として読むよりは、自己啓発の為に読む、というのが、正しい読書スタイルではないでしょうか。
書いている事のすべてを実践する必要は無さそうですが、刺激を受けると言う意味では、すばらしい内容の本だと言えます。 (/2004-02-29)

SEとしての基本が記述されております。2,3度読み返すことを薦めます。システム開発に入る前には、再度目を通すと開発時に注意すべきことが思い起こされ良いものを作れる手助けになるのではないでしょうか？ (/)

　達人とあるので、上級者向けと思われがちであるが、内容は、初心者から脱し、中級、上級者への移行途中の方が読まれると良いです。　私は、すでに上級レベルに達した後に読みましたが、これを若い頃に読んでいれば、もっと楽に上達できたのでは無いかと思います。　テクニックと言うより、考え方、創造力を磨く事が出来る書籍です。 (シンちゃん/2005-03-16)

いわゆる眠くなる本の典型です。書いてある内容もわかりにくい例えや、当たり前のことばかりで、価値のある部分はありません。
特に、実践的なノウハウを知りたいときは、役に立ちません。 (つる/2001-08-10)

この本はプログラミングやアルゴリズムのテクニックというよりは、開発作業をより円滑に、かつ生産的に行うノウハウについて説明しています。

開発を効率良く行うにはプログラミングテクニックだけでなく、作業の進め方や考え方を知る必要があります。それができないと、工数や開発予算を無駄に使うはめになります(私は工数や予算を無駄にしている開発プロジェクトをたくさん見てきました)。
これを読むと作業を進めるにあたっての正しい考え方が身に付きます。また、プログラミングという作業を哲学的な観点からも説明しています。

抽象的な説明が多く、具体例が比較的少ないですが(もちろん具体例が記載されているものもあります)、その場合は、他の本を参照すると良いです。
この本の中でも紹介されているプログラミング作法という本と組み合わせて読むことで、より理解を深めることができます。
この本に限らず、一冊の本だけでなく複数の本を組み合わせて読むとより多くの知識を得ることができます。

曳光弾を使った開発についての説明がありました。名前はかっこよくてインパクトがあるのですが、本文を読んでも普通のプロトタイプを使った開発と具体的にどう違うのかが良くわかりませんでした。これも、他の本を参照すれば理解できるかもしれません。

上記の件はあるにせよ、「下手な言い訳より対策を立てること」「割れた窓を放置するな」など、開発者として抑えておかなければならないポイントが満載です(開発者にとって言い訳は絶対NGです)。特に、ブロークン・ウィンドウ理論(割れ窓理論)の話はとても説得力があります。

現在開発プロジェクトのマネージャーをやっている人や将来それを目指している人、また、タイトル通り「達人プログラマー」になりたい人は、必ず読むべき本です。 (/2009-06-23)

本書を読むのは開発者が多いと思うが、本当に読む必要のあるのは
管理職や経営者だろう。我々開発者は機械ではなく、生きた人間で
ある。人類の長い歴史の中で、技術者が如何にして学び、技術を継承
してきたか。その教訓を現代のソフトウエア開発にも活かすべきである。
優れた技術者は良い仕事をする。あたりまえのことだが、これを忘れ
ている経営者が多くないだろうか？　また、優れた技術者を育成する
のも優れた技術者の仕事であり、会社にとって最も注力するべき仕事
だろう。
本書の一節に、「非常に優れた技術者のほとんどは、やがて独立するか
もっと報酬の多い職種に転職する」とある。この問題をどう捉えるか、
管理職や経営者の方によく考えて頂きたい。 (kaizen/2003-04-17)

ソフトウェア開発は職人の仕事だと思っていたので、思わず購入してしまった。
自分が思っていることとあまり違わないことが書いてあるので、ほとんど読まずに積ん読していました。
多くの書評（レビュー）を読むと、様々な立場で、この本を読んでいる事が分かりました。

「１００人未満のプロジェクトでは、ソフトウェア職人気質に則ったアプローチの方がより効率的になります。」

という記述は、自分の経験則からも妥当だと思う。ただし、能力が低く、なおかつ能力にばらつきがある場合には、１０人になったときから、ソフトウェア工学によった方がよいかもしれない。

職人気質を問題にするには、そこまでの質の高い職人がいる場合だけである。
そうでない多くの人たちには、関係ない世界かもしれない。

職人という響きに何も感じない人は、読まない方がよいかもしれない。
(製造業se/2007-12-26)

製造業でシステム開発に従事しているため、「職人」と呼ばれる人達は
身近で何人も見てきました。
彼らの技術の奥深さ、知識の豊富さには神がかりと思えるほどに凄みを
感じるものが多いのは紛れもない事実です。
NCマシンやCAD/CAMが進化したとは言っても、製造の現場では定量化され
ていない事象があまりにも多く、思ったようには進みません。
そのため、定型処理や荒加工は自動化できても、納品できるレベルに達
するには職人さんに頼ることも多く、彼らなしには製造業は立ち行かな
いのが現実としてあります（「勘所」という奴ですね）。
本書は半ば強引な論調に思える言い回しもありますが、対比によって
理想＝ソフトウエア工学（NC機械）
現実＝クラフトマンシップ(職人)
を浮き立たせ、一見相反する存在の特性をうまく表現しています。
開発技術の具体例を述べているわけではないので、そういう話を期待す
るとガッカリすると思いますが、理想と現実に振り回されがちな開発者
達に対して健全な心構えのあり方も示しており、その意味では個性のあ
る良書だと思いますね。 (なか/2002-07-10)

多くの優れた開発者の大半が、
より報酬の多い別の活動へと移っていき、
しかも、開発者としては頭打ちという状態から
抜け出すために、管理者、起業家、研究者に
ならざるを得ない現状に警告を発しています。

プロスポーツの分野で、花形選手よりも
コーチの方に高い報酬が支払われているような
チームがどれだけ長くやっていけるかで、
例えています。

優れた技術者に育成するために、
徒弟制度を推奨しています。

現在の組織、プロジェクトに違和感を感じる方は、
是非一読してください。 (/2007-04-06)

ソフトウェアの開発に関して、単純な「技術」に着目した手法に疑問を
投げかけている本である。しかし、主張が目新しいかと言えば、そういう
こともない。
基本的には、日本の１９８０年代に行われていた手法そのままであり、
特に「職人」と強調しなくとも日本的な組織ピラミッドには自然と見ら
れた仕事の仕方を米国流に解釈して、特有のXP流言い回しに変えている
だけのように見える。その意味で、ソフトウェア工学に関する主張も検討
はずれだし、ソフトウェア工場に関する記述も、本家の日本での組織は
異なっていたように思う。（どちらかと言えば、工房という感じだった）
ただし、フラットで職能的な米国の労働習慣にはデマルコの「slack」など
でも批判していたので、このような批判!!が米国でもあることはオープンや
マイクロソフト流一辺倒の日本の開発組織でも知っておく必要があるだ
ろう。
もし、日本語で同様の主張を知りたいのなら、菅野文友著「ソフトウェア
エンジニアリング」（日科技連）や保田勝通著「ソフトウェア品質保証の
考え方と実際」（同）、石川肇「日本式品質管理 TQCとは何か」（同）など
が良いだろう。
このようなやり方は日本の組織が勝手に忘れていただけだから。 (/)

U.S.のXPサイトで書評に取り上げられていたので入手してみた。名著とは思わなかったが、これからのソフトウェア開発を考える上で大いに参考になるだろうと感じる内容だった。
親方と、各地を渡り歩く旅職人と、弟子、という比喩で開発チームを表現し、なぜその形態が「優れたソフトウェア」を生み出すことに寄与するか、という論を展開していく。そして職人はどんなスタイルで仕事をしていくのかを説く。
１冊を読み通してみると、この比喩はなかなか多くの場面に適用できると思えるし、掘り下げてみる価値が大いにあるとは思わせられた。ただ読了時にやや物足りなさも感じられたのは確かだ。核となるアイディア部分については、まだまだ掘り下げて検討できるだろう。
しかし開発チームへ発注する場合のやり方についての提案とか、プロジェクトのメンバーを選定する方法など、ぜひそうしていきたい、と思う内容もいくつか含まれている。
高性能なＰＣが簡単に入手でき、市販のパッケージは十分（過ぎるほど）高機能・多機能で、インターネットが当たり前のように使える現代。そんな今の時代から１０年先までソフトウェア開発に関わる積もりのある方なら、一読の価値が有るのではないだろうか。 (mal/2002-05-05)

著者は「エンジニアリング」（工学）にかわって、「クラフトマンシップ」（職人気質）というメタファーを提唱する。そこで重視されているのは、
実作業をとおしてしか体得できない、「設計の勘所」「知恵」のようなものだ。単なる「知識」でもなければ、個々の「技術」でもない。それぞれの
技術を実作業の文脈のなかで、有機的に連動させ発動させるセンス＝「技能」と、その原動力となる「仕事へのプライド」、そしてその伝承の方法。
これらが一般的な開発において最も重要なもので、工学のメタファーで
それらが「負なるもの」とされてきたことが問題だという。
それは、標準プロセス導入や言語研修の充実、資格制度等とは全く無縁の
領域。かろうじてナレッジマネジメントで「暗黙知の共同化」として語られ
る部分かもしれない。ＩＳＯやＣＭＭで何を失ってはならないか、開発現場に疎い企画・導入部門の方にも是非一読を薦める。 (白頭/2002-04-13)

この本では、
従来、「製造業」である「ソフトウェア開発業」の中で
いかに優秀な職人をそだてあげるか？
ということを命題にして、いろいろとかきまくられています。
もちろん、組織論や技術論も展開されていきます。

ドイツのマイスター制度みたいに
・熟練職人
・ジャーニーマン(親方の右腕)
・アプレンティス(見習い)
でやんなきゃだめなめんもあるそうです。
(スペースシャトルうちあげるような大プロジェクトは、従来の
「ソフトウェア工学」でもＯＫだそうです。)

ピアソンから同じくでている
「人月の神話」から引用も多く、一読に価する良書です。

・・・さて、じゃ、今日は「お師匠さん」をさがそうかな。。♪
(やーまん/2006-07-10)

読んで、いいなと思った主張を拾います。
「工業製品の工場での生産にあたるのは、ソフトウェアにおいては出来
　上がってテストを終了したバイナリ－をCD-ROMにコピーしてるときで
　ある。コーディングやテストですら、工業製品で言えば開発・試作工
　程にあたる。ゆえに、工学（エンジニアリング）の世界での大量生産
　の成功例を当てはめる試みはうまくいかない」
これは、ホントにそうだなと思いました。
ソフトウェア開発でのプロセス（ＣＭＭとかＩＳＯとかＲＵＰとか）か、
人かという対比は、サッカーにおけるシステムか人かという問いと似てる
と思う。サッカーではそこの問題は落ち着いてきて、約束事は必要だが、
高度な組織は高度なプレーヤーがいないと成立しない、長期的な!強化
は若年層の継続的な強化が肝要、という所にだいたい落ち着いていると
思う。
ソフトウェアエンジニアもそうだと思う。約束事が少ない小規模な開発で
も、大人数で約束事が増える場合も、何をすればよいか分かって手を動か
せる職人が必要だと思う。 (/2002-08-12)

私は、この本を読まれる多くの方と同様に、ソフトウェア開発に従事しています。常日頃、ソフトウェア工学に基づく手順に則り（極力）、業務を行っていますが、何か違うなと感じていました。
この本では、「職人気質」という印象的な言葉により「ソフトウェア開発は人間が行っているのだ」ということを再確認させてもらえました。
ソフトウェア工学は誤っているのか？
ソフトウェア開発の失敗は、正しく、ソフトウェア工学に則った手順を踏まなかったからだ思っていましたが、この本により、自分なりに、見直してみる機会が与えられたように感じます。 (/)

ソフトウエアの品質問題をクリアする為、新しい開発手法として、昔
からある職人の「徒弟制度」を提案している。（「品質問題」とは、
生産性、信頼性、保守性、可用性等で客等を納得させられない事。）
「徒弟制度」とは、優秀な熟練職人（親方）をトップに、一般職人、
弟子の３階層で、１０名前後のグループに開発全てを任せる。大工や
今流行の料理人等の職人の世界と同じやり方。
従来の開発手法は、全て「ソフトウエア工学的」なアプローチである
が（ＣＡＳＥ等）、機械的処理（作業）が主でない人間中心の頭で考
える作業が主のソフト開発に当て嵌めるのは無理が多いと。
よって、大規模システムではまあ良いかも知れないが、大分の中小規
模システムには向かず、むしろデメリットが多いと言う。
我々は、今在る開発手法が現時点ではまあ一番良く、規模に関係無く、
使うのがベストと思って居たが、これを見事打ち砕くくらい説得が在
る説明を、工学的が何故ダメで職人気質が良いかを、延々と判り易く
説いている。
ソフト開発に係わる人、特に始めに述べた品質の良いソフト作りに関
心在る方には、是非、一読をお勧めしたい。多分、大部分の人は、期
待を裏切られない筈。
文章は非常に読み易く一気に読める。訳書に多い微妙な言い回しなど
で伝わり難い文が多いが、本書には殆ど無い。これは訳者の力も大と
思われる。
３０年位前か？確か、ＩＢＭが「チーフプログラマ制」とか言う、
優秀なプログラマをヘッドに小人数グループによる開発体制で、生産
性や信頼性を両話題になたのと、似てて面白いと思った。
只、疑問に思ったのは、ソフトは形や技術が直接的に目に見え難い為、
評価がキチンと出来ず、これがソフトをダメにして居る最大の原因で、
この為、良い技術や職人気質の優秀なプログラマも育ち難い筈。
良い例が、新人がコーディング覚えプログラムが組めるようになると
（半年から１年）、もう先輩の話など聞こうとしない為、技術指導な
ど何も無い。このようないい加減な所で、良い技術者は育たず、又、
熟練者も技術の違いを見せ付けられない。（尤も、職人世界でも技は
指導でじゃあなく盗むらしいが(^⊥^;)…）
これに対する説明は無く、只、徒弟制度を導入しても、師弟関係が旨
く行くとは思えず、給与で差を付けるべしと言ってるが、これだけで旨く行くのか疑問。
－以上－ (公一/2003-01-10)

プロジェクトを進めるにあたって世の中で言われている事と
自分の経験した事の差を上手く説明してくれている本です。
コンピューター業界に足を踏み入れたけれども不安に感じていた
自分のスキルやそれに対する評価ということに一筋の光を
投げかけてくれたようです。
ソフト開発者だけではなく・・・
むしろ管理者やまわりの人に読んでもらいたい本です。 (arts/2002-04-02)

→個人のＰＭスキルを、経験してきたＰＪ規模で
　レベル分けすることがあります　
　なぜなんでしょう？

→それは、「なんとなく」、「体験的に」
　「大規模」と「中小規模」のＰＭは別物である
　ということを、数多くのＰＭの方々が認識しているからなんだろーなー
　と私は勝手に思っていました

→この本は、その「なんとなく」、「体験的に」という　モヤッとした部分を
　「大規模」をソフトウェア工学
　「中小規模」を職人
　という切り口で、明確に、納得させてくれる本です

→ただねぇ．．言ってることはいいんだけど
　文章がダラダラ続いて読みにくいなぁ．．
　斜め読みで十分かも．． (よこはま　こうたろう/2007-04-07)

いつまでも職人でやってちゃ生産性があがりません。
それとプロジェクト内の標準化や継承ができない。
当たってるけど、改善が必要。 (lmm/2009-06-12)

他の方とは違う観点で。
内容は他の方の解説にもある通り文句なし。
ただ正直訳があまりよくなく、読んでいて疲れます。 (/)

　スタンダードなプログラミングとは何かということが書かれていると思います。速度のみを重視した、解読不可能なトリッキーコードは全くありません。誰もが努力すれば必ず身につけることができるような、そういった内容です。しかし、それこそが、最も効率的で、最も効果的で、最も美しいプログラミング、正にプログラミングの王道あるということが分かります。
　この本を読みこなすには、最低Cの知識が不可欠ですが、それでもCのよく使われるライブラリのみでコードが構成されています。
　また、awkやperlが分かると、更に楽しく読めると思います。 (たか/2002-09-16)

カーニハンの本には、いつも無駄がない。職業プログラマが、キャリアアップの中で経験する試練を乗り越えるための、英知と示唆が凝縮されている。多くのWindows本に見られるようなディスプレイ画面のコピーや使い方で多くのページ数をさいて、判ってしまえば積読になる昨今のノウハウ本とは全く対極をなす。かといって何回な数式や論理を振り回すこともない。読者が経験を積めば積むほどに、深く考えさせられる。新人教育用に、またベテランは自己のスキルの再チェックのためにプログラマから管理者まで必読してほしい。 (トム仙人/2002-05-26)

出版された時から、書店で手にとっていたのでどんな内容は分かっていたつもりだったのですが、実際に読んでいくと、実に深い内容だなあ、と思います。
最初にプログラミングのスタイルの話から入るのですが、いつも私が悩んでいる変数の名前付けなどについて，きっちり結論がだされていて、ためになります。
この辺の問題は、別にプログラマや、プログラマを目指す人だけの問題ではありません。会社でVBAマクロを書くだけの人にもぜひ、意識してほしいと思います。
頭がなかなかついていかないので、読むペースが上がらず、もどかしいのですが憧れのカーニハン大先生の本なので（プログラミング言語ａｗｋでプログラミングに開眼しました）、じっくり読もうと思います。 (トニオ、アントニオ/2001-11-10)

　この本のエピローグの後には「Appendix：ルール集」というものが付いており、各章の主旨やルールがまとめられている。一度読み終えれば、このAppendixを眺めるだけでも充分だろう。
　C、C++、Javaを始め、AwkやPerlによるプログラムも紹介されている。言語による記述の違いが明快で興味が持てた。
　参考書には書いていない今さら人に聞けないような「変数名や関数名の名前の決め方」なども書かれている。
　また、各章のはじめにある著名人たちのことばから得るものも多い。
　我々のバイブル的な書籍であろうという評価には納得だ。 (petitbee1980/2003-08-30)

プログラミング作法に関する類似本はたくさんありますが、本書が一押しです。コーディングスタイル、インタフェース、テスト手法、などに関して、単にお勧め方法が書かれているのではなく、その本意がきちっと説明されているので納得できます。
また、従来作法の間違い指摘なども随所に盛り込まれています。
仕事で作るプログラムのヒントが盛りだくさんに書かれています。
コーディングスタイル、インタフェース、移植性の重要性を説明できますか？自己満足のプログラミングではなく、仕事に役立つプログラムを作成するためには、絶対に読むべきです。かならず役に立ちます。 (春峰/2005-06-19)

プログラムを書き始めると、どんな風に書くのが良いのか、
色々と戸惑うことがあると思います。
より良くするためにはどうしたら良いだろう？　自分の書き方は正しいだろうか？
そう考えたとき、周りに人がいれば訊くこともできますが、
その人が本当に正しいのかはわかりません。
また、自分一人だったらやっぱり解りません。
世界には色々と沢山のコードが転がっていますが、そのどれが正しいのかも解りません。

そんなときにはこの本です。
他のレビューにもありますが、プログラミングの正道が学べます。
読みやすく、効率的で、美しく、正しいプログラミングコードを学ぶことができます。
プログラマの心得などを知ることができます。

これを読まずに良いプログラマになることはできません。
是非、読みましょう。 (いそっぱ/2008-09-22)

この1年に買った本の中では一番気に入ってます。一番参考になったのは英語の文章から適当に単語を取り出して別の文章を作る「マルコフ連鎖アルゴリズム」。他には「単語のハッシュ乗数には37を使え」や「最適化の第一原則は『最適化するな』だ」など。この手のチップスが満載です。最高に笑ったのが「バグかな？と思って他人に質問する前に、まずテディベア相手に自分のプログラムの説明をしろ。そのうち「あ、そうか、えへへ」と気づく」というところ。ほんにとにねぇ、とうなずいてしまいます。初心者向きではなく、ある程度経験がある人向きだとは思います。#ifdefはなるべく使うな、など、よりきれいなプログラムを書く「努力」をする気にさせてくれます。 (えびあん/2005-12-12)

関数リファレンスなどと同じようにいつまでも利用価値が高く、常に机の上に置いておける本だと思います。
C言語を中心に書いてあるが、他の言語の開発者にも読んで欲しい。
チームでソースコードを書くような立場の人には特にお勧め。
新人開発者向けの参考書籍として会社ではいつも推しています。 (thomas2000/2004-05-09)

「プログラミング書法」と基本的なところは変わっていない。彼らの手
法に劇的な進歩があったわけでもない。だから昔「プログラミング書
法」を読んで感銘を受けた人にとってはこの本は有益度が低いかもしれ
ない。けど、入門レベルの人にとっては間違いなく有用な本である。今
からプログラミングのレベルを上げたいと思っている人は読んだほうが
よい。よい習慣やよい原則といったものに古さという問題は存在しないからだ。 (エパメイノンダス/2006-05-19)

　Kernighan と Pikeという2大巨匠が書いたというだけで，職業プログラマでなくとも，プログラミングを志す人であれば読むに値する価値ある一冊．
　多くのソースコードが掲載されているが，すべてが洗練されたコードであると言える．たとえば「リストの中から同確率で１つのデータを取得する」という場面で，普通なら「1度目のスキャン」でリストの個数nを数え，1-nの乱数を発生させて「2度目のスキャン」で値を取得するところだが，それを本書のコードでは，たった1回のスキャンで済ませている．そのエレガントさには「さすがKernighan」と，思わずうなってしまった．
　少し残念なのは，時々日本語の意味の通じないところがいくつかあること．原書を読んで，意味がわかったところも少なくない．もう少しこなれた訳の日本語第２版が欲しいところ． (/2004-04-08)

かなり参考になる内容でした。
そして、プログラミングのくせは簡単には治らないことを実感しました。
納期に追われながら実装してると自然と自分流の書き方になってしまいます。
初学者が読むと効果絶大だと思います。
早いうちに自分流の書き方を矯正しとくと楽ですよ、たぶん・・・。 (ぽるる/2004-09-18)

第一章を読むだけで、自分のプログラムの書き方が大幅に変わるはずです。
当たり前の事ではあるが、その当たり前ができてない人のなんと多い事か、
と実感する事ができると思います。

「３日前の自分のプログラムは赤の他人が書いた物と思え」
こんなよからぬ格言をどこかしらで聞いた事があります。聞いた時は、「なるほど」
と思っていました。この仕事してる人は、こう考えている人も多いと思います。私もそうでした。
が、この本の第一章を実践するだけで、この言葉は私の頭の中から消えました。
何年前に書いたプログラムであろうが関係なくなるはずです。

将来こういう仕事に就きたい学生、職業エンジニア、どちらの人も読んだ方がいいです。

第二章以降は若干の専門知識を必要とします。
ハッシュの理論など、全く知らない人が読むと難解かもしれません。

著者のブライアン・カーニハンは、この他に「プログラミング言語C」という本を
デニス・リッチーと共著していますが、現在でも教科書として使える非常に有用な
著書を書いている人です。 (ぬるぬるず/2007-12-17)

「ソフトウェア開発の名著を読む」で紹介されていたのがきっかけで読んでみました。

章が進むにつれて難しくなっていくのですが、
初心者の方には、とにかく読めるところまで読んでみてはいかがでしょうか？
第１章を読むだけでも十分に価値ありです。

私は第２章のアルゴリズムとデータ構造が特に勉強になりました。
恥ずかしながら、やっとハッシュテーブルについて理解できました。
(なか/2007-02-05)

普通の入門書や文法書が扱っていない内容，「作法」，に関する書です．インデントのしかたから始まり徐々に高度な方向に進みます．Cを勉強したことが無い人には薦めません．他の人には薦めます．
プログラムを書いていて「もっと効率よくできないかな」と思ったことのある多くの人にとっては刺激的で役に立つ本だと思います．また，熟練者の習慣とも呼べる技術を記した本の中では私が知る範囲では最も読みやすい本です．何らかの言語の入門書を勉強した程度の初心者にとっても，この本が教えてくれる「作法の意義」はとっても有益なものでしょう．仮に後半の内容が難しくても，最初の50ページを読むだけでも良い勉強になります． (ま2007/2005-02-05)

この本を読むと、C言語で実装すべき本当に正しい方法が、とてもわかりやすく
具体的に例をあげて丁寧に説明されています。
コーディングスタイルやデータ構造、設計方法やデバッグ、テスト方法など、
実戦にすぐに使えるテクニックやノウハウが満載です。
また、普通のCプログラマーがやりやすいミスなどの説明も、わかりやすく
書いてあるため、とても参考になります。
普通のCプログラマーはとかく#ifdef や関数マクロを使いがちですが、
関数マクロを使うときの陥りやすいミスは、必見に値します。
また、定数を定義する時には、マクロ(#define)を使うことがほとんど常識
だと思っていたのですが、その認識が実は誤りだったということが、この
本を読むことにより認識されられました。

ただ、第３章 設計と実装の章で、マルコフ連鎖アルゴリズムをテーマにして
実装方法を説明していたのですが、私はマルコフ連鎖アルゴリズムにはあまり
興味がなかったので、あまり楽しく読むことができませんでした。しかし、
書いてある内容を理解するためには、興味がないアルゴリズムでも読まなけれ
ばならず、しかも、マルコフ連鎖アルゴリズムがそれ以降の章でも頻繁に登場
してくるので、そこが唯一残念な点でした。しかし、その唯一の残念な点を
帳消しにするほど、実際の業務に役に立つノウハウが満載の本です。

また、デバッグに行き詰った時には、テディベアのぬいぐるみに話しかける(説
明してみる)という話も、とてもユニークで説得力があります。私も、実際に
これと非常に良く似た経験があります。行き詰った時に、実際に他の人に説明
して見ると、今まで思い違いをしていたり、全然気づかなかった事に気づく事が
できるので、この方法は驚くほど非常に効果があります。
皆さんもデバッグ作業に行き詰った時には、是非他の人に、実際に声を出して
説明してみることをお勧めします。必ず効果がありますよ。

なんでもっと早くこの本に出会えなかったのかと、とても後悔しています。
特に、仕事でC言語を使っている人は、絶対に読むべきです！！ (つる/2009-04-07)

他の方もおっしゃっていますが、１～３章までは必読ですが
時間のない人は辞書的にも使えると思います。
ただ、すべてを一読しておくと、明日行うコーディング等にも
役立つ情報が多々ありますので、ぜひ一読することをお勧めします。
目から鱗が落ちるようなサンプルの宝庫です。 (森　博之/2004-11-27)

この本は著者のXPでのリファクタリングの経験をカタログ形式でまとめたもので、ソフトウェアを少しずつ日々改善し、ソフトウェアが肥大化が修正を困難にしないようにする小さな手法の集まりを紹介しています。ソフトウェアの構造に日々手を加える(部分的な再設計の)ための、問題点の発見の仕方、直し方がカタログ化されています。
書いてあることの個々の内容は比較的単純なものばかりですが、まずい設計が示唆する問題点、改善による効果、リファクタリングが可能な条件、リファクタリング時に見落としがちな点の指摘などが十分に書かれていて、リスクと効果をよく考えながらリファクタリングが出来るようによく配慮された内容になっています。プログラミング初級者にとって、とても勉強になる内容だと思いますが、経験を積んだプログラマにも日々のプログラミングのチェックリストとして非常に役に立つのではないかと思います。
JAVAでかかれているため、C++を使っている人には多少違和感がありそうですが、.NETプログラミングにはうってつけの内容だと思います。 (中村拓男/2002-11-10)

達人プログラマ、ソフトウェア職人気質も読みました（ただの流行り好きですね・・・）が前二書がメンタルな部分が多いのに対し、この本は非常に実践的です。
5章まででリファクタリングの意味を知り、後はリファレンス的に手元に置いておきたい本です。サンプルコードが多く明快な解説がされているので詰まったときに調べるのに最適だと思われます。 (木下牛/2003-04-10)

リファクタリングの技法が非常にいっぱいつまっていてとても役立ちます。
通して読むのは1章から3章くらいまでで、後は辞書引きの方が良いでしょう。
1章から3章までのswitch文をStrategyパターンにもっていくやり方はぜひ身に付けて下さい。
リファクタリングも繰り返し行っていけば、不吉な匂いがするコードを書く前に気づき直すこともできるようになると思います。
直接生産性に影響する技術ではありませんが、保守がしやすく、すっきりとしたコードを書けるようになるので1度読んでみることをお薦めします。 (貨物列車を止めた男/2004-10-19)

リファクタリングするための個々のテクニックのカタログを説明する
前に、それらを適用するストーリーを例示する章がまず最初に用意さ
れています。そのため、第１章さえ読めばやりたいことの本質が会得
できるので、非常にストレスなく読めます。（この構成は、ＧＯＦの
デザインパターンや、ランダル・L. シュワルツ の「初めてのPerl」
に共通する方法です）
導入の章さえ読めば、個々のリファクタリング技法の節を１節ずつ電
車の中、空き時間等に少しずつ読んでいくことができます。途中の節
から気軽に再開できるので、忙しくて読めない時期があっても最初か
ら読み直しにならない所が嬉しいです。
順番によまずとも拾い読みでも構わないし、もっと言えばカタログだ
から全部読破しなくてもいい、と割り切れるのがいい所です。なんと
なく持ち運んでいつのまにか、読み終わってしまいました。
ファウラーの本の中では、アナリシスパターン（挫折しました）、
ＵＭＬモデリングのエッセンス（若干難しかった）と比べて、
極めて読みやすく買って無駄になることがない本だと思います。 (悩み多き頭でっかち/2002-11-17)

プログラマであれば、プログラムを書いているときに時間（納期）と理想のコーディングにさいなまされたことが1度はあるのではないでしょうか？ （もっと、綺麗に書きなおせるが時間が無いといったジレンマ） また、プログラムの設計を行っている際にこの設計で良いかもっと良い設計があるのではないか？と悩んだこともあるのではないでしょうか？
この本ではリファクタリングと言った手法にプログラムの振る舞いを変えずにソースコードの中身を変えていく手順が説明されています。 私はこの本を読むことによって、設計に自身が持てる（後で変更が容易なので）ようになりましたし、妥協のないプログラムを書く気になりました。
また、この本を読むことによって、見やすいプログラムを書くための原則も身につけられます。 プログラマであれば必読の本だと思います。 (鈴木純一/2001-05-08)

ソースコードを修正（再構成）する常套手段をパターンとしてまとめ、それに名前を付けて分かりやすく説明した本。最近はIDEなどの開発ツールが、この本のリファクタリング名に沿って、各種リファクタリングを実装しています。プログラマーにとって必須アイテム。 (osm10/2003-07-03)

オブジェクト指向に乗り換えて、なにが良かったかって、それは、可読性の高い、変更しやすいプログラムが書けるようになったこと。オブジェクト指向について、いろいろ勉強したけど、オブジェクト指向はプログラミングできて味がわかった。その味付けを学べたのがこの本。テストファーストの意義もよくわかるし、高価だけど、効果はそれ以上アル。オブジェクト指向でプログラムを書き始めたら、読んでほしい。きっとオブジェクト指向の目が開けるよ。努力はいるけど、報いも大きい。 (kosaru/2005-11-03)

これはｲｲです。
なんというか、プログラミングのベストプラクティスが載っているわけではありません。
しかし、
「最初からすげぇプログラムなんてできるわけないじゃん。とりあえず作って、後から体質改善すれば～？」
みたいなノリでプログラムってやっていいんだ。って感じです。
体質改善の為の基本的な処方箋が、ここにはあります。
ケント・ベック著の「テスト駆動開発入門」も、あわせて読めば、効果的かも。 (風の又兵衛/2005-08-29)

リファクタリングをマスターすれば人生が変わります。
これ、大げさに聞こえますが、本当の話です。

今まで幾つか改修案件をこなしましたが、
仕様の大変更による数万ステップのコードの改修も、
他人が書いた数万行のフォーム、5千行を越すメソッドの改修も
改修前に事前にリファクタリング・・・
いや、リファクタリング80％・改修20％の割合で
可読性を徹底的に向上させながら改修を行ったところ
デスマを回避できた上、土日はしっかり休日をもらえるまで進捗が進み
深夜残業もほとんどなくなり、納期に間に合わせることができました。

この本のおかげで、悲惨なデスマ環境から開放されるに至ったのみならず、
「コードも商品」との哲学を持ってコーディングに臨めるようになり、
お客様から絶大な信頼を頂けるようになったのは、紛れもない事実です。

この本を著されたファウラー先生には、本当に頭が上がりません。m(__)m

ただしリファクタリングの最大のコツは、

「プロジェクトリーダーには内緒で行う」

これ一番肝要です(爆)

それはともかく、騙されたと思ってサンプルコードを実際に手で打ち込みながら
この本を二度三度繰り返し読めば、貴方のコーディング能力は劇的に向上し
デスマから開放され、幸せに一歩近づけます。是非お試しください。
(/2008-10-19)

いつもながらマーチンファウラーの本を読むと技術者としての自分が一歩も二歩も成長した気がするから不思議だ。
この「リファクタリング―プログラムの体質改善テクニック」はベテランよりもむしろ新米プログラマさんとかに読んで頂きたい。
そうすればプログラミングの正しい作法を身につけることができると思う。僕自身、フレームワークを作ることが結構あるがその際にはリファクタリングのテクニックは必ず採用している。もし今までに自分のプログラムが読みにくいと言われた経験があるのなら迷わず読むべし。
可読性向上の一番の特効薬である。 (あーるみき/2005-06-28)

　プログラムを作り変えるのをマネージャに認めさせるのは大変です。実際、適当に直すと、直したつもりが悪くなることもあります。
　リファクタリングとは本書中「外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェア内部構造を変化させること」となっていますが、私は「プログラムの資産価値を上げる」と解釈しています。
　本書は大きく４部構成です。
　まず１章で具体的なリファクタリング例を一つ示し、全体を説明します。
　次に２～５章で、、
　　・リファクタリングの意味、実施理由
　　・管理者へのアプローチ
　　・リファクタリングする個所の発見（アンチパターンに類似）
　　・テストの構築
　を説明し具体的なカタログに入ります。
　カタログには、「名前・動機・手順・例」が示されます。これにより、適切なパターンを選び★内部構造だけを変化させる★ことができます。
　最後、カタログの後にリファクタリングツール及びまとめがあります。
　本書中、いくつも相反するパターンがあります。これは動機が異なる場合に、変更方法が逆になるということですが、非常に面白いと思います。
　尚、本書はデザインパターンの知識があると読み易くなります。 (cxj01155/2003-07-11)

オブジェクト指向のプログラマ必読の本。非常に膨大な天才たちの知恵が詰まっている。これを読んで明日からリファクタリングを楽しみましょう。原書もかなりわかりやすい英語で書いてあるので、英語で読める方は原書を読んでも楽しめるかもしれません。 (ws133/2004-10-20)

リファクタリングの勉強するなら、この一冊は必要不可欠でしょう。

この本の対象となる読者は、職業プログラマ及びオブジェクト指向言語です。
解説はすべて、Java言語で行われていますが、他のオブジェクト指向言語を
理解していれば、問題なく読み進めることができます。

リファクタリングの重要性についてはもちろん、テクニックを細かく解説してあり、
実践に役に立ちます。

この本の核となる部分は第６章からリファクタリング・カタログです。
「名前、要約、動機、手順、例」の順で全てが書かれていて、
非常に読みやすく、後から調べ直すのも簡単です。

デザインパターンについても少しでてくるのですが、
知らなくても大丈夫です。どちらかというと、
デザインパターンを勉強する前に、読んだほうが良いと思います。

専門用語についての意味の説明がもう少しあった方が
私は良かったと感じました。

４００ページを超えるボリュームですが、
あっという間に読めました。

是非、手元に置いておきたい一冊です。 (なか/2008-02-24)

この本を読んでから、プログラミングに対する考え方が変わった。
今まで自分が書いたプログラムをすべて書き直したい衝動にかられました。
値段は張りますが、それ以上の価値があると思います。 (たけぼーん/2005-02-28)

昨今のソフトウェア開発においては大抵がRDBMSベースのもので開発ツールも整っており、
アルゴリズムや計算量、メモリ使用量およびそれらの結果としてのパフォーマンスなどを
真剣に考えないと全く仕事にならないケースと言うのはあまり無いと思われ、それはそれで
幸せな時代とも言える。

本書はそんな「幸せな時代」に逆行する形となるが、上記で述べた内容（アルゴリズム、
計算量、メモリ使用量、パフォーマンス）をメインテーマとしており、それぞれ

1)提示された問題の解法を著者の視点で説明
2)ソースコードとして具現化
3)ソースコードについて更なる考察
4)同じテーマでの練習問題の提示

と言うスタイルで記されている。
特筆すべきなのは問題を解くにあたって筆者が最終的なソースコードにたどり着くまでの
「思考」（いわゆる設計作業）が文章や擬似コードや図表で表現されている事である。
他のアルゴリズム関連の書籍では大抵いきなり完成形のコードが出てきてそれらを説明して
終わりと言うパターンが多く、それではただの丸暗記であり、初級プログラマにとって
本当の意味でのトレーニングにはならないと思う。

個人的な見解だが特に初級プログラマのステップアップの壁に一つには「設計と言う概念の
理解」が挙げられると思っており、本書はそんな概念を掴みきれていない初級プログラマにとって

あぁ、プログラマの頭の中ってこんな風に試行錯誤しながらコードを紡ぎだすんだ！

と言う感覚が味わってもらえるような造りとなっており、非常に好感が持てる。
練習問題が結構多いので勉強会のネタにも使えそうである。
理解しながら読み進めるのは意外と大変かもしれないが読み終えた時にあなたは
一皮むけたプログラマになっているはずである。 (コモヒコ/2007-04-02)

　今まで、アルゴリズム関係の本をいろいろと読んできた。しかし、この本は何なんだろう。自分ではベストだと思っていたアルゴリズムが、かなりの確率で否定される。
　「これ以上は無理かな？」と思っていた巨匠アルゴリズム＋自己流アルゴリズムが、それ以上の高効率で処理されている。あるいは、「出来ないよ、そんなこと！」を「可能」にしている。まさに、「思い込み」は禁物だということを改めて感じさせてくれる、アルゴリズムにこだわる人には、まさに「目のウロコが落ちる」一冊。「速い」と「メモリを食う」は相反しないことに気づかされる。
　近年のコンピュータの高速化により、アルゴリズムの効率が無視されがちな企業プログラマには是非とも読んでいただきたい一冊。
　パズル的な面もあるので、アルゴリズムとパズルが好きな方は是非とも手に入れるべし! (takamasasuzuki/2003-04-17)

この本は、プログラミング言語を学ぶという本ではなく、どのようにしてアプローチをしていくかという本です。たとえば、ある著名人は、よいプログラマーとは、机上でまず詳細設計を完璧にするものだといっていましたが、まさにその通りのことが書いてあります。
いきなりプログラムを書くのではなく、色々なアプローチからプログラムの骨格を作り上げていくことが出来る一冊です。
中堅プログラマーの方が、上級プログラマーになるためには必須の本だと思います。私のバイブルでもあります。 (李牧/2001-06-14)

コンピュータ・プログラムに手を初めて２０年近くなる。最初の２，３年は先輩が色々手解きをしてくれたのだが、答えられない内容にまで掘り下げて質問すると別の仕事を与えられたものだった。４，５年で自立すると立場が逆転した。過去に苦い経験をもつ私としては、常に最新の情報や考え方、パラダイムの転換といった、この職に不可欠な知識（知恵）を探求し後輩達に伝授していったつもりである。１０年も過ぎるとリッパなシニア・プログラマ（エンジニア）となる。それまでに獲得した知識を最大限に活用して仕事をこなしていく。が、ここ数年マンネリした技術に嫌気がさしていた時に、この１冊に巡り合った。プログラミングに携わる人には座右の書となるであろう。久しぶりに良い師匠に出会えた。わかる人にはわかる本である。初心者には敷居が高いかもしれないが丁寧に解説されているのできっと（数年後でも）役にたつはずである。技術的なことだけでなく、日々精進の仕方まで何気なく書かれている。著者にあってみたくなること請け合いだ。 (/2004-05-02)

今までいろいろなアルゴリズムの本を見てきましたが、
ほとんどが理論的であり、眠気を誘うものばかりでした。
この本は、アルゴリズムが何であるか？データ構造とは？を
根本から解説しているのですが、プログラマであれば、
非常に興味をそそられる内容になっています。
サンプルプログラム等は、CやC++で書かれていますが、
他の言語しか知らなくても十分理解できるレベルです。
参考本情報が豊富にありますし、少しずつ読んで見ようと思います。 (/)

古典ともいえる本だが、内容は現在でもそのまま 通じることが書いてある。 すべてのプログラマーに読んでもらいたい本だと思う (春峰/2001-10-30)

最高です。濃密です。凄く面白いです。笑ったり驚いたり唸ったり…(^^;
Programmerに必要とされる基本姿勢・基礎教養を学ばされます。小手先の対処法や、用意されたものを使ってなんとなく…ではなく、本当に美しいProgramingがどういうものであるかを教えてくれます。
私自身は初心者で、正直"敷居が高かったか(T T)"と思いもしましたが、あまりの面白さに、普段使わない言語についてもいろいろ調べながら読んだくらいです。
もう少しレベルが上がった時にまた読んで、また興奮するつもりです。(^^; (国語辞典/2005-06-19)

「珠玉」ってなんて読むんだろう？興味を持ち、「本質を見抜く」というサブタイトルに惹かれました。プログラマーならば、アルゴリズムが重要であることは誰もが知っている、そしていくつかのアルゴリズムを知っていることだと思います。しかし本書を読むと、なぜアルゴリズムが重要なのか？どうすれば高速化できるのか？わかりやすくなるのか？メモリを減らせるのか？といった疑問が解き明かされていくのです。ページをめくる毎に”納得！”させられます。今までの漠然とした理解ではなく、本質を見抜いた理解に達すると、視界が開け非常に気持ちがいいものです。
だまされたと思って、一読ください。決して損はしません！！ (/2001-05-04)

本書は、「小さいメモリの中でいかにソートを行うか」や「いかに速い検索を行うか」というテクニックがぎっしり詰まっている。残念なのは、著者がアルゴリズム至上主義になってしまっておりコンピュータの内部生産性が低いコードを徹底的にけなしている。「いかにして小さく速いコードを書くか」がテーマになっている。そのためチームで開発する際に重要な「コードの把握性」などを犠牲にしているコードを推奨していたりする。しかし、現代においてはコンピュータのリソースなどよりもプログラマなどの技術者リソースの方が希薄になっている。たとえば、５万円余計にだしたり１年待ったりすれば倍速いコンピュータが手に入れられる可能性はかなり高いが５万円よけいに払ったり１年待っても倍速いコードを書いてくれる技術者が登場する保証は無い。しかし先人の苦労を伝えるという意味では非常に重要な書籍だと思う。ところで、携帯電話向けプログラマなどにはおすすめできる。 (/2003-03-24)

内容は、古典的なプログラムの香りがしますが、この本が伝えようとしていることは、いつの時代のプログラマにも必要な感覚？（意識）だと思います。
しかし、そろそろプログラマとしても一人前になったかな？と思っている人が読むと、自信喪失するおそれがあるので注意が必要です。:-P (/)

　プログラムの設計について、問題の定義、アルゴリズムの選択とデータの表現方法、ま
たチューニングなどについての大変面白い本。なぜ自分の書くプログラムがいつも酷く複
雑で、可読性が低く、メモリを食い、実行速度が遅いのかとなやんでいる人に向けられた
本だと感じました。適切なアルゴリズムを用いて、複雑な問題を単純なコードでエレガン
トに解くのは楽しいものです。
　全体はコラム単位で構成され、コラムは本文と、得られた教訓による「原則」、そして
練習問題と読書案内からなります。読書案内は、特定のトピックに対してより深く内容を
理解したいプログラマに向けた書籍の紹介です。
　この本を通読することで、読者はアルゴリズムの計算量に対する経済感覚を身につける
、あるいは少なくとも意識できるようになるでしょう。現実の問題に対して、自分がどの
ようなデータ構造とアルゴリズムを用いれば十分な速度で実行できるだろいうか、という
事が判断できるようになります。
　著者は本でしばしばライブラリ関数やC++のSTLを使用するよう主張します。それらは
多くの問題に十分に高速で、にもかかわらずそれを用いないのはプログラムを不必要に複
雑にしている、と考えています。つまり、何が何でも特定の問題に対してカリカリにチュ
ーンされたアルゴリズムを用いよなどという主張をした本ではありません。
(student/2009-03-22)

1.CVSによるバージョン管理
2.JUnitによるユニットテスト
3.プロジェクトの自動化
という三部構成で、それぞれのツールの有効性と具体的な使い方が説明されています。
基本的な使い方しか書かれていないので、これらのツールを既に使っている人（達人？）にとっては、新たに学ぶものは少ないでしょう。
また、上記のツールを使ってみようという意欲のある方は、インターネットを利用して、より新しく詳しい情報を調べられるはず。

ほいじゃ、本書の対象となる読者は誰かというと、「バージョン管理なんて意味あんの？」とか「単体テストめんどくせー」などと言っている人。
こんな人が身近にいたら、本書をそっと机の上に置いておくのだ。

内容は良いのだが、邦題がいまいちなので星いっこ減らしたぞ。
(殿下/2007-02-18)

CVSによるバージョン管理から始まって、
JUnitによる単体テスト、自動化までを説明している。
プログラマーレベルではなく、リーダー、管理者向けな感じの本。
テストファースト等のXP的開発を始めようとしているチームには良いと思う。
というか、今やってる仕事そのままだったので、星5つという話。 (hayapu/2005-04-09)

プログラマ志望の人にはぜひ読んで欲しい。
プログラマになってしまうと、仕事が忙しくて読む時間がない人が大勢います。
学生のうちに読んでおくのがいいかもしれません。

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

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

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

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

題名の通り、完璧なプログラミングコードを書くための指針をまとめたシリーズの上巻。
良いコードを書くために守るべき習慣（プラクティス）が次々と述べられており、自分で実践したくなることはもちろん、開発者仲間にも教えたくなるような事柄が満載である。
プログラミング言語は特に指定されておらず、例外は多少あるものの、基本的にどのプログラミング言語を使うときにでも共通に使用できるテクニックが中心に述べられている。
例として上げられている言語はVisual BasicとC/C++、それにJAVAが多いが、コードは簡単かつ明瞭に書かれているため、これらのプログラミング言語を使ったことがなくても、問題なく理解できるだろう。
非常にボリュームが豊富なため、読み切るのに苦労するかもしれない。
しかし、多くの内容が理路整然とわかりやすくまとめられているため、量が多くて苦痛になるという感覚はあまり感じなかった。
また、経験豊富な開発者なら、既に知っている内容も多く含まれているかもしれない。
だが、既知のテクニックを再確認できるという点で、読む価値は十分あるだろう。
完全な初心者には向かないかもしれないが、もっときれいで読みやすいコードを書きたい全ての開発者、プログラマの方々に是非手にとって欲しい１冊である。 (the_world/2005-07-31)

　第１版を読んだ時の感動を忘れることが出来ない。コンストラクション（広義の実装）についての「MUST」はカーニーハン等で知っていたが、「WHY」について、ここまで系統的にかつ実践的な書物が存在することに驚きを禁じ得なかった。ちょうど暗いトンネルに先に見える明かりを見つけた時の昂揚感とでもいうべき感情であったような気がする。
　第１版の出版から１０年が経過し、第２版が出版され、早速目を通してみた。第１版では抽象的な話題になりがちであった「ADT：抽象データ型」や「オブジェクト指向」がJAVAやVBによる実装例を得て、現実のソースコードとして記述されている。筆者の豊富な経験が盛り込まれている第２版は決して、第１版の焼き直しではないことを実感した。
　第１版を読んだことがない、新人プログラマー諸氏は第２版をまず読むことをお奨めする。２冊で１万円を超える投資は決して無駄にはならない。さらに本書の参考文献リスト（邦訳名が充実し検索がしやすくなった）を使って守備領域を拡大していくことが「職業としてのプログラマー」には必須であると確信している。
　 (銀鼠/2005-05-03)

　　なんとなくノリに近い雰囲気でこの業界に入った．
　　プログラミング言語の解説本片手に，あるいはおじさんにいろいろ言われながら
　　プログラミングを覚えた．
　　もう自分は一人前の開発者だ！

というひとが読むと，自分が実はちっとも一人前ではないことや，
ただ動くコードと，それ以上の価値があるコードの違いが理解できる本です．
設計やテストなど，内容的にも大変網羅的で，無駄のない実践的な本です．

また，例として掲載されているコードはVBやC，Javaがほとんどですが，
細かい文法規則を論ずる本でもないので，これらの言語を知らなくても読むことに問題はないと思います．

一見するとボリュームはすさまじいですが，
この内容を経験のみから学ぶ非合理さ（バカバカしさ）を考えれば
むしろコンパクトにさえ見えてきます．

書架に置いといて，定期的に時間をかけて読み直したいと思う本です． (EVAM/2006-10-01)

たしかに厚いし、小遣いで買うには高いかもしれない。
でもね、いいね、この本はいいねー。
読みやすいので、厚さに臆することなかれ。得られるものは計り知れず。
中立的な立場で書かれているのが気に入っている。
良いコード、悪いコードの対比も楽しい。
また、各章末で紹介されている関連書籍（寸評が参考になる）が良いんだなぁ。
この本を起点に、多くの有名書籍にめぐり合うことができました。 (殿下/2006-08-08)

会社に入るなり、上司から「これをまず読みなさい」と渡された一冊。
基本的な内容でありながら、今読み返しても学ぶことが多い。
今年の新人にもこの本を渡したが、彼らにもやがて部下が出来た時に、その部下に渡してもらいたいと思う。

高い値段に見合う一冊。
プログラマなら必携だと思います。 (駆け出しプログラマ/2007-08-02)

本の厚さと、上下巻というボリュームで、
なかなか手を出せずにいた本ですが、
読んでみるとスラスラとあっというまに読み終えました。

美しいコードを書くのは永遠のテーマですが、
沢山のヒントが所狭しと書いてあり、感動しました。

もうこの本無くてはコーディングできません。

プログラマを語る以上は、この本は読んで置くべきです。 (なか/2007-02-05)

かなり評判がよかったので買ったのですが、みながそこまでべた褒めするほどでは
ないと感じました。
第1版も見ることができましたので、見てみたところ、
第1版の方が絵も多いし、訳もよく、説明も分かり易いです。残念なことに。
第2版だと、後半は【下巻】に収録されているので両方買うとかなり高額になります。

初心者の方にお薦めします。
上級者の方が読んでも、自分のやっている作法の正しさを確認するだけになるでしょう。スランプの時にどうぞ。 (大工さん/2007-08-21)

読んだことのない第１版と、基本は変わってないのかも？と想像しました。
実経験と重なるプロジェクト／システムは、後から参入でも非常にやり易かった。
全く重ならない所は言うまでもなし。

どうも、この本に書いてあることを理解できない、知らない、経験ない人は、
変なプロジェクト体制、変な設計、変な実装しても問題の本質を理解できない
ようです。

きついこと書きますが、この本の内容を理解できない人は、正直言って
この業界辞めた方がいいと思います。
実践は・・・できるところで働きましょう。 (yamasato/2006-11-12)

その前、これを読んでからなってください。 (solid code/2005-09-08)

上巻が良い内容でしたので、迷わず下巻を読みました。
上巻よりは少し難しいかったですが、それでも大変読みやすい本でした。

内容は、テスト、デバッグ、リファクタリング、コードチューニング、ツール、
レイアウトについてで直ぐに実践できる内容ばかりで業務に生かせます。

上下巻合わせて手の届く場所に置いておくべき、プログラマ必須の本でした。 (なか/2007-02-05)

上巻はあまりそうでもないですが、下巻は第1版とは大分趣が違うように感じました。オブジェクト指向、C++、XP、PMBOKなど、最近の手法やプロセスについての記述が多く、職人技的な内容(個人的にはこちらが好み)の割合が少ないようです。まあ、この辺の新しい知識もこれからは必要ですが...。 (amazon_hk/2007-03-30)

コードコンストラクションにまつわるトピックを完全に網羅しています。参考文献が豊富に紹介されており、変な入門書より役に立つでしょう。

値段が高めですがその価値はあると思います。
ITエンジニアには特にオススメです。 (やすます/2009-05-20)

上巻の前半までは仕事でプログラミングに関わる方なら皆読んだ方がよいです。
上巻の後半から下巻にかけては特にこの本ならではという内容ではありません。
目次を見て興味がある方だけ読めばよいと思います。 (/)

リファクタリング時に、こういう論拠で、こうしたら、
デザインパターンになりました、という具合に、
具体的なサンプルを通じて解説してくれます。
先人のノウハウの固まりだから、設計の段階から、
うだうだせずにデザインパターンを使おう、という意見に、
何となく違和感を感じている人には、
特に、読む価値のある一冊だと思います。 (palemoon/2005-09-16)

～リファクタリング、という言葉を意識するようになったので、買ってみたのがこの本です。ぼくはデザインパターンはよく知りませんが、例をあげて丁寧に方法を示してくれています。本の中では、なぜリファクタリングが必要なのか、また、デザインパターンの適用の仕方を、筆者の経験を交えて説明してくれます。例として、問題のあるコードについて、一般的なデ～～ザインパターンの適用手順と、具体的な適用例を示してくれるのでとてもわかりやすいです。むやみにデザインパターンを適用するのではなく、状況にあわせてリファクタリングを行うことを教えてくれます。～ (/)

この本は、リファクタリングによって設計を改善して行く際に、デザインパターンのエッセンスを取り入れて設計を良くしていく道筋を取り上げています。
最初からデザインパターンを使うのではなく、リファクタリングによって、段々とパターンに近づけていく様を、「先輩とペアプログラミングしている」かのように読み進められます。
『オブジェクト指向における再利用のためのデザインパターン』、『リファクタリング』の両書を先に読んでおけば、本書の内容はすんなりと理解できるはずです。 (/)

単なるデザインパターンの説明だけの本よりは理解しやすいです。
どこもかしこも「デザインパターンを使えばよい」ということではなく、
「小さい金槌でこんこん叩けばいいところを大きな金槌を振り回すよう
な状況でデザインパターンを使うのはよくない」という内容の記述が
あり、はっとしました。
自分を含め、勉強したての人ほどついその傾向があるとおもいます。
じっくり読むことでリファクタンリグもデザインパターンへの理解も深まります。 (/)

いかなる仕事も，それを実行する「人」にかかっている。このあたりまえのことをあたりまえと放置せず，「人」の仕事の質を上げる，または下げる要素について広く深く分析している。特に阻害要因についての記述は，組織で仕事をしている人ならば誰しもが頷け，自分の組織にこうなって欲しいと希望を持ち，
あるいは自分の組織のダメ具合に暗澹たる気持ちになるような内容である。経営者やリーダーたち全員に読んで，本書の示唆通り実行して欲しい本。多数の読者の声によって，そのために復刊されたのだから。 (kasm/2001-11-26)

謳い文句としてはソフトウェアプログラマーの管理手法とそのあり方についてのお話。
だが、管理という概念について非常に考えさせられる有益な本だと思う。
実験結果もあり、童話のようなものもあり、説得力も高い。
ただ、内容的には「デッドライン」と多くの部分がかぶっている。
気になったのが、後半部から訳が直訳になっていて、
日本語としてというか文章として成立してないと感じる部分が
非常に多く、翻訳ソフトを通した結果でも見ているかのような
文章になっていた。
「デッドライン」のほうは完璧に日本語に感じられたので残念。 (んにゃ/2004-11-27)

1987年に出版された第1版にプラスして「ピープルウェアの小さな続編」を設けたこと、それと電子メール環境の繁栄により一部の記述を変更した形となって第2版が出ました。実は第1版は読んでいないのですが、記述されている「プロジェクトにおける人」について如何に振舞うか、扱うかの内容は今も15年前も変らないです。特にプロジェクトにおける管理者の役割についてはプロジェクトマネージメントの精神論的な内容に思えて、「ここまで人を大事にすべきか！」と思われるほどです。作業環境について一人あたりのスペースについても記述されていましたが、目に見えない効果をどこまで管理者層が納得して動けるか・・・というのは大きな課題です。
これまでの日本において欧米に追いつけ、追い越せで実施してきて戦後（そのときは皆中流階級）、そして日本が世界に到達したときに得た次なる目標、次なる仕事の仕方が見えなくなり、それとともにITによる世界的なデフレ化。そのために「人」も他と同じように頑張れば食べていけた時代から、何時の間にか360度評価、実績主義へと変貌したかと思ったら、次は「整理解雇」に意味が取って代わったリストラが台頭してきている現在を思うと、「ピープルウェア」は誰のために？と悲しくなったりします。
お互いの利益を超えた（というか利益を考えずにお互いの幸せを供する）仕組みが近いうち訪れるのではないのかと考えています。資本主義は競争社会であり、かつかけがえのない地球を蝕んできたことを徐々に多くの人が気づき、良い方向に向かおうと努力しているように思われます。そのときには「ピープルウェア」の真髄が随所に発揮される世の中になっているのではないでしょうか。
「人」について一番幸せな方法を皆で考えましょうと訴えてくれた大切な一冊になりました。 (やんちゃ青/2002-07-02)

初版は１９８７年だから、もう２０年にもわたって読み継がれているソフトウェア開発者の「古典」である。著者のトム・デマルコは、８０年代後半から９０年代にかけて活躍したシステムコンサルタント。構造化技法のひとつである「デマルコ法」の考案者としても著名である。

ドッグイヤーとかマウスイヤーと呼ばれるほど進歩の早いこの業界にあって、本書がこれだけ長い間読者を魅了し続けるのは、まさに書名のとおり、ハードウェアでもなく、ソフトウェアでもなく、それを作る「人」に焦点をあてた論考だからであろう。

最近でこそ、コーチング理論やメンタルヘルスなど、ヒューマンリソースのケアが重要視されているが、当時、開発者のやる気や、生産性の高い作業環境、チームビルディングの重要性を正面から論じた本はこれ以外にはなかったと思う。

現場のソフトウェア開発者の視点に立って、管理者や会社側の不条理を追及するというスタンスなので、当時プログラマだった筆者は「わが意を得たり」と密かに喝采を送ったものだった。チームで回し読みしては「パーキンソンの法則」「スパゲッティディナー効果」「チーム殺し７つの秘訣」「黒服チームの伝説」などなど、議論白熱して終電を逃したことも懐かしい。

当時の仲間はいまや皆管理職になり、本書からは攻撃を受ける立場になった。今、第二版を読み返してみると必ずしも肯ける話ばかりではないが、それは単に立場が変わったというだけではなくて、きっと初心を忘れてしまっているからなのだろう。

というわけで、筆者にとって本書は、この業界に身を投じた当時の初心に立ち返るための大切な本であるが、もちろん若い方にも勧めたい。頭のかたい上司、理不尽な上司の下で働いている方なら、きっと溜飲が下がること請け合いである。 (丁三/2006-06-17)

旧版とあわせて、折に触れて手に取ります。


・・・プロジェクト成功の鍵は、「技術」「プロセス」「人」の３つ。

ＩＴ技術者にとって「技術」は生命線ですが、

プロジェクトの円滑な推進には「プロセス」と、

そもそもの「人」・・感情を持つ人間の営み、組織論の理解が

十分条件になると再認識し、

チームのあり方や

自身の行言動を振り返ることしばしばです。 (papillon/2007-08-22)

→この本は、「構造的に知識を得る」本ではありません
　「感覚的に知識を感じる」本です
　よって、どのページをめくっても
　読者に知識を感じる触覚がなければ
　得るものは何もありません．．

→しかし、ひとたびその触覚に触れたのなら
　生きた知識が、まるで血液のように
　全身をめぐります
　深い見識に裏打ちされた、吟味された言葉たちが
　栄養となって．．

→「プログラムは夜できる」
　「頭脳労働時間　対　肉体労働時間」
　「お手玉使いの曲芸師を雇う」
　「チーム殺し、７つの秘訣」
　私には、上記のような言葉たちが
　ゆっくりと、しかし確実に
　体の中をかけめぐりました．．

→トム・デマルコ流の比喩、暗喩がかなりあります
　悔しいけど、全体の２〜３割は、
　どう考えても、その真意がわかりませんでした．．

　数年たった後、もう一度読み返して
　自分の触覚がどれくらい伸びたのかを
　確認したいと思います．． (よこはま　こうたろう/2007-06-18)

今でこそモティベーションマネジメントという言葉が
聞かれるようになってきましたが、まさにこの本は
モティベーションマネジメントを堂々と唱えたパイオニアです。 (hiro_kl/2005-07-22)

ソフトウエア技術者なら、読んでいて「あるある」の連続ではないでしょうか。アメリカも日本と大差ないのかと意外でした。（初版以来ここ１０数年の状況は変わっているのかもしれませんが。）チームのモチベーションやヤル気が現実の生産性を大きく左右するのを何度か見てきましたが、それがアタリマエのことだよと裏付けてくれたようです。オフィス環境や働き方そのものに、まだまだ進歩の余地がありそうです。これからの管理者が智恵をしぼって新しいアイデアを出していくための、参考書のひとつとして推薦します。 (ビリー/2002-01-31)

会社勤めをしたことのない、一学生の感想です。
いままで、管理職っていうのは
「給料はいいけど、上司と部下の板ばさみで、
責任ばかりがのしかかってくる面白くない仕事の代名詞」
っていうイメージしかなかったけど、
（貧弱なイメージですね。ごめんなさい・・・。）
この本を読んで、管理職っていう仕事は、
存在するべく存在して、しかも、特殊な能力を要求される、
創造的な仕事なんだと気づかされた。
島耕作なんかに出てくる、派閥争いにあけくれて
本来の業務がなんなのかわからないような管理者には
魅力を感じませんが、
この本に書かれている魔法使いのような管理者
（決して魔法を使っているわけではないのですが）
には、心底、憧れますね。 (kaizen/2004-08-30)

P234
「知識労働者の典型的なチームがさまざまなスキルを持っていて、そのほんの一部をボスがマスターしているだけだ。」
「活動中の固く結束したチームを観察すると、仲間同士のコーチングという、ごく当たり前の健康的な行為が常に行われていることを目にするだろう」

副題にある「やる気こそプロジェクトの成功の鍵」のひとつの鍵がここにあることがわかった。

(/2009-01-29)

ソフトウェア開発（プロジェクト）で、
大事にすべきことが項目に分けられて
綴られている著作。

購入してから４年の歳月が過ぎ、
当時と異なる立場となり読み返してみると
「当たり前のことでは？」と感じていた内容に
忘れていたり、気づいてなかったり、蔑ろにしていたりと
人間として「ごくごく自然なこと」が
いかに実行することが難しいかを感じさせてくれる
大変ありがたい作品と改めて感じました。

但し、例え話の内容や感性で訴えられている個所が、
日本人では理解しにくい部分があるように感じ
また、今日となっては、同様の内容をさらに発展させて
書かれている著作が存在していることもあり、
読み応えとして、少し物足りなさを感じたことも正直ありました。

とはいえ、デマルコ氏の著書は同業人であれば必読の書であることは
間違いなく、この作品からも、読み終えた時には何かしらのインパクトは
受けるであろうと思います。


(HJ/2007-02-11)

初版を読んでからずいぶん経った。うーむ、人間って変わらないものですね。
でも初版の時の感動はないけど、初版では理解できない別な側面が見えてきました。
（たぶん、私が変わったのだろうな）

一般にこの手の本は管理者が読むべきと思っている人がいるかもしれない。
でも下っ端の人や（初版当時の私がそうだった）、スタッフ部門の人こそ読むべきだ。
人が全力で働ける環境を作ることが、数値にこそ出ないものの、いかに大切か、
それを理解すべき。そうでないと、社内で真っ当な議論すらできない。

あと10年経ったら第３版を出して欲しい。
その時の私は...？ (osm10/2005-05-20)

人は単純な道具ではない。機械は燃料と時間があれば、作業量は増えるかもしれないが、人間はシリをたたくだけでは良い結果を出さない。機械にも優劣があって、高くてもいい機械を導入する価値を認めているのに、いい人に来てもらう努力を惜しんで失敗するプロジェクトがなくならない。いい人は平均的な人の２万倍の生産性があるらしい。ソフトウエア開発は、いいひとをあつめて、その人達のやる気をそがないように環境を整えることが管理者のつとめ。そのことを何度も認識させてくれる本。デマルコさんの経験則だから、間違いない。 (まちゃ/2002-03-04)

スラッグに引き続き読みました。人格を無視した昨今の管理方法の難点を指摘した好著といえます。ただし、組織は玉石混淆でありそこから選ばれるティームメンバーも玉石混淆です。怠け者や狡知者はどこにでも必ずいる者です。本書の内容は採用時の慎重選択（オーディション大賛成）だけでなく、採用後の自然淘汰（退職・補充）抜きには語れない面もあります。ティーム構成メンバーの質によって適宜当てはまるといったところではないでしょいか。
翻訳（直訳）に難点がありせっかくの好著が台無しになっています。日本語を練り直せば、もっとストレートに訴えるものがあると思われます。 (/)

証拠はないが声高に繰り返されているいかがわしい言葉の力、それに屈してあきらめてしまっている我々の意識を変えてくれる良書。
我々が日常、生産性を上げるためにはこうするしかない・こうすれば効率化し生産性があがるだろうと認識している大いなる勘違いを明らかにしてくれる。ソフトウエア業界に身を置くマネージャはもちろん、メンバーも読むべき啓蒙書である。 (/)