- Amazon.co.jp ・本 (326ページ)
- / ISBN・EAN: 9784894712744
感想・レビュー・書評
-
この本が10年以上前に出ていることは脅威に値すると思う。その反面、劣化コピーならぬ、強化されたコピーが10年かけて沢山出回ったようにも思えるので、「必読」とまではいかないな。でもいい本でした。
詳細をみるコメント0件をすべて表示 -
プログラマとして押さえておくべき心構え、姿勢、哲学を紹介した古典ともいえる本。
同様の書籍「CODE COMPLETE」と比べると、「CODE COMPLETE」が後発な分、紹介しているコードが新しく、プラクティスがより具体的である。それでも、プロのプログラマとしての姿勢を学ぶことができる名著。 -
座右の書になりそう。
-
プログラマーとしての心構えから、設計手法やプロジェクト管理まで幅広く書かれている。
ざっと読んだ感じ、信用してよさそうな文章で幅広く書かれていて好印象。新装版が出てるみたいなので、そっちを真面目に読んでみようと思う。
以下、心動かされたところ。
# 達人プログラマーになるためには?
- 新しい物好き
- 研究好き
- 批判的
- 現実的
- なんでも屋
# ゴール
- 毎年少なくともの一つの言語を学習する
- 毎四半期ごとに技術書籍を読む
- 技術書籍以外の書籍を読む
- 講習を受講する
- ローカル・ユーザー・グループに参加する
- 異なった環境に慣れ親しんで見る
- 最先端にとどまり続ける
- インターネットを使う
# Cockburnのユースケース・テンプレート
## 特性情報
- 概要
- スコープ
- レベル
- 事前条件
- 正常終了時の条件
- 異常終了時の条件
- 一時アクター
- トリガー
## 主要な正常時のシナリオ
## 補足
## バリエーション
## 関連情報
- 優先順位
- パフォーマンス目標
- 頻度
- 上位ユースケース
- 下位ユースケース
- 一次アクターへの伝達経路
- 二次アクター
- 二次アクターへの伝達経路
## スケジュール
## 未解決の問題
# ヒント
- あなたの仕事について考えること!
- 割れた窓を放置しておかないこと
- 変化の触媒たれ
- 常にあなたの知識ポートフォリオに投資すること
- 最終決定などというものは存在しない
- プロトタイプの真の目的は学びにある
- 一つのエディターを熟知すること
- コードを生成するコードを作成すること
- 早めにクラッシュさせること
- 始めたことは終わらせること
- サービスを使って設計を行うこと
- 常に並列性を意識した設計を行うこと
- 理解できないウィザードのコードを使わないこと
- 要求は拾いあつめるものではなく、掘り起こすものである
- テストが終わるまでコーディングは終わらない
# 気になったことば
- IBMにあったおなじみの企業モットーTHINK! -
@torazuka さん、 @kompiro さんと MorningBee 全5回で読んだ。
読書会的なものに向いていると思う。
新人さんに送ったのはちょっと早かったかも、、、という気もしたりしなかったり。 -
意外に抽象的な内容だった。もっと具体的事例に沿ったものだと思っていた。
だが、本文中でも触れられているように、抽象は具象よりも寿命が長く、具象方法論は、その本来の目的という重要な要素が抜け落ちる危険性がある。
そういう意味では、良いバランスだと思う。
要求を契約としてコード定義し、実装を保証する、というのは、興味深かった。
だが、一読した限りでは、内容はコメントレベルと大差ないように思えた。
(コードと結びついていない?)
契約定義言語を調べて、具体的な内容を調べてみる。 -
この本一読せずしてプログラマーと名乗る無かれという感じの本。CODE COMPLETEもそうだが、こうした本質を踏まえずにプログラムしているということは恐ろしいことと感じなければならないだろう。
[private]・知識ポートフォリオに定期的に投資する。
・DRY原則
・直行性を確保する。
・曳光弾アプローチ
・仮定をドキュメント化する。
・ソフトウェアは建築というよりガーデニング
・プロジェクトの用語集を作る
・自分が作成しているソフトウェアを使うことができますか?
・ドキュメントをコードと同等に扱う。
[/private] -
アンドリューハントさんへ、この本書いてくれて、ありがとうございました。といいたくなるぐらいすばらしい本。この本は、私をソフトウエア開発のプロに導いてくれた。 DRY(Do not repeat yourself)プラクティスは特に参考になる。ソフト開発者必読の書といえる。
-
全部で70個の原則を説明。以下、響いたもの。
・DRY Don't Repeat Yourself 繰り返しを避けること。
・曳光弾えいこうだん 早い内にでも出来るものを作っておく。
・バグの原因が誰のミスかは関係ない。非難では無く問題を修復せよ。
・デメテルの法則=モジュール間の結合度を最小化。
オブジェクト中の全てのメソッドは以下のカテゴリのメソッドのみ呼び出すべき。
ー自分自身
ーメソッドに渡されたパラメータ
ー自身が生成したオブジェクト
ー直接保持しているコンポーネントオブジェクト
・偶発的なプログラミングを行わないこと。行き当たりばったりを止める。
前提はドキュメント化すること。つまりコメントで表明すること。
・立ち上げ恐怖症候群を克服するにはプロトタイプを開始するほうが良い。
・回帰テスト=事前に作成した出力値と今回の出力値を比較するテスト。
・カバレッジ100%を目的にしない。状態をカバーしないといけない。
・我々には自動化されたテストで見つけられるようなバグを追いかける暇はない。
・コメントには「なぜ」行うかという目的やゴールを記述すべき。
「どのように」はコードに書いてあるからDRY原則よりいらない。
・ユーザーが期待していたものより少し仕上げを上回らせる。
ユーザー指向の機能を追加する。ショートカットキーやヘルプ機能、カスタマイズなど -
プログラミングで仕事をしていく人が読むべき本。 大学院とかで扱ってもいいんじゃないかと思う。 ただ、研究室や社会で揉まれていることが前提になります。 ある程度実務経験がないとピンとこないと思う。 基本的に性悪説で話が進みますが、計算機は命令した通りにしか動かなくて、バグを混入させるのは人間なので、間違ってはいません。(2:6:2の法則や働き蟻の法則も交えて欲しかった) キーは、自動化プロセスを作り、成熟させていくこと。 人の手は極力排除しないとだめです。 3章を読んでから、すぐにwindowsを捨てて数年ぶりにscreen+emacsに戻りますた。