すごく面白い、ためになる本だから、基本的に読まなくていい、忘れてもいいことはないんだけど、読みながら付箋紙を貼っていっていたところをメモ。
6 伝達しよう
What 聞き手に何を知って欲しいのか Interest 言いたいことの中にある彼らの興味とは何か Sophiscate それらはどれくらい洗練されているか Detail 彼らはどの程度詳細を知りたがっているか Own 誰にその情報を知ってもらいたいのか Motivate 話を聴いてもらえるには、どうするのか
伝えるときに心得ておくべきこと。この項はとても重要。とても大切なことがたくさん書いてある。
ヒント 10: 伝える事柄と、伝える方法は車の両輪だと考えること
伝えようとする行為は、ひとに伝えられなければ意味はない。
人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3)) ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵 ソフトウェア開発のダイナミズム (MicrosoftPRESS) を向こう18ヶ月で読む計画を建てること。
10 曳光弾
曳光弾とプロトタイピング。プロトタイピングは使い捨て、曳光弾はシステム最終形の骨格をなすもの。
ヒント 16: プロトタイプの真の目的は学びにある
とても大切な違いだそうで。
26 契約による設計
- 事前条件
- 事後条件
- クラス不変表明
オブジェクト指向入門 (ASCII SOFTWARE SCIENCE Programming Paradigm)、ひとに貸したままだ。読まなきゃ。
26 結合度の細小化とデメテルの法則
機能に対するデメテルの法則は、オブジェクト中のすべてのメソッドは以下のカテゴリーに属しているメソッドのみを呼び出すべきである。 自分自身 メソドに引き渡されたデータ 自身が生成したオブジェクト 直接保持しているコンポーネント・オブジェクト
これ以外だとグローバルなオブジェクトくらいしか思いつかないから、それはやめとけってことかな。まあ、そういうのは褒められはしないだろう。
28 時間的な結合
同期とか意味ではなく、フローの直列性に依存するような設計をすべきではない。並列性を意識した設計をすべき、ということ自体にも納得できるけど、それにあわせて、このセクションの最後にあった、
（並列性の設計を先送りするのではなく、）今がその時でしょう？
というのが特にジンときた。無駄な仕事をする必要もないし、タスクにはプライオリティをつけるべきなのは当然だけど、ただ、怠惰な故の汚い設計を認めるべきではない。やるべきことはやること。
37 不可能なパズルを解く
ヒント 55: 枠にとらわれずに考えるのではなく、枠を見つけだすこと
現実世界では枠を見つけだすこと、問題発見することこそが難しい。
43 容赦ないテスト
ヒント 62: 早目にテスト、何度もテスト、自動でテスト
46 誇りと愛着
ヒント 70: あなたの作品に署名すること
我々は所有することによって誇りを持つべきなのです。「私はこれを記述した、そしてこの仕事の後ろには私が付いている」と。品質の証明として、あなたの署名が入っているべきなのです。あなたの名前をコード中に見い出すことによって、みんな、それがきっちりと記述、テスト、ドキュメント化されたものであることを確認できるのです。それが本当のプロの仕事です。それが本当のプロによって記述されたものなのです。
達人プログラマー
うう、署名できると言えるようなコードなんて数えるほどしか書けていない。でも、すべてのコードに署名しないといけないんだろうな。署名をしなければならないと思うからこそ、本気でコードについて考えることができるのだろう。
