刑務所の鉄格子の間から、二人の男が外を見た。 一人は泥を眺め、一人は星を眺めた。

道を知ることと、道を歩くことは違う。

テレビゲームのコントローラを握ったら、落とし穴に落ちたり火の玉に飲み込まれたりせずにゲームに完勝できるなどとは思わないだろう。それならなぜ、失敗を経験せずに人生を生き抜けると思うのだろうか。

間違うことのコストが小さい場合には、いつも必ず何もしないより何かをすることを選ぶべきだ。

良い本！

文章の各レベルで「何を主張しているのか」を自問すること

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

設計の損益分岐点はプログラマーによって異なります。経験の浅いプログラマーがいくら将来を予測した設計をしたところで、その初期の設計努力が報われる日が来ることは、おそらく永遠にないでしょう。注意深くコードを書く熟練者であれば、午前中に書いたコードで午後のうちにコストを削減できるかもしれません。あなたの熟練度はおおむねその極端な間のどこかに位置するはずです。

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

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

テーブル定義において、列には可能な限りNOT NULL制約を付加する。

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

また、チームの規模が大きくなりすぎると、多元的無知と呼ばれるものも発生する。多元的無知とは、内心では否定していることに対して、自分が何かを見落としているのだろうと考え、全員が同意してしまう現象だ。

基本的に、アーキテクトは２つのものを設計する。それは、指定されたあらゆるドメインと、システムを成功させるために必要なその他のすべての構造要素だ。

私たちは、ソフトウェアアーキテクチャを、システムの構造、システムがサポートしなければならないアーキテクチャ特性、アーキテクチャ決定、そして設計指針の組み合わせで構成されるものだと考えている。

個人の中にある知識は、すべて「わかっていること」と「わかっていないとわかっていること」と「わかっていないとわかっていないこと」の３つに分類できる。

アイランドチェーン方式では、アプリケーションをすべて同じリポジトリで管理し、データも同じデータベースに保存します。一方、アプリケーションの構成要素は別々のプロセスで動作させます。

新米プログラマーは「機能を削除する」と聞くと、何か良くないことのように思うかもしれません。しかし経験豊富なプログラマーにとっては最も喜ばしい瞬間のひとつです。

メソッドは、パブリックにすべきかプライベートにすべきかについて確信を持てなければ、プライベートにしましょう。

原則のひとつは、「APIの設計にあたっては、APIを使いやすくすることだけでなく、APIを誤って使うのを難しくすることを考慮すべき」です。これを「誤用耐性（misuse resistance）の原則」と呼びます。