見た目が美しいコードのほうが使いやすいのは明らかだ。考えてみれば、プログラミングの時間のほとんどはコードを読む時間なのだッ！　さっと流し読みができれば、誰にとっても使いやすいコードだと言えるだろう。

どんなバンドで演るときも一番下手くそなプレイヤーでいろ。 IT業界に入る前、僕はジャズとブルースのサックス奏者をしていた。バンドの中で一番下手くそというのは、いつも自分より優れた人たちと一緒に演奏するという意味だ。

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

良い本！

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

繰り返しますが、大切なのはスクラムかSpotifyモデルかというプラクティスではありません。重要なのはプラクティスを支える原則や、それを生み出す価値観のあり方、すなわち文化です。「文化が重要」なのです。

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

目的が明確な作業と、助け合いながら開発を進めていける環境の２つはモチベーションの向上に大きく寄与しました。

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

ブロックやProcオブジェクトを渡せるようなメソッドを定義すると、定型的な処理の一部に対して外部からカスタマイズ可能な振る舞いを組み込むことができます。

プログラムが大きくなってきたときに、意味のあるまとまりで分割することで、書きやすく、また読みやすいプログラムにすることができます。また、同じ処理は１カ所にまとめて書くことで共同利用することもできます。

type文では任意の型に対して別名を宣言できましたが、interface宣言で扱えるのはオブジェクト型だけです。

普通の人間とプロを隔てているのは恐怖心

リーダーが開発者に望んでいるのは、バンガロールのチームのような気概と自立心だ。計画を作成して実行し、その成果を報告することは、両方を獲得するのに大いに役立つだろう。

誰もがコルトレーンやモーツァルトになれるわけじゃない。しかし、情熱を持てる仕事を見つけることで、凡人からの大きな一歩を踏み出すことができる。

リズムが一定になると、これまでよりも決断を下しやすくなるので、プロジェクトも前進し続けられるようになる。

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

変数や関数などの構成要素の名前は、抽象的ではなく具体的なものにしよう。

このように、変数には見える範囲と寿命があります。変数の見える範囲と寿命のことを、「スコープ」といいます。これまでにでてきた変数たちはローカル変数と呼ばれます。

また、テストコードを書いてからデバッグすれば、デバッグの修正と同時にそのロジックのテストコードができあがります。なので、プログラムにほかの修正が入った場合でも、そのテストコードを実行すればそのロジックが壊れていないことを保証できます。デバッグの時間を短縮できる、できないにかかわらずテストコードを書いておくことは非常に良い習慣だと言えるでしょう。