スティーブ・マコネルのレビュー一覧

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

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

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

ソフトウェア開発に携わる人の必読書でしょう。プロジェクトマネジメントに関する簡単な本を読んでからがいい。

勉強会はまだ続きますが、ひとまず、一通り目を通しました。

これは、ソフトウェアエンジニアとそのマネージメントをする人みんなに読んで欲しいですね。

繰り返し読み返すことになりそうな、そんな本です。

私は、マコネルをまったく信用していませんでしたが、この本で私の認識が間違っていたことが分かりました。上流設計から、コーディング、マネジメントまで、ソフトウエア開発について、ここまで網羅した本は他にないでしょう。ほとんどの指摘は的を得ており、私は、９０％以上の彼の主張に賛成します。また、ほとんどのソフ...続きを読むトウエアプロジェクトでは、ソースコードが唯一のドキュメントであるという言い切り方は、この人が現場での経験を充分積んだプロのプログラマーであることを証明しています。エンジニアは、先人の知恵に学ぶべきであり、この人は、学ぶに値する本当のプロです。ぜひ、この本（上下巻とも）を読むべきです。

「９０％と確かとは、何％確かなのか？」この質問に答えられないソフトウエア開発者は火急速やかにこの本を読むべし。ソフトのスケジュールに対する知見をここまで掘り下げた非学術的本は、他に類を見ない。この分野のバイブルとすべき書である。

プログラミングでの命名規則を徹底検討

よりよいプログラミングを目指して書かれた書籍。分厚い。大量の文献が引用されており，読み応えが十分。
上下巻に分かれており，この上巻では主にプログラミングでの名前について解説されているのが印象的だった。

関数（ルーチン）の名前はどうすればいいか？変数名はどう書...続きを読むけばいいか？データ型やステートメントはどう使い分けるのがいいかなど，実際のプログラミングで誰しも一度は悩むような項目を扱っている。
たとえば，TotalDataとするか，DataTotalとしたほうがいいのか。

クリーンコードやリーダブルコードなど他のコーディングに関する本でもこうした項目に言及しているが，この本ほど網羅的で徹底的に議論されてはいない。おそらく，この本以上にコーディングについて徹底的に考察された本はないのではないかと思える内容だった。

p. 317の「11章 変数名の力」の冒頭の以下の言葉がこの本の本気度を伺わさせる。
「効果的なプログラミングにとって、よい名前というテーマは重要であるにもかかわらず、よい名前の作り方を10項目以上にわたって取り上げた本を読んだことはない。プログラミングに関する文献の多くは、省略形の選択に段落をいくつか割き、決まり文句でお茶を濁し、読者が自力で何とかやっていくことを期待する。本書はこれに真っ向から対抗し、良い名前に関する情報を使い切れないほど提供しようと考えている。」

値段は少々高いが，大量の文献，考察が書かれており，2005年出版とやや古いが，今でも通用するかなり有益な本だった。是非手元においておきたいと思える本だった。プログラミングするなら読んで損はしないと思う。

読み応えのある本。

自分はこれでオブジェクトとは何か。
オブジェクトにおける振る舞いとは何か。
主にプログラミングインターフェースに関して、多くのことが学べたので非常に良かった。

現場で生きるプログラマーの「教科書」。
学校で授業で習ってある程度プログラムを書いた後、あるいはプログラムを仕事である程度書いた後で読むのをお勧めする。
自分の今までの経験からも「あぁこれ書いた事あるわ」とか「これ見たことあるわ」というコードや問題が大量に出て来て苦笑するしかない。
今でも現場で記載...続きを読むされている問題は起き続けている。
現時点では多少異なる点はあるし、読むのにとても時間がかかる。
しかし是非とも現場で働く前に読んでおいていただきたい。

全てのプログラマにとって有益な本と思います。この本に記された具体的なアドバイスに従うことこそ、高品質ソフトウェアへの一歩になるに違いありません。
なお、テストエンジニアは「第20章　ソフトウェアの品質」、「第22章　デベロッパーテスト」、「第23章　デバッグ」、「第27章　プログラムサイズが及ぼす影...続きを読む響」、「第30章　プログラミングツール」、「第34章　ソフトウェア職人気質とは」等々がある下巻の方が興味深く読み進めることができるかもしれません。

全てのプログラマにとって有益な本と思います。この本に記された具体的なアドバイスに従うことこそ、高品質ソフトウェアへの一歩になるに違いありません。
なお、テストエンジニアは「第20章　ソフトウェアの品質」、「第22章　デベロッパーテスト」、「第23章　デバッグ」、「第27章　プログラムサイズが及ぼす影...続きを読む響」、「第30章　プログラミングツール」、「第34章　ソフトウェア職人気質とは」等々がある下巻の方が興味深く読み進めることができるかもしれません。

本書は全てのプログラマーに捧げる、最高クラスの名著である。
ひとことで言うと、「コードスタイルとはどうあるべきか」を示した本である。ページは相当数あり、読み抜くだけでも相応の努力が必要だが、上下巻を読みきった頃にはソースコードに対する意識が変わっていることだろう。そしてきっとこう思うはずだ。「俺のコ...続きを読むードは腐ってる」と。

開発者必読の一冊。開発歴10年近いけど、それまでに培った以上のノウハウが詰まっていた。
技術の移り変わりは早いけど、あと10年は役立つ内容かと。

読んでもいまいちピンとこないものだが、実践してみればこれはすごい。マッコネルさんが色んな本の知見を、バキッと説明してくれるので、これを読んで実践すれば、技術者の見積もりはばっちりである。
営業見積もりと経営判断は別だよ。

ソフトウェア開発におけるベストプラクティスを網羅的に解説したプログラマにとってのバイブル的書籍である。
著者はソフトウェア工学の第一人者であるスティーブ・マコネルで、
私の会社の机にも置いてある「SWEBOK」の構築を主導している人物でもある。

この書籍が解説している範囲的は主に詳細設計?テストで...続きを読む、
上巻では詳細設計?プログラミングの部分を解説している。
この書籍の良いところは、かなり具体的に例を示している点で、
例えば、コーディングの際の擬似コード(PPP)のススメや、
変数の宣言、定義等のベストプラクティスなど、
実際の実務に直ぐにでも生かせるようなテクニックを惜しげもなく教えてくれる。
これは恐らく先人たちが何十年もかけて得た知識や経験を、
この本に凝縮して詰め込んでくれたのであろう。
そんな素晴らしい知識をたかだか数千円の投資で得ることが出来るというのは、
この著者に十分感謝しなければならないと思う。

以下、上巻を読んで大事だなと思った項目を一部抜粋します。
・プロトタイプを作成するときはクラス名やパッケージ名にprototypeというプレフィックスを付けるといった標準を設けるといい。
・設計書の文書化(CRCカード、UML、デジカメ、JavaDocの使用)。
・擬似コード (PPP)の活用。
・変数は宣言時に初期化する(C++など)。
・変数は最初に使用する場所の近くで初期化する。(VBなど)。
・変数の宣言と定義は、最初に使用する場所の近くで行うのが理想的である。
・できるだけfinalまたはconstを使用する。
・クラスのメンバデータはコンストラクタで初期化する。
・すべての変数を自動的に初期化するようにコンパイラを設定する。
・変数の参照はまとめて。
・トランプデータの削除。
・グローバル変数が必要なすべてのコードでアクセスルーチンを使用する。
・ロックを使ってグローバル変数へのアクセスを制御する。
・ループは一度に確認できる程度に短くする。
・ネストは3段階までに制限する。
・ブール値とtrue、falseは暗黙に照合する。
・ド・モルガンの定理を適用して、否定語のある論理評価を単純化。
・数値を含んでいる式は数直線の順番に並べる。
・Cでは、文字を終端のnull('\0')と明示的に比較する。
・Cから派生した言語では、定数を比較の左側に置く。(但し、数直線との関係が矛盾している)。
・null文の代わりにDoNothingプリプロセッサマクロやインライン関数を作成する。

どの言語を使用していても役に立つ。これ一冊で得られるものは非常に多い。
プログラマがこれを読まない理由が思い当たらない。

■概要
コードは書く事に費やす時間より
読むことに費やす時間のほうが長い

読みやすいコード（＝変更するときに間違えにくいコード）
を書くための色々なテクニックが紹介されている

割と基本的な事からしっかり書かれている

■感想

こんないい本を今まで読んでなかったなんて・・・と，衝撃を受けた
後１...続きを読む～２年早く読んでいれば卒業研究のプログラムなどがもっと効率よく書けたのに．

量は多いけど，栄養たっぷりで美味しいので
もりもり食べれた（本を食べ物に例えたメタファー）

ただ，全部消化しきったわけではないので
もっと経験を積んだ後に，また読み返したい1冊

我流でプログラムを勉強したが
読みやすいコードの書き方がいまいちわからない人や
これから，プログラムをもりもり書く人や
これから，チームでプログラムを書く人等に
おすすめの1冊

見積もりする際には参照したいです。
今後見積もる場合は、最良ケース、最有力ケース、最悪ケースの 3ケースを提示するようにしたいですね。

なんか最近 McConnell の本ばっかり読んでるような気もするけど、彼の最新作。見積りというものの位置付けやその考え方が非常に明確に整理されていて、プロジェクト・マネージャ必読と言える。

見積りを「プロジェクト・マネージャがプロジェクトの "ターゲット" を達成するための "コントロール" を...続きを読む行う上で、適性な意志決定ができる明確な視点を提供する」ものと位置付け、規模の見積り、工数の見積り、スケジュールの見積りのそれぞれについて解説する。大切なのは、ターゲット(一点の目標)と見積り(幅と確度を持つ)は異なるということ。

メインは規模の見積り。その後の工数とスケジュールの見積りは、彼が言うところの「サイエンス」に負うところが大きく、技法の紹介に留まっている。

手続き型言語を扱う全てのプログラマに無条件でオススメできる本。ある程度プログラムの経験を積んでくると、きれいなソースや効率化、再利用性といった物を求めると思いますが、その様な中級プログラマとして必須な考え方がぎっしりと詰まっています。デザパタ的なものではなく、モジュール強度や結合度的な考え方、変数や...続きを読むステートメントといったより細かい単位での考え方が詳しく載っているので、それらを人から習う機会が無かった人等には特にオススメです。
ただ設計の部分に関してだけは自分の肌には合いませんでしたが…。特にPPPの部分！いやそれはお前が分かってないだけだとか言われそうですけど（笑）
これを読むときっと「人に優しいプログラミング」ができるようになります。