プログラマーとしての心構えから、設計手法やプロジェクト管理まで幅広く書かれている。 ざっと読んだ感じ、信用してよさそうな文章で幅広く書かれていて好印象。新装版が出てるみたいなので、そっちを真面目に読んでみようと思う。 以下、心動かされたところ。 # 達人プログラマーになるためには？ - 新しい物好き - 研究好き - 批判的 - 現実的 - なんでも屋 # ゴール - 毎年少なくともの一つの言語を学習する - 毎四半期ごとに技術書籍を読む - 技術書籍以外の書籍を読む - 講習を受講する - ローカル・ユーザー・グループに参加する - 異なった環境に慣れ親しんで見る - 最先端にとどまり続ける - インターネットを使う # Cockburnのユースケース・テンプレート ## 特性情報 - 概要 - スコープ - レベル - 事前条件 - 正常終了時の条件 - 異常終了時の条件 - 一時アクター - トリガー ## 主要な正常時のシナリオ ## 補足 ## バリエーション ## 関連情報 - 優先順位 - パフォーマンス目標 - 頻度 - 上位ユースケース - 下位ユースケース - 一次アクターへの伝達経路 - 二次アクター - 二次アクターへの伝達経路 ## スケジュール ## 未解決の問題 # ヒント - あなたの仕事について考えること！ - 割れた窓を放置しておかないこと - 変化の触媒たれ - 常にあなたの知識ポートフォリオに投資すること - 最終決定などというものは存在しない - プロトタイプの真の目的は学びにある - 一つのエディターを熟知すること - コードを生成するコードを作成すること - 早めにクラッシュさせること - 始めたことは終わらせること - サービスを使って設計を行うこと - 常に並列性を意識した設計を行うこと - 理解できないウィザードのコードを使わないこと - 要求は拾いあつめるものではなく、掘り起こすものである - テストが終わるまでコーディングは終わらない # 気になったことば - IBMにあったおなじみの企業モットーTHINK!

意外に抽象的な内容だった。もっと具体的事例に沿ったものだと思っていた。 だが、本文中でも触れられているように、抽象は具象よりも寿命が長く、具象方法論は、その本来の目的という重要な要素が抜け落ちる危険性がある。 そういう意味では、良いバランスだと思う。 要求を契約としてコード定義し、実装を保証する、というのは、興味深かった。 だが、一読した限りでは、内容はコメントレベルと大差ないように思えた。 （コードと結びついていない？） 契約定義言語を調べて、具体的な内容を調べてみる。