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

やめようにもやめられないなら、挫折してもまた性懲りもなく始めてしまうなら、そこにお前さんの独学を動機付ける核があるんだろう。

実際にお客さんを目の前にしてソフトウェアをデモするだけで、チームは自分たちの果たすべき成果責任に対してもっと自覚的になれる。

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

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

こうした不都合を避けるために、チームと業務をつなぐ共通の用語を定めて、プロジェクト共通の言葉づかいを徹底しよう。ユーザーストーリー、モデル、図表、もちろんコードにもそうした言葉づかいを反映させるんだ。

当初作ろうと思っていたものよりも良いアイデアが出てくれば、それを受け入れ、作るものを変えていきます。そうすることで成果が最大化していきます。

早期の失敗を奨励する「フェイルファスト」手法、ソフトウェア開発における反復学習的な「スクラム」手法など、リーン・スタートアップのようないわゆる失敗型のアプローチは各所で見られるようになってきた。もちろん、状況に応じた使い分けは必要だが、どのアプローチも試行錯誤から大きな恩恵を受けていて、実に効率的なものが多い。

メタプログラミングは大いなる力であり、大いなる力には大いなる責任が伴います。

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

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

だから、改善は小さく少しずつでいい。ただし、毎日行うこと。小さな改善は失敗の代償も小さい。１日くらいだめでも、翌日新たに再開できる。

バーンダウンチャートとは、作業の進捗報告を見える化するツールです。

合意と同意は異なります。主責任者を決めて、その人に丸投げしてしまい、その人が困っていたとしても周りが助けないというのは、合意ではありません。合意とは、同意に加えて「全面的にサポートするという意思」まで含んでいます。

自分で例外を発生させることもできます。例外を発生させるときはraiseメソッドを使います。引数には例外のメッセージを指定します。メッセージの部分は自由に書くことができます。どんな例外が起きたかをプログラマーが調べるときに使えます。例外クラスで例外の種類を指定し、メッセージに具体的なエラー内容を書くとよいでしょう。

融合が進化の原動力になりつつある現代において、重要な役割を果たすのは、従来の枠組みを飛び越えていける人々だ。異なる分野間の橋渡しができる人々、立ちはだかる壁を不変のもの、破壊不可能なものとは考えない人々が、未来への成長の扉を開いていく。

たとえば、一つの情報が複数のテーブルに存在して無駄なデータ領域と面倒な更新処理を発生させてしまうということがあります（冗長性）。（……）こうした冗長性や非一貫性の問題を解決するために考案された方法論が、正規化です。

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

システムのソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったものだ。

エラーメッセージはRubyからプログラマーである私たちへのさまざまなヒント