達人プログラマー 読書ノート 1/3¶
- 著者:
Andrew Hunt, David Thomas
- 訳者:
村上雅章
- 出版社:
株式会社ピアソン・エデュケーション
- 発行年:
2000 年
- ISBN:
978-4-89471-274-4
ローマ数字ページ¶
<本書は無理のないプログラム開発方法を教えてくれるものです> (p. vii)
<ラテン語の pragmaticus> (p. xi) 辞書を見たら確かにギリシア語由来で、英語でいうところの do の意だそうだ。
<コンピュータ科学の基本的原理を理解することによるバックグラウンドと、幅広い分野における現実的なプロジェクト経験が大事である> (p. xii)
<この願いの背景には、自分自身の潜在的な力を発揮できていないという不満があるのかもしれません> (p. xii)
<常に自分が何をやっているのかということを考え続ける必要があります> (p. xiii)
<もし今までに見たことがない用語に遭遇した場合、それを読み飛ばしてしまわないようにしてください> (p. xvi)
<質素な表紙> (p. xvii)
第 1 章 達人の哲学¶
達人が <常にその問題をより大きな背景の中で捉え> (p. 1) るのはなぜ？ どうして？
<通常の場合にはトレード・オフというものが存在するはず> (p. 1)
これは真理である気がする。
<ソフトウェアを腐らせる要素として（略）最も大事なものがプロジェクト活動における心理学、あるいは文化と呼ばれるものです> (p. 4)
有名な「割れ窓理論」を紹介。 <悪い設計、間違った意思決定、質の悪いコード> (p. 5) はまさに割れ窓だ。
石のスープのエピソードでは、<軍人達は食料をいっさい提供していない> (p. 7) ポイントを見逃してはならないだろう。
<別な見方をすれば穏やかで緩やかなペテンの話> (p. 8)
<水の入った鍋に蛙を入れて徐々に熱していった場合、蛙はゆっくりとした温度の上がり方に気づかず、調理されるまで鍋の中から飛び出してこない> (p. 9)
ゆっくりとした変化にはなかなか気付くものではない。常に注意せよ、か。
<今日の素敵なソフトウェアは、明日の完璧なソフトウェアよりも好まれる> (p. 11)
プログラミングと絵画はよく似ている点がある。作業の「やめ時」を見極めるのが難しい (p. 11)
<知識への投資は常に最高の利息がついてくる> (p. 12)
避雷針で有名なベンジャミン・フランクリンの言葉だそうな。
<あなたの知識と経験はあなたがプロとしての資産の中で最も大事なものです。しかし、そういった資産は残念なことに有効期限付きなのです> (p. 13)
これは技術者ならではの特性なのではないだろうか。
ポートフォリオという言葉がたとえで出てくる。単語の由来を調べると、ポートは carry の意で、フォリオは leaf の意。何かの明細のことをポートフォリオと呼ぶと見た。ただし、ここでは金融用語のそれと同様に「投資」の要素を含む。
<毎年少なくとも一つの言語を学習する> (p. 14)
<月に 1 冊読書をしましょう> (p. 14)
「最低」1 冊とは言っていないことに注意したほうがよさそうだ。
<Makefile とエディタしか知らないのであれば、IDE を使ってみましょう。逆も同じです> (p. 15)
そう言われると Makefile はもっと勉強しておきたい気がする。
<例えば、オブジェクト指向に慣れ親しむことで、単なる C のプログラムでもひと味違った記述が行えるようになる> (p. 15)
<狂信者に注意してください> (p. 16)
グルはエンターキーのすぐ近くにいる (p. 17)
<外に出て現在のプロジェクト以外や社外の人間と技術的な話をしましょう> (p. 18)
そりゃ無理だ。
<頭をよぎっていく内容> (p. 18)
<戦略を何種類か練っておく> (p. 19)
<迫力のあるドキュメント> (p. 21)
<e-mail による伝達> (p. 24) の囲み記事はとても面白い。ぜひ紙に印刷して貼っておきたい。
送信ボタンを押す前に再読する。
スペルチェックを行う。
単純なテキスト形式は全世界共通。
送信前に受信者のリストを確認。
e-mail は永遠である。
第 2 章 達人のアプローチ¶
この章には書名に恥じぬほどの実践的ヒントが充満している。同業者必読。
<知識は不変のものではありません> (p. 26)
<プログラマーは常にメンテナンス・モードなのです> (p. 26)
<DRY 原則は本書中のコーディングに関係のない部分でも何度も登場します。我々はこれが達人プログラマーの道具箱の中にある道具のうちで最も重要なものの一つであると考えています> (p. 27)
本の比較的早い段階で最重要であると言い切っている。
<簡単なフィルター・プログラムやコード・ジェネレータを記述すれば良いのです> (p. 28)
<ドキュメント自体から直接テストを行うプログラムを作成して、テストを自動化したのです> (p. 29)
C/C++ において <2 つのファイル間で、関数やクラスのヘッダー・コメントを二重化することに意味がないのは明白> (p. 29) である。ヘッダーファイルの方（だけ）に書いておくことを勧めている。
<こそこそ詮索して回る> (p. 33)
「直交性」という概念を説明する箇所。<2 つ以上のものごとで、片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶ> (p. 34)
線形代数風に言うと一次独立・一次従属ってところか。
<直交していないシステムは本質的に変更や制御が難しくなる> (p. 35)
<自己完結した比較的小さなコンポーネント> (p. 35)
<コードの二重化は構造的問題の兆候です> (p. 41)
<単体テスト用のビルド自体が、直交性に関する興味深いテストとなります> (p. 41)
各機能がどの程度局所化されているかを確認できる。
<DRY 原則ではシステム内の二重化を最小限に抑える事を目的としていましたが、直交性ではシステムのコンポーネント間の依存関係を最小限に抑えることを目的としています> (p. 42)
ここには特に太い線を引いておこう。
<ここでお勧めしている点 – 特に DRY 原則、結合度の最小化、（略）を貫き通すことによって、後戻りが許されない多くの重大な決定から解放されるのです> (p. 45)
下の方にはうまくやっていれば <途中で鞍替えできるだけの柔軟性があるはず> とも。
<どんなメカニズムを使用するにしても、可逆性を持たせるようにしてください。自動的に何かを追加するのであれば、同じように自動的に削除できるようにしておくのです > (p. 47)
これは意識していなかった。いいアドバイスを聞いた。
曳光弾のセクションは、妙にわかりにくい。曳光弾が何かの比喩だとはわかるが。
<曳光弾とプロトタイピングは違ったものなのです> (p. 51)
<曳光弾によるアプローチは、（略）アプリケーション全体がどのように連携するのかを知りたい場合です> (p. 52)
<ワークフローやアプリケーション・ロジックといった動的なもののプロトタイプには、ポストイット・ノートが重宝します> (p. 53)
アナログ文房具も活用するべし。
<プロトタイプは（略）極めて高水準の言語（プロジェクトで実際に使用するものよりも）を使用するべきでしょう> (p. 55)
<プロトタイプを正しく使用した場合、（略）莫大な時間、予算、苦痛、労力が節約できるのです> (p. 56)
ミニ言語と記法の話が出てくる。
<より形式的なシンタックスを用いることによって、より複雑な言語を実装する> (p. 59)
<BNF といった記法を使ってシンタックスを定義するのが秘訣です> (p. 59)
<いったんシンタックスを知ってしまえば簡単なミニ言語を作成するのはさほど難しい仕事ではないのです> (p. 60)
ミニ言語の例として次のようなものがある。
アプリケーション設定ファイルに見られるような <独自のコンフィギュレーション用言語> (p. 60)
Windows の rc ファイル（リソース定義ファイル）
作業時間の見積もり。これは経験が要る。
<海中に突っ込んだ車内にどれだけの空気が残っているかという質問では秒単位の答えに意味があるはずです> (p. 65)
<見積もりを行う場合は以下の単位を使うことをお勧めします> (p. 65)
「125 営業日」「25 週」「約 6 ヶ月」では精度の印象が異なる。
<同様の作業を行った人に聞く> (p. 66)
<机上モデルを構築する> (p. 66)
<クリチカル> (p. 67) という表記が昭和っぽくて好きだ。
第 3 章 基本的なツール¶
この章も実践的な内容でよい。
<手になじんでいく> (p. 71)
<最初は一般的に使用できる基本的な道具一式から始めてください> (p. 71)
<我々は IDE の制約を越えたところに到達しなければならない> (p. 72)
エディターは <何よりも大事なツール> (p. 72) である。
これが道具その 1 かな。
<知識を永続的に格納するためのフォーマットで最も適しているのがプレインテキストなのです> (p. 72)
<バイナリー形式には、データを解釈するためのコンテキストがデータ自身から切り離されてしまっている、という問題があります> (p. 73)
透明性、活用ができる、テストしやすい、の 3 点セット。
<未来でも、普遍的なテキスト・ファイルが使われているはずです> (p. 77)
<プログラマーにとって、作業台はコマンド・シェルに相当します> (p. 77)
これが道具その 2 かな。
<すべての作業を GUI で行うということは、お使いの環境が持っている能力すべてを使いこなしていないということになる> (p. 78)
<ツール単独での守備範囲はツールの実行目的に応じて制限されているのが普通> (p. 78)
ということは、ツールの目的が抽象的であるほど、守備範囲が広いのが普通と考えてよい？
<すでにコマンド・プロンプトに慣れ親しんでいるのであれば、このセクションは読み飛ばしていただいても構いません> (p. 78)
find, zip, tar の使いがちなサンプルが列挙されている。次のページにはパイプの威力を示すために、grep の処理結果を sed で加工して、さらにそれを sort で並び替える例が紹介されている。
テキストエディター論。
<ツールはあなたの手の延長である> (p. 82)
<理想を言えば、お使いのシェルとエディターで使用するキーバインディングを一致させておくべきです> (p. 82)
これ、あまり選択肢がない感じがする。Emacs 系か vi 系かのチョイスしかないような。
<まず選択するエディターが、あなたの使うすべてのプラットフォームで利用可能であることを確認してください> (p. 83)
これはテキストエディターを選ぶための、究極の条件である気がする。
テキストエディターが備えるべき機能を pp. 83-84 で列挙している。10 年前の本が謳うエディター要件は、今見ても古びていない。
ソースコードの編集に notepad.exe を使うのは、<シャベルの代用品として茶匙を使っているようなもの> (p. 84)
テキストエディターに関するアドバイスの類は、<満足度や習熟度が人それぞれで異なっているため、特に記述するのが難しいところです> (p. 85)
<あなたが勉強する新言語の一つにエディターが使っている言語を加えてください> (p. 86)
Xyzzy ユーザーならば Lisp ということかね。
次の道具はソースコード管理。
常にソースコード管理を使用するべし、とある。
<一週間で終わるプロジェクトを一人でやっていたとしてもです。それが「使い捨ての」プロトタイプであってもです。作業しているものがソースコードでなくてもです> (p. 88)
ビルドの自動化で手作業を排除し、それにより一貫性を保証する (p. 89)
なぜか急にデバッグの話になる。
COBOL の開発者に Dr. Grace Hopper 少将という人物がいるらしい。
<バグの修正を始めるに当たってまず最初にやるべきことは、そのバグを再現することです> (p. 93)
<バグが顔を出す環境を分離する> (p. 93)
わかった。デバッガーの話をしたかったんだ。
<トレース・メッセージの解析を自動的に行えるよう、メッセージは規則的で整合性のある形式にしておきましょう> (p. 95)
この章の残りは流しちゃっていいか。
テキスト操作言語を学ぶこと (p. 100) というアドバイスは的確。習得の有無で、残業時間のトータルや作業効率が全然違ってくるからな。
<書籍に引用するコードは重要なものであり、真っ先にテストするべきであると我々は考えています> (p. 101)
コード・ジェネレータのセクション。小さい本が一冊書けるテーマのようだ。
消極的なコード・ジェネレータ
成果物を作り出すために一度だけ実行するもの。
タイピング量を減らすもの。
パラメータ化されたテンプレートである。
完全に正しいコードを生成する必要はない。最後に手作業で結果を編集して OK という発想。
積極的なコード・ジェネレータ
こちらは何度も実行する。<必要に応じてコード・ジェネレータによって再生成する > (p. 105) コードを作成するためのもの。
<2 つの異なった環境をまとめたい場合には、常に積極的なコード・ジェネレータの使用を考えるべきでしょう> (p. 105)
<通常の場合、もっとも複雑な部分は入力ファイルを分析する解析処理> (p. 106)
