# 『達人プログラマー（第2版）熟達に向けたあなたの旅』ダイジェスト読書会

## グランドルール
こちらは、[ドメイン駆動設計の読書会](https://ddd-community-jp.connpass.com/event/198329/)のグランドルールを拝借しました。MECEで素敵だったので・・

- フィードバックを恐れずに発言しましょう
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

## 感想や意見、疑問点、取り上げて欲しい部分を挙げて下さい
- (Format)ページ識別情報(Page/章名など)|意見や感想など。階層化して書いてもOK
- P.21 妄想の達人-契約による設計(DbC)｜interfaceともまた違う？例として出されているClojureが日本では一般的では無いと思ったのでより身近な開発環境で話を聞いてみたいです。
- No.9 DRY- Don’t Repeat Yourself（繰り返しを避けること）では第2版から知識にフォーカスしていますが、そうすると「DRY原則に反しているのでは？」という例を聞いてみたいです。例えばDB設計書など、設計書類は該当してしまいそうです。
- P.186 変換のプログラミング|shellは強力なプログラムだと思っているのですが、その理由の一つがパイプだと思います。何で一般的な言語でパイプ的なものが無いんだろうと思っていたのでJS辺りで機能追加が検討されているのは興味があります。
- P.213 「サービスとしての設定」ここでは大域変数（設定）をAPI経由で参照できるようにすべきとあります。個人的には「うーん」という感じなのですが、これは実際今後のトレンドになりうると思いますか？
- Tips58/P.231 無秩序なエラーはしばしば並行処理によって引き起こされる。|その通りだと思うけど、だからこそエラーを敬遠するため線形の設計をしがち。そんな意味ではある程度の設計レベルが必要だと思うが、エンジニアはどのタイミングで並行処理を学ぶべきなんですかね？
- P.272 リファクタリングの手順として、最初に「テストが用意されていること」の確認をしています。また、P270-274ではテストについて多く触れられていますが、はやりテストはリファクタリングにおいて必須と考えて良いのでしょうか？
- P.232 アクターとプロセス|この部分、２版で追加されている部分だと思いますが、業務レベルで考えるとマイクロサービスの考えとかがこれにあたるのかな
- この本は個人的にかなり「教え」として役に立つとは思いますが、これを変化の触媒のように広めるにはどうすればいいのでしょうね？

## その他読書会についての要望などがあれば記載願います
- hoge

## 付記Tips（第１版＆第２版）

### 第１版Tips
|  No  |  Tips  |  Discription  |
| ---- | ---- | ---- |
|1|自らの技術に関心を持つこと|技術に関心を持たずに、どうやってソフトウェアの開発ができるのか？|
|2|あなたの仕事について考えること！|漫然と仕事するのではなく、意識して仕事する。また、常に批判的な目で自らの仕事を評価する。|
|3|いい加減な言い訳よりも対策を用意すること|言い訳ではなく対策を用意する。「できない」などと言わずにできることを明確にする。|
|4|割れた窓を放置しておかないこと|まずい設計、誤った意志決定、貧弱なコードを見つけたら修正する。|
|5|変化の触媒たれ|他人に変革を強制することはできない。そうではなく、未来を垣間見せ、その実現に参加できるよう手助けする。|
|6|大きな構想を忘れないようにすること|詳細に入り込みすぎて、周囲の状況をおろそかにしてしまわないようにする。|
|7|品質要求を明確にすること|プロジェクトにおける真の品質要求を決定するためには、ユーザーを巻き込む。|
|8|あなたの知識ポートフォリオに対して定期的な投資を行うこと|学習を習慣づける。|
|9|見聞きしたものごとを批判的な目で分析すること|ベンダーの売り文句、マスコミの宣伝、独断的考えに惑わされない。|
|10|伝えることがらと、伝える方法は車の両輪だと考えること|うまく伝えることができなければ、良いアイデアも無意味である。|
|11|DRY- Don't Repeat Yourself（繰り返しを避けること）|システム中のすべての知識は、重複なく、明瞭、信頼できる表現となっていなければならない。|
|12|再利用しやすいようにしておくこと|容易に再利用できれば、皆がそれを使うはずである。再利用をサポートできる環境を構築する。|
|13|関係のないもの同士の影響を排除すること|単独目的のうまく定義され、自己完結した独立コンポーネントを設計する。|
|14|最終決定などというものは存在しない|石に刻み込まれるような決定はあり得ない。すべての決定を砂浜の砂に描かれたものと考え、変更に備えておく。|
|15|目標を見つけるには曳光弾を使うこと|曳光弾を使えば、目標の補足と目標にどれだけ近く着弾したのかが判るようになる。|
|16|プロトタイプの真の目的は学びにある|プロトタイピングとは、学習経験のことである。その価値は出来上がったコードにあるのではなく、学習した教訓そのものなのである。|
|17|問題領域に近いところでプログラミングを行うこと|ユーザーの言葉で設計、コーディングを行う。|
|18|後でびっくりしないために、見積を行うこと|始める前に見積もりを行い、前もって潜在的な問題を洗い出しておく。|
|19|規律に従ってスケジュールを繰り返し、精度を向上させていくこと|プロジェクトの期間見積もりに磨きを掛けるには、その実装によって得た知識を用いる。|
|20|知識はプレインテキストに保存すること|プレインテキストは廃れることがなく、デバッグやテストを簡潔にする強力な武器となり得る。|
|21|コマンドシェルの力を使うこと|GUIが使えない場合はシェルを使う。|
|22|一つのエディタを熟知すること|エディタは手の延長となるべきであり、エディタが設定可能、拡張可能、プログラム可能であるかどうか、確認しておく。|
|23|常にソースコード管理システムを使用すること|ソースコード管理システムはあなたの仕事におけるタイムマシンであり、どんな過去にも戻ることができる。|
|24|非難するのではなく、問題を修復すること|バグの原因が誰にあるかは問題ではない➖問題はあなたのものであり、あなたが解決しなければならないのである。|
|25|パニックに陥らないこと|まず深呼吸をしてから、バグを引き起こした原因について考える。|
|26|"select"はおかしくない|OSやコンパイラ、サードパーティの製品やライブラリーにバグがあることは稀である。バグは大抵の場合アプリケーション側に存在する。|
|27|仮定せずに、証明すること|実際の環境➖つまり実際のデータと境界条件を用いて仮定を証明する。|
|28|テキスト操作言語を学ぶこと|毎日多くの時間をテキスト作業に割いているなら、そういった作業をコンピュータにさせるべきである。|
|29|(old)コードを生成するコードを生成すること|コードジェネレータは、生産性と二重化を避けるための武器である。|
|30|あなたは完璧なソフトウェアを作ることができない|ソフトウェアは完璧にはならない。このため、不可避のエラーからコードとユーザーを守る。|
|31|契約を用いて設計を行うこと|ドキュメントには契約の考え方を用い、コードがそれ以上のこともそれ以下のことも行わないことを検証する。|
|32|早めにクラッシュさせること|中途半端に動いているプログラムは、停止したプログラムよりもたちが悪い。|
|33|もし起こり得ないというのであれば、表明を用いてそれを保証すること|仮定を検証するには表明を使用する。表明を用いて不確かな世界からコードを守る。|
|34|(old)例外は例外的な問題のみに使用すること|例外の使い方を誤ると、古典的なスパゲッティコードに起因するすべての可読性と保守性の問題が呼び込まれる。例外は例外的な場合にのみ用いる。|
|35|始めたことは終わらせること|リソースの開放は、可能な限りそのリソースを割当てたルーチンやオブジェクトが責任を持って行うべきである。|
|36|(old)モジュール間の結合度を最小にすること|「恥ずかしがりなコード」を記述し、デメテルの法則を適用することにより、結合度を低く抑える。|
|37|(old)設定とすべきものを統合しないこと|何でも統合してしまうのではなく、設定オプションを用いて必要なものをアプリケーションが選択できるようにする|
|38|(old)抽象概念はコード上に、詳細はメタデータ上に置くこと|概念的なものをプログラムし、詳細はコンパイルされたコード中には記述しない。|
|39|並列性の改善にはワークフローを分析すること|ユーザーのワークフローにある並列性を活用する。|
|40|(old)サービスを使って設計を行うこと|サービス（整合性のあるインターフェースをうまく定義した、独立／並列動作可能なオブジェクト）を用いて設計を行う。|
|41|(old)常に並列性を意識した設計を行うこと|並列性をもたせることにより、仮定の少ないきれいなインターフェースを設計する。|
|42|(old)モデルからビューを分離すること|モデルとビューを用いてアプリケーションを設計することにより、安価で柔軟性の高い設計を目指す。|
|43|ワークフローを協調させるためにはホワイトボードを使用すること|独立性を保ったまま共通点のない事実やエージェントを協調させるには、ホワイトボードを使用する。|
|44|偶発的なプログラミングを行わないこと|信頼のおけるもののみを信頼する。偶然の符合に注意し、当初の確固たる目的と偶然の一致を区別する。|
|45|アルゴリズムのオーダーを見積もること|どのくらいかかるのか、コードを書き始める前に感じ取れるようにする。|
|46|見積もりの検証を行うこと|アルゴリズムの数学的分析で、すべてが判るわけではない。このため、対象としている環境で実際に測定する。|
|47|早めにリファクタリングすること、そしてこまめにリファクタリングすること|庭の雑草取りや植物の再配置を行うのと同じように、必要に応じてコードの再記述、再作業、再アーキテクトを行う。そして問題の根本原因を修正する。|
|48|テスト設計を行うこと|コードの記述を始める前にテストのことを考え始める。|
|49|ソフトウェアをテストすること、さもなければユーザーにテストを強いることになる|容赦ないテストを行う。ユーザーが先にバグを見つけることのないようにする。|
|50|(old)ウィザードの生成コードが理解できないのであれば、ウィザードを使わないこと|ウィザードを使えば大量のコードを生成できるが、そのすべてが理解できるまではプロジェクト中に組み入れない。|
|51|(old)要求は拾い集めるものではなく、掘り起こすものである|要求が見えるところに横たわっていることは稀である。要求は、仮定、誤解、政策といった層に深く埋められているものである。|
|52|(old)ユーザーの視点に立つには、ユーザーと働くこと|システムの本当の使用方法について理解を得るにはこれが一番の方法である。|
|53|(old)抽象は詳細よりも息が長いものである|実装ではなく、抽象化に労力をつぎ込む。抽象は、異なった実装や新技術といったものに起因する集中砲火に耐えることができる。|
|54|プロジェクトの用語集を作ること|プロジェクトが使用する特定の専門用語や語彙をまとめた用語集を作成、維持する。|
|55|枠にとらわれずに考えるのではなく、枠を見つけ出すこと|不可能と思われる問題に直面した場合、実際の制約を見抜く。「この手段でやり遂げなければならないのか？」「多少なりともの方法でやり遂げなければならないのか？」を自問する。|
|56|心の声に耳を傾け、準備ができてから開始すること|長い人生で培ってきた経験を信じ、小さな疑いも無視しない。|
|57|(old)解説しないほうがよい場合もある|仕様の渦の中に巻き込まれず、どこかのタイミングでコーディングを開始する。|
|58|(old)形式的方法論の奴隷になってはいけない|実際の開発における実用性や能力といった観点を抜きにして、方法論を盲信してしまうことは避ける。|
|59|(old)高価なツールが良い設計を生み出すとは限らない|ベンダーの誇大広告、業界の偏見、価格の高さに惑わされず、メリットでツールを評価する。|
|60|職務権限ではなく、機能によってチームを編成すること|設計者、コーディング担当、テスト担当を分断してしまわない。コードのビルドと同じ方法でチームを編成する。|
|61|手作業は危険である|シェルスクリプトやバッチファイルを使えば同じ作業を同じ順序で何度も実行できる。|
|62|早目にテスト、何度もテスト、自動でテスト|毎回ビルドを行う度に実行されるテストは、棚にしまわれているテスト計画よりもずっと有効なものとなる。|
|63|テストがすべて終わるまでコーディングは終わらない|これ以上、言うことなし。|
|64|テストのテストをするには破壊工作を試みる|テストがうまく機能するかどうかを確認するには、目的に応じたバグをソースのコピーに混入してみる。|
|65|コードのカバレージではなく、状態のカバレージをテストすること|テストは、重要なプログラムの状態を識別して行う。すべての行をテストしただけでは十分ではない。|
|66|複数のバグを一度に見つけること|テスト担当者がバグを見つけた場合、今後はもうそれと同種のバグをテスト担当者が見つけることのないようにする。以降は自動化されたテストにチェックさせる。|
|67|日本語をもう一つのプログラミング言語として扱うこと|コーディングを行うようにドキュメントを記述する。DRY原則を守り、メタデータ、MVC、コードの自動生成と言った技法を使用する。|
|68|ドキュメントは付け足すものではなく、組み込むものである|コードと別に作られたドキュメントは、正確性に劣り、すぐに陳腐化する。|
|69|(old)ユーザーの期待を少しだけ上回ること|ユーザーの期待を理解し、それよりも少し良いものを作る。|
|70|あなたの作品に署名すること|初期の職人が自らの成果物に誇りを持って署名したように、ソフトウェアに署名する。|

### 第２版Tips
|  No  |  Tips  |  Discription  |
| ---- | ---- | ---- |
|1|自らの技術に関心を持つこと|ソフトウェア開発をうまく進めようという心を持たずして、自らの人生をソフトウェア開発に費やそうとするなかれ。|
|2|あなたの仕事について考えること！|漫然と仕事を進めるのではなく、自ら制御権を掌握すること。そして、常に批判的な目で自らの作業を評価すること。|
|3|(new!)あなたには現状を打破する力がある|これはあなたの人生についての話である。しっかりと手綱を握り、自らが望むように進めていくこと。|
|4|いい加減な言い訳よりも対策を用意すること|言い訳ではなく対策を用意する。「できない」などと言わずに「できる」ことを明確にする。|
|5|割れた窓を放置しておかないこと|まずい設計、誤った意志決定、貧弱なコードをみつけたら修正する。|
|6|変化の触媒たれ|他人に変革を強制することはできない。そうではなく、未来を垣間見せ、その実現に参加できるように手助けする。|
|7|大きな構想を忘れないようにすること|詳細に入り込みすぎて、周囲の状況をおろそかにしてしまわないようにする。|
|8|品質要求を明確にすること|ユーザーを巻き込み、プロジェクトの真の品質要求を決定する。|
|9|あなたの知識ポートフォリオに対して定期的な投資を行うこと|学習の習慣をつける。|
|10|見聞きしたものごとを批判的な目で分析すること|ベンダーの売り文句、メディアの宣伝、独善的考えに惑わされない。あなたとあなたのプロジェクトという観点から情報を分析する。|
|11|日本語をもうひとつのプログラミング言語として考えること|日本語をもうひとつのプログラミング言語として考え、コーディングを行うようにドキュメントを記述する。DRY原則、ETC、自動化などを順守する。|
|12|伝えることがらと、伝える方法は車の両輪だと考えること|うまく伝えることができなければ、良いアイデアも無意味である。|
|13|ドキュメントは付け足すものではなく、作り上げるものである|コードと別に作られたドキュメントは、正確性に劣り、すぐに陳腐化する。|
|14|(new!)良い設計は悪い設計よりも変更しやすい|ものごとはそれを使う人に適応できる場合にうまく設計されていると言える。コードの場合、それは変化に対応できなければならないということを意味している。|
|15|DRY➖Don't Repeat Yourself（繰り返しを避けること）|システム中のすべての知識は、重複なく、明瞭、信頼できる表現となっていなければならない。|
|16|再利用しやすいようにしておくこと|再利用しやすくしておけば、皆はそれを使うためにやってくる。再利用をサポートできる環境を構築する。|
|17|関係のない者同士の影響を排除すること|単一目的のうまく定義され、自己完結した独立コンポーネントを設計する。|
|18|最終決定などというものは存在しない|石に刻み込まれたような決定はあり得ない。すべての決定を砂丘の砂に描かれたものと考え、変更に備えておく。|
|19|(new!)流行を追い求めないようにする|Neal Fordの言葉、「昨日のベストプラクティスは明日のアンチパターンになる」を噛みしめ、流行ではなく、地に足のついたアーキテクチャーを選ぶこと。|
|20|目標を見つけるには曳光弾を使うこと|曳光弾を使えば、目標の補足と目標にどれだけ近く着弾したのかが判るようになる。|
|21|プロトタイプの真の目的は学びにある|プロトタイプとは、学習の経験についてである。その価値は出来上がったコードにあるのではなく、学習した教訓そのものにある。|
|22|問題領域に近いところでプログラミングを行うこと|問題領域の言葉で設計、コーディングを行う。|
|23|後でびっくりしないために、見積を行うこと|始める前に見積もりを行い、前もって潜在的な問題を洗い出しておく。|
|24|規律に従ってスケジュールを繰り返し、精度を向上させていくこと|プロジェクトの期間見積もりに磨きを掛けるには、その実装によって得た経験を用いる。|
|25|知識はプレインテキストに保存すること|プレインテキストは、廃れることがなく、デバッグやテストを簡潔にする強力な武器となり得る。|
|26|コマンドシェルの力を使うこと|GUIで実現できなければシェルを使う。|
|27|エディターに熟達すること|エディターは最も重要なツールである。やりたいことを迅速かつ正確に実現できる方法を知っておく必要がある。|
|28|常にバージョン管理システムを使用すること|バージョン管理システムはあなたの仕事で使えるタイムマシンであり、どんな過去にも戻ることができる。|
|29|非難するのではなく、問題を修復すること|バグの原因が誰にあるかは問題ではない➖問題はあなたのものであり、あなたが、解決しなければならないのだ。|
|30|パニクるな|銀河のヒッチハイカーと開発者はこの言葉を忘れてはいけない。|
|31|(new!)コード修正の前にテストを失敗させること|バグの修正に取り掛かる前に、そのバグを再現するテストを作成すること。|
|32|(new!)エラーメッセージをちゃんと読む|ほとんどの例外メッセージには、どこでどういったことが発生したのかも含まれている。運が良ければパラメーターの値も表示されている。|
|33|"select"は壊れていない|OSやコンパイラ、さらにはサードパーティーの製品やライブラリーのバグを見つけることはまれである。バグはたいていの場合、アプリケーション側に存在する。|
|34|仮定を置かずに、証明すること|実際の環境➖つまり実際のデータと境界条件を用いて仮定を証明する。|
|35|テキスト操作言語を学ぶこと|毎日多くの時間をテキスト作業に割いているなら、そういった作業をコンピュータにさせるべきである。|
|36|あなたは完璧なソフトウェアを作ることができない|ソフトウェアは完璧にはならない。不可避のエラーからコードとユーザーを守る。|
|37|契約を用いて設計を行うこと|ドキュメントには契約の考え方を用い、コードがそれ以上のこともそれ以下のことも行わないようにする。|
|38|早めにクラッシュさせること|中途半端に動いているプログラムは、停止したプログラムよりもたちが悪い。|
|39|もし起こり得ないというのであれば、表明を用いて保証すること|仮定を検証するには表明を使用する。表明を用いて不確かな世界からコードを守る。|
|40|始めたことは終わらせる|リソースの開放は、可能な限りそのリソースを割当てた関数やオブジェクトが責任を持って行うべきである。|
|41|(new!)ものごとを局所的にする|変更可能な変数のスコープを制限し、リソースの使用時間を短くするとともに可視化できるようにしておくこと。|
|42|(new!)少しずつ進めること➖常に|常に小さな歩幅で少しずつ進める。そしてフィードバックを得た上で、先に進む前に軌道修正を加える。|
|43|(new!)予言は避ける|見えるところまでのみを見るようにする。|
|44|(new!)分離されたコードは変更しやすい|ものごとを結合させると、１つのことを修正するのも難しくなる。|
|45|(new!)照会せずに依頼する（TDA：Tell, Don't Ask）|オブジェクトから値を取得し、その値を操作し、結果をオブジェクトに戻してはいけない。該当オブジェクトにすべての仕事を任せること。|
|46|(new!)メソッド呼び出しを連鎖させないこと|何かにアクセスする際には、ドット（.）を２つ以上続けないこと。|
|47|(new!)大域データを避ける|これはすべてのメソッドにパラメーターを追加して回るのと同じ結果になる。|
|48|(new!)大域データにするだけ重要なものである場合、APIでラップする|・・・とは言うものの、どうしても大域データにしておきたい場合にのみこの手を選択すること。|
|49|(new!)プログラミングとはコードについての話であるが、プログラムはデータについての話である|すべてのプログラムはデータを変換し、入力を出力へと変える。まず、変換を用いた設計を考えること。|
|50|(new!)状態をため込まず、引き渡すようにする|関数やモジュール内にデータをため込まずに、引き渡すようにすること。|
|51|(new!)インヘリタンス（相続）税を払わないこと|インターフェースや委譲、mixinといったニーズに見合った代替策を考慮すること。|
|52|(new!)ポリモーフィズムの表現にはインターフェースを愛用すること|インターフェースは、継承によって生み出されるような結合を気にすることなくポリモーフィズムを実現できる。|
|53|(new!)サービスに委譲すること：has-a は is-a に勝る|サービスを継承してはならない。サービスを保持するようにすること。|
|54|(new!)機能の共有には mixin を使用する|mixinを使えば、相続税を支払うことなくクラスに機能を追加できるようになる。インターフェースと組み合わせて、痛みを伴わないポリモーフィズムを実現すること。|
|55|(new!)外部設定を用いてアプリをパラメーターに対応させる|アプリケーションが本番稼働に入った後でも、ある程度挙動を変えられるようにするには、アプリの外側でそういった挙動を指示する値を保持しておく。|
|56|並行性を向上させるためにワークフローを分析する|ユーザーのワークフローに於ける並行性を明らかにする。|
|57|(new!)共有状態は間違った状態|状態の共有によって、すべてをやり直すしかないほどのさまざまな問題が生み出される。|
|58|(new!)無秩序なエラーはしばしば並行処理によって引き起こされる|並行処理のバグは、タイミングやコンテキストの変化によって無秩序かつ再現性のないかたちで引き起こされる。|
|59|(new!)共有状態を持たないアクターを並行処理で使用する|明示的な同期を用いずに並行状態を管理するにはアクターを使用する。|
|60|ワークフローを協調させるためにはホワイトボードというコンセプトを活用すること|独立性を保ったまま共通点の無い事実やエージェントを協調させるには、ホワイトボードを使用する。|
|61|爬虫類脳に耳を傾ける|開発中のコードが抵抗しているように感じられるのは、あなたの無意識が何らかの間違いを訴えかけているためである。|
|62|偶発的プログラミングを行わないこと|信頼のおけるもののみを信頼する。偶発的な複雑さを避け、単なる偶然と意図的な結果を混乱しないようにする。|
|63|アルゴリズムのオーダーを見積もること|どのくらいリソースを消費するのか、コードを書き始める前に感触をつかむようにする。|
|64|見積もりの検証を行うこと|アルゴリズムの数学的分析ですべてが判るわけではない。このため、対象としている環境で実際に測定する。|
|65|早めにリファクタリングすること、そしてこまめにリファクタリングすること|庭の雑草取りや植物の植え替えと同じように、必要に応じてコードの再記述、再作業、再アーキテクトを行う。そして問題の根本原因を修正する。|
|66|(new!)テストとはバグを見つけることではない|テストとは、コードに対する１つの観点であり、その設計やAPI、結合についてのフィードバックを与えてくれるものである。|
|67|(new!)テストはコードのユーザー第１号である|テストからのフィードバックを活用し、要求に対する洞察を深めること。|
|68|(new!)トップダウンでもボトムアップでもなく、エンドツーエンドで構築していく|エンドツーエンドで小さな機能を構築し、そこから作業を進めながら問題について学習していく。|
|69|テスト設計を行うこと|コードの記述を始める前にテストのことを考え始める。|
|70|ソフトウェアをテストすること、さもなければユーザーにテストを強いることになる|容赦ないテストを行う。ユーザーが先にバグを見つけることのないようにする。|
|71|(new!)仮定を検証するためにプロパティーベースのテストを使用すること|プロパティーベースのテストは、あなたが試してみようと思ったことのないテストを試し、想定されていない方法でコードを実行してくれる。|
|72|(new!)KISSの原則を守り、アタックサーフェスを最小化する|複雑なコードはバグや、攻撃に利用できる脆弱性の温床となる。|
|73|(new!)セキュリティパッチはすぐに適用すること|攻撃者はすぐに攻撃を仕掛けることができるため、それよりも先に手を打つ必要がある。|
|74|(new!)適切な名前を付け、必要に応じてリネームすること|読み手に意図を理解してもらえる名前を付け、意図が変わったのであればすぐにリネームすること。|
|75|(new!)自らが欲しているものを正確に認識している人などいない|全体的な方向性は分かっているかもしれないが、その先に待ち構えている紆余曲折など誰も知らない。|
|76|(new!)プログラマーの仕事は、人々自身が欲しているものを自ら気づいてもらえるように支援すること|ソフトウェア開発とは、ユーザーとプログラマーによる共同開発という行為である。|
|77|(new!)要求はフィードバックループの中で学んでいくものである|要求を理解するには、探求とフィードバックが必要となり、意思決定の積み重ねが初期のアイデアを洗練する鍵となる。|
|78|(new!)ユーザーとともに働き、ユーザーのように考える|これがシステムの「実際の使用法」について洞察を得る最善の手である。|
|79|(new!)ポリシーはメタデータである|ポリシーをシステム内にハードコーディングしてはいけない。ポリシーはシステムによって使用されるメタデータとして表現すること。|
|80|プロジェクトの用語集を作ること|プロジェクトが使用する特定の専門用語や語彙をまとめた用語集を作成、維持する。|
|81|枠にとらわれずに考えるのではなく、枠を見つけ出すこと|不可能と思える問題に遭遇した場合、「本当の制約」を見抜く。「この手段でやり遂げなければならないのか？」「そもそもやらなければならないのか？」を自問する。|
|82|(new!)１人ぼっちでコーディングに取り組んではいけない|プログラミングは要求水準の高い難しい作業である。このため仲間を連れて行くように。|
|83|(new!)Agileという言葉は名詞ではなく、ものごとの進め方を形容する形容詞である|「Agile」は何かを実行するあなたのスタイルを指す形容詞である。|
|84|(new!)小規模で安定したチームを作ること|チームはメンバー全員がお互いのことをよく知っており、信頼し合い、助け合う、小規模で安定したものとなっているべきである。|
|85|(new!)事を成し遂げるにはまずスケジュールする|スケジュールしなければ何ごとも起こらない。振り返りや実験、学習、スキルの向上をスケジュールする。|
|86|完璧に機能するチームを編成すること|チームの編成は、職務権限ではなく機能に基づいて実施すること。ユーザーインターフェースとユーザーエクスペリエンスのデザイナーとコーダーを、フロントエンドとバックエンドを、テスターとデータモデラーを、設計と配備を分離してはいけない。コードをエンドツーエンドで構築でき、インクリメンタル且つイテレーティブに開発できるチームを編成すること。|
|87|(new!)流行を追いかけるのではなく、効き目があるものごとを実行すること|他社が実践しているだけと言うだけの理由で開発手法や開発テクニックを採用してはいけない。あなたのコンテキストで、あなたのチームに有効なものを採用すること。|
|88|(new!)ユーザーが必要としたタイミングで調達すること|採用しているプロセスを理由にして、何週間も、あるいは何ヶ月も調達を遅らせてはいけない。|
|89|(new!)バージョン管理によってビルド／テスト／リリースを駆動すること|コミットやプッシュを使用してビルドやテスト、リリースを起動する。本番環境への配備を実行するためにバージョン管理タグを使用する。|
|90|早めにテスト、何度もテスト、自動でテスト|毎回ビルドを行うたびに実行されるテストは、棚にしまわれているテスト計画書よりもずっと有効なものとなる。|
|91|テストがすべて終わるまでコーディングは終わらない|これ以上の説明は要らないはず。|
|92|テストのテストをするには破壊工作を試みる|テストがうまく機能するかどうかを確認するには、目的に応じたバグをソースのコピーに混入してみる。|
|93|コードのカバレージではなく、状態のカバレージをテストすること|テストは、重要なプログラムの状態を識別して行う。すべての行をテストしただけでは十分ではない。|
|94|同種のバグを一度に見つけること|テスト担当者がバグを見つけた場合、今後はもうそのバグ自体を人間が見つけることのないようにする。以降は自動化されたテストにチェックさせる。|
|95|手作業を排除する|コンピュータであれば同じ命令で同じ順序で何度も実行できる。|
|96|(new!)単にコードを調達するのではなく、ユーザーを喜ばせる|業務価値を生み出すソリューションをユーザーのために生み出し、彼らを日々喜ばせる。|
|97|あなたの作品に署名すること|先人たちが自らの成果物に誇りを持って署名をしたように、ソフトウェアに署名する。|
|98|(new!)とにかく、害をなさないようにすること|問題の発生は避けられない。誰も問題によって苦しまないようにすること。|
|99|(new!)極悪なことを実行できるようにしない|さもなければ自らも極悪な人間になるリスクを負うことになる。|
|100|(new!)これはあなたの人生だ。皆と共有し、祝福し、生み出していくこと。そして思いっきり楽しむこと！|素晴らしい人生を楽しみ、偉大な成果を成し遂げよう。|