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

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

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

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

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

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

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

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

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

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