まずは数多くTryを出すようにしましょう。突拍子もないような改善策や、些細な改善策、実効性のない改善策を挙げていけば、数を増やせます。その中から、素晴らしい改善案が出るかもしれません。

文字列の中に指定したルールの文字列が含まれるかどうかを調べたり、ルールに従って文字列を置き換えたりするときには、正規表現と呼ばれる機能を使うことができます。

インスタンスを初期化するために実行したい処理があれば、このinitializeメソッドでその処理を実装します（とくに必要がなければ定義しなくてもかまいません）。ほかのプログラミング言語の経験者であれば、コンストラクタのようなものと考えるとわかりやすいと思います。

優れた開発者は、優れたサーファーと同じく、（技術的な）適性、バランス感覚、そしてアジャイルさを備えている。アジャイルであることとは、状況の変化にすばやく適応できる能力のことだ。

クロージャとは、引数以外にも関数定義時のコンテキストに含まれる変数などの情報を持つ関数オブジェクトのことをいいます。

リファクタリングの際に注意すべきこと はじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。

インスタンス変数は、インスタンス、つまりオブジェクトごとに存在する変数です。同じクラスに書かれているインスタンス変数でも、オブジェクトが別ならば、別のインスタンス変数になります。

読みにくいコードがあれば、そこで行われているタスクをすべて列挙する。そこには別の関数（やクラス）に分割できるタスクがあるだろう。それ以外は、関数の論理的な「段落」になる。タスクをどのように分割するかよりも、分割するということが大変なのだ。

ベロシティを予測する理想的な方法は、実際に１回、イテレーションを実施してしまうことだ（１回に限らず、２回でも３回でも構わないが）。そして、実施したイテレーションのベロシティをもとに、今後のベロシティを見積もるのだ。ベロシティを知る最もよい方法は実際に測ることなのだから、まずはこの方法を採用すべきである。

「開発準備OK」ステージは、基本的に「このステージには、エピックからの分割と見積りが行われており、要求の内容が明確になった機能が集まっているが、どの順番で開発を行うかまではまだ決定していない」という意味を持っている。

つまり、データベースという器の中にデータを蓄積さえすれば良いのではないということです。だからアウトプット志向で考えなければならないということになります。

HTTPメソッドのうちGET、POST、PUT、DELETEは、これら４つで「CRUD」という性質を満たすため、代表的なメソッドと言えます。

少しずつインクリメンタルにコーディングすること。そうすれば、開発が進むにつれてコードが洗練され、構造化されていくことに気づくだろう。インクリメンタルにコードを書いて、テストする。この継続的なフィードバックが、コードが過剰に複雑になったり、散らかり放題になることを防いでくれる。

本書で心から伝えたいことは２つだけだ。「権限を与えること」「信頼すること」。

スタートアップのプロダクト開発ではひたすらイテレーションを重ねる。プロダクトを一度だけ構築して勝利を宣言するのではなく、計測、分析、テストの結果から得られた知見をプロダクトに何度も何度もフィードバックする。

複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける。

このように、オブジェクトのクラスが何であろうとそのメソッドが呼び出せればよしとするプログラミングスタイルのことを「ダックタイピング（duck typing）」と呼びます。これは「もしもそれがアヒルのように歩き、アヒルのように鳴くなら、それはアヒルである」という言葉に由来するプログラミング用語です。

Rubyはオブジェクト指向言語です。文字列や配列はもちろん、数値やnil（ほかのプログラミング言語でいうところのnull）も含めて、すべてがオブジェクトになっています。その証拠に数値やnil、trueやfalseに対してもメソッドを呼び出すことができます。

インセプションデッキの背後にある考えはこうだ。「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ。」と。

アーキテクチャを形にする最も一般的な方法は、モデルを作成することだ。