達人プログラマーのメモ

最初に

私が今読んでいる達人プログラマーのメモです．
あとで見返せるものが欲しかったのでノート感覚でQiitaにあげてみました(問題あったら非公開にします)．
自分用のメモなので他者から見たらよくわからない場合が多々あると思います．
もし見てくれて気になったりしたら，是非買ってみて下さい．

まだ読んでいる途中なので随時更新していく予定です．
読了しました

目次

1章 達人の哲学
2章 達人のアプローチ
3章 基本的なツール
4章 妄想な達人
5章 柳に雪折れ無し
7章 プロジェクトを始める前に
8章 達人のプロジェクト

達人プログラマーが持っている性格

Tip 1. 自らの技術に関心を持つこと
Tip 2. 常にあなたの仕事について考える(評価する)
リアルタイムに自らの作業を批判的に見る

単に石を切り出す場合でも、常に心に聖堂を思い描かねばならない。

#1章 達人の哲学

すべての弱点でもっとも重要なものは弱みを見せることに対する恐れである
無知は誤りと同じである、自らの欠点に対して正直に
責任を「負う」場合、過ちやミスを認め取りうる選択肢の提案を試みる ※他人や他の何かのせい(非難、言い訳)にしてはいけない

Tip 3. いい加減な言い訳よりも対策を用意する
問題を収集するために何ができるのかを説明する

Tip 4. 割れた窓を放置しておかない
割れた窓=悪い設計, 間違った意思決定, 質の悪いコード
修正できない場合でも、その旨をわかり易い場所に明示
綺麗に保たれていることで最初の汚す人になりたくないという抑止にもなる

・チャレンジ

数枚の割れ窓を探して，それを修復するために何ができるか話し合う
なぜ，どうやって割られたのかを思い出し，どういう対処ができるか

Tip 5. 変化の触媒たれ
うまくいっていることには簡単に参加できる

Tip 6. 大きな構想を忘れないように
個人がおこなっていることだけでなく、常に周囲で何が起こっているのか注意する

金融ポートフォリオにみる自身の知識ポートフォリオ

• 習慣的に定期的な投資をおこなう

継続した投資

• 多角化

まず自分が作業している技術のすべての詳細を知り
新しいものより多くの技術に親しむ

• リスク管理
• 技術のリスク管理
• 安く買い， 高く売る
• 見直しと再配分

Tip 8. あなたの知識ポートフォリオに対して定期的な投資をおこなうこと

ポートフォリオの作成に対しての提案

• 毎年少なくとも１つの言語を学習する

• 四半期ごとに技術書を読む

• 技術書以外の書籍を読む

  人間によってコンピュータはつかわれるので人間のニーズに対する意識を忘れてはいけない

• 講演を受講する

• ローカルユーザーグループに参加する

• 異なった環境に慣れ親しんでみおる

windowsならunix，エディタとIDEと言った感じ

学習の機会

ある程度技術に習熟すると質問されるようになる
質問がわからない場合はチャレンジと考える
分かる人をさがす←これもポートフォリをを広げること

Tip 9. 見聞きしたものごとについて批判的な目で分析する
一旦否定的な目でみてみる

グル(分かる人)に対する礼儀

・何が聞きたいかを明確にし，できるだけ内容を具体的に
・質問を注意深く丁寧に組み立てる．お願いしていることを忘れず，答えを強要するような書き方はしない
・質問ができたら一旦立ち止まり，もう一度答えを考える(webでキーワードで検索するなど)
・公共の場で聞くのか個人的に聞くのかを決定する
・質問を終えたら，気を楽にして辛抱強く待つ
・質問に答えてくれたすべての人々に感謝の意を表す
そしてあなたがこたえることができる質問を見かけたら，その人に手を差し伸べてあげて下さい

チャレンジ
・今週から新しい言語を始めよう
・新しい書籍を読む， 設計しているならコードや実装の本を， 実装しているなら設計などの抽象度の高い本を読んでみる
・外に出て技術的な話をしよう

コミュニケーション

聞き手を理解するための合言葉WISDOM
W what 聞き手に何を知って欲しいか
I interest 言いたいことの中にある彼らの興味とはなにか
S sophisticate それはどれ位洗練されているか
D detail どの程度詳細をしりたがっているか
O own 誰にその情報を知ってもらいたいか
M motivate 話を聞いてもらえるには，どうするのか

Tip 10. 伝える事柄と、伝える方法は車の両輪だと考えること
相手に必ず返信し聞き手に状況を知らせておく

サマリー

・あなたの言いたいことを知る
・あなたの聞き手を知りましょう
・タイミングを選びましょう
・見栄えを良くしましょう
・聞き手を巻き込みましょう
・良い聞き手になりましょう
・聞き手の立場に成りましょう

#2章 達人のアプローチ
Tip　11.　DRY
Tip　12.　再利用しやすいように
簡単に見つけ出して再利用できる形を整えておく
そうしないと，他の人達は見つけ出す努力をしない

Tip　13.　関係ないもの同士の影響を排除する
独立性を保つべきという話を直交性というキーワードを交えつつ説明

ある機能に対する要求を変更したら，どれだけのモジュールに影響を及ぼすか
→ 直交性の高いものは1

ツールキットやライブラリを導入する場合は直交性を維持できるかという観点を忘れないように

singletonパターンをグローバル変数の用に使わない

見積もり

Tip　19.　規律に従いスケジュールを繰り返し,精度を向上する
見積もりを要求されたとき→後ほどお持ちします
じっくりと見積もりを行い,より正確な見積もりを出す
最初に出した見積もりは相手の脳裏からなかなか消えない

#3章 基本的なツール

デバッグ

Tip　24.　非難するのではなく問題を修復する

誰かに問題を説明する
説明する過程で明確化されることもある

Tip　25.　仮定するのではなく証明する
正しく動いてると盲目的に信じない

コードジェネレーター

• 消極的なコードジェネレーター
  一度だけ使うもので利便性を追求したもの
  ex) 新規のソースファイルの生成,プログラミング言語の一括変換など

• 積極的なコードジェネレーター
  DRY原則を実践する際に必要となるもの
  ex) 元となるものを様々な形式に変化する, 2つ以上の環境をまとめたい,DBのアプリ側orDB側のスキーマなど

#4章 妄想な達人
Tip 30. あなたは完璧なソフトウェアを作ることができない
格言

契約による設計

ソフトウェアモジュールの権利と責任を文書化しプログラムの正しさを保証する簡潔かつパワフルな手法
ここでいう正しさとは要求された以上でも以下でもないということ

何を保証するか，何を保証しないかを契約しておく

プリプロセッサ

既存のプログラミング言語がもつ機能を拡張するために用いられるプログラムの1つ
拡張部分をコンパイラが処理できる形態に置き換える役割を持つ

事前条件を決めたメソッドには不正値が入らないように，呼び出し側で対応する必要がある

#5章 柳に雪折れ無し

Tip　38.　抽象概念はコード上に詳細はメタデータに
柔軟性を持たせるためにコードは抽象的にし、設定などはメタデータに持たせるべき

Tip　39. 並列性の改善にはワークフローを使う
UMLのアクティビティ図など

理由のわからないのに動いてるように見えるものは、単なる偶然なのか確認する

Tip　45.　アルゴリズムのオーダーを見積もる
普段のプログラムのループなどでも意識しておく

Tip　46.　見積もりの検証を行う

ソフトウェアは建築よりガーデニングの方が近い

#7章 プロジェクトを始める前に
Tip　51.　要求とは拾い集めるものではなく掘り起こすものである

Tip　52.　ユーザーの視点に立つにはユーザーと働くこと
使う人の手に馴染むツールが正しいツール

Tip　53.　抽象は詳細よりも息がながいものである

Tip　54.　プロジェクトの用語集を作ること

問題が難解である場合、以下を考える．
・もっと簡単な手段は存在するのか？
・本当の問題を解決しようとしているのか、末端的な問題にとらわれているのか？
・なぜそれが問題なのか
・解決を難しくしている心の原因はなんなのか？
・そもそも解決しなければならない問題なのか？
必要なものは、実際の制約、誤解を招く恐れのある制約、そしてその違いを知る知恵

1. 仕様書がシステムの要求に関するすべての詳細やニュアンスを含んでいると仮定している
2. 言語自体の表現能力に問題(限界)がある
   Tip　57.　解説しないほうがよい場合もある
   仕様書の記述をこれ以上詳細にしても、メリットが生まれないor失われるという限界点を常に意識する
   仕様書だらけになっているならプロトタイピングや曳光弾による開発の検討を

Tip　58.　形式的方法論の奴隷になってはいけない
設計者による翻訳が必要でシステムを実際に使用するユーザーによる本当の意味での要求の検討が行えない
可能であればプロトタイプをユーザに見せ，それをたたき台にしたほうが好ましい

#8章 達人のプロジェクト
達人の技法が集団としてのチームにどのように適用できるのか

割れた窓をなくす

集団としてのチームは誰も修正しない小さな欠陥を大目に見てはいけない
品質とはチームメンバー全員が個々に貢献することによってのみ達成できる

蛙の煮物

誰かが問題を対処してくれている、チームリーダーが承認済みだろうといった仮定してしまう
全員が環境の変化を積極的に監視しているかどうかを確認する
そのためのチーフを任命し，短い時間尺度でもともとの合議事項になかったものをチェックし，新たな要求として管理する

伝達しよう

内部では活発な議論をしているが，外への意見は1つにまとまっている

DRYの原則

プロジェクトライブラリアンを決め，二重化が発生する可能性を指摘する

直交性

Tip　60.　職務権限ではなく，機能によってチームを編成すること
2つのサブチームが同じプログラムモジュールや同じクラスの作業をおこなっている場合，チーム編成が誤っている
機能による編成は，受ける影響を減らすことができる
また，特定の機能に関して責任を負っているのが自分たちだけであることを知っているため，自分たちの成果物に対してもよりしっかりした所有意識をもつようになる
※これは信頼のおける開発者と強いプロジェクト管理者がいる場合のみ，うまくいくアプローチ
プロジェクトには，技術上と管理上の，最低2つの「チーフが必要」

自動化

Tip　61.　手作業は危険である

###　容赦のないテスト
Tip　62.　早めにテスト，何度もテスト，自動でテスト
Tip　63.　テストがすべて終わるまでコーディングは終わらない

何をテストするか

Tip　65.　コードのカバレージではなく，　状態のカバレージをテストすること

すべてはドキュメント

Tip　68.　ドキュメントは付け足すものではなく，組み込むものである
内部ドキュメントと外部ドキュメントがある
すべてのドキュメントはコードを反映したものになっているはずなので，矛盾があったとしたらどんな場合であれコードの問題へとつながっていく

####　コード中のコメント
ソースコード中のコメントは技術上のトレードオフ，意思決定の理由，却下された代替案といったプロジェクト資料のどこにも記述されない難解なポイントを記述するためのもの
明快でないものすべてをコメントとして提供するべき

###　大きな期待

追加のマイル

ユーザーと期待を共有し，ユーザーに近いところで作業を行い，やっていることをうまくユーザーに伝達できれば納品時にあっと驚くような自体はほとんど無くなる
しかしこれは悪いこと、彼らの期待よりも少しだけ仕上げを上回らせる
「少し」＝「何らかのユーザー指向の機能をシステムに追加する」
ユーザーに対して良い印象を与える機能例の紹介

誇りと愛着

Tip　70.　あなたの作品に署名すること