01 まえがき
人々は 80 年以上にわたってコンピューター用のプログラムを作成してきましたが、これらのプログラムの設計方法や優れたプログラムとは何かについては、驚くほどほとんど議論されていません。ソフトウェア開発プロセス (アジャイル開発など) や開発ツール (デバッガー、バージョン管理システム、テスト カバレッジ ツールなど) については、かなりの量の議論が行われてきました。オブジェクト指向プログラミングや関数型プログラミングなどのプログラミング手法、設計パターンやアルゴリズムも幅広く分析されています。この議論はすべて貴重なものですが、ソフトウェア設計の中核問題はほとんど手付かずのままです。David Parnas の古典的な論文「システムをモジュールに分解するための基準について」は 1971 年に出版されましたが、その後 45 年間、ソフトウェア設計はその論文を超えて進歩することはありませんでした。
コンピューター サイエンスにおける最も基本的な問題は問題の分解です。つまり、複雑な問題を独立して解決できるいくつかの部分に分解する方法です。問題の分解は、プログラマーが毎日直面する設計の中核タスクですが、ここで説明する作業を除けば、問題の分解を中心的なトピックとして扱っている授業はどの大学にもまだ見つかりません。私たちはループとオブジェクト指向プログラミングを教えますが、ソフトウェア設計は教えません。
さらに、プログラマーによって品質と生産性には大きな差がありますが、最高のプログラマーの何が優れているのかを理解しようとしたり、教室でそのスキルを教えようとしたりすることはほとんどありません。私は優れたプログラマーだと思う何人かと話しましたが、彼らのほとんどは、優位性をもたらす特定のテクニックを明確に説明するのが苦手です。多くの人は、ソフトウェア設計スキルは生まれ持った才能であり、教えることはできないと信じています。しかし、多くの分野での卓越性は、生来の能力よりも質の高い実践と関係があるというかなりの科学的証拠があります（たとえば、ジェフ・コルビンは才能を過大評価しています）。
これらの疑問は何年も私を悩ませ続けてきました。ソフトウェア設計を教えられるかどうか疑問に思っていますが、優れたプログラマと凡庸なプログラマを区別するのは設計スキルだと考えています。私は最終的に、これらの質問に答える唯一の方法は、ソフトウェア設計のコースを教えてみることだと決心しました。その結果がスタンフォード大学の CS 190 です。このクラスでは、ソフトウェア設計の一連の原則を紹介します。その後、学生は一連のプロジェクトを通じてこれらの原則を吸収し、実践します。このクラスは、伝統的な英語ライティングのクラスと同様の方法で教えられます。英語の授業では、生徒は下書きを書き、フィードバックを得て、改善するために書き直すという反復プロセスを使用します。CS190 では、学生はかなりの量のソフトウェアをゼロから開発します。次に、広範なコード レビューを実施して設計上の問題を特定し、学生は問題に対処するためにプロジェクトを修正します。これにより、学生は、設計原則を適用することでコードをどのように改善できるかを理解できます。
私は現在 3 つのソフトウェア設計クラスを教えており、この本はそのクラスでの設計原則に基づいています。原則はかなり高度で、哲学的（「定義の誤りは存在しない」）に近いため、学生は抽象的な概念を理解するのが困難です。学生は、コードを書いて間違いを犯し、その間違いとその後の修正が原則とどのように関連しているかを確認することで最もよく学びます。
この時点で、あなたは次のように考えているかもしれません。なぜ私がソフトウェア設計についてすべての答えを持っていると思うのでしょうか? 正直に言うと、分かりません。私がプログラミングを学び始めたとき、ソフトウェア設計のクラスは受講していませんでしたし、設計原則を教えてくれる指導者もいませんでした。私がプログラミングを学んでいた頃は、コードレビューはほとんど存在しませんでした。ソフトウェア設計についての私の考えは、コードを書いたり読んだりした個人的な経験に基づいています。これまでのキャリアを通じて、私はさまざまな言語で約 250,000 行のコードを作成してきました。私のチームは、3 つのオペレーティング システム、複数のファイルおよびストレージ システム、インフラストラクチャ ツール (デバッガ、ビルド システム、GUI ツールキットなど)、スクリプト言語、およびテキスト、描画、プレゼンテーション、集積回路用のツールをゼロから作成しました。その過程で、私は大規模システムの問題を直接経験し、さまざまな設計手法を試しました。さらに、他の人が書いたコードをたくさん読んだので、良いことも悪いことも含めて、さまざまな方法を知ることができました。
これらすべての経験から、避けるべき間違いや使用すべきテクニックなど、いくつかの共通点を抽出しようとしています。この本は私の経験を反映しています。ここで説明されているすべての問題は個人的に経験したものであり、提案されているすべてのテクニックは私が自分のコーディングでうまく使用したものです。
私はこの本をソフトウェア設計に関する最後の言葉にしたくありません。私はいくつかの貴重なコツを見逃していると確信していますし、私のアドバイスの一部は長期的には悪いアイデアになるかもしれません。しかし、この本がソフトウェア設計についての会話のきっかけになれば幸いです。本書のアイデアをあなた自身の経験と比較し、ここで説明されているアプローチが実際にソフトウェアの複雑さを軽減するかどうかを自分で判断してください。本書は意見書であるため、私の推奨事項の一部に同意しない読者もいるでしょう。同意できない場合は、その理由を理解するように努めてください。私は、何があなたにとってうまくいったのか、何がうまくいかなかったのか、そしてソフトウェア設計に関するあなたのその他の考えに興味があります。以下の会話により、ソフトウェア設計に対する全体的な理解が深まることを願っています。私が学んだことは、この本の今後の版に取り入れていきます。
この本について私に連絡する最良の方法は、次のアドレスに電子メールで連絡することです。
ソフトウェア設計に関する一般的な考えや経験だけでなく、バグや改善の提案など、書籍に関する具体的なフィードバックを聞くことに興味があります。私は、この本の将来の版で使用できる説得力のある例に特に興味があります。最良の例は重要な設計原則を示しており、1 ～ 2 段落で説明できるほど簡単です。他の人が電子メール アドレスについて何を言っているかを知り、ディスカッションに参加したい場合は、Google グループ Software Design Books に参加できます。
何らかの理由で Software Design Books Google グループが将来消滅することになった場合は、Web で私のホームページを検索してください。そこには、この本の伝え方に関する最新の説明が含まれています。私の個人メールボックスに書籍関連のメールを送らないでください。
この本のアドバイスを割り引いて聞くことをお勧めします。全体的な目標は複雑さを軽減することであり、これはここで読む特定の原則やアイデアよりも重要です。この本にあるアイデアを試してみて、複雑さが軽減されないとわかった場合は、それを使い続ける義務はありません (ただし、あなたの経験を教えてください。何が機能し、何が機能しないのかについて洞察を得たいのです)のフィードバック）。
多くの人がこの本の品質を向上させるために批判や提案を提供してくれました。この本のさまざまな版について、次の方々が有益なコメントを提供してくださいました: Jeff Dean、Sanjay Gumawalt、John Hartman、Brian Kernihan、James Coppel、M. Oosterhout、Kai Oosterhout、Rob Peck、Pasha Ranganathan、Keith Schwartz、Alex Snapes。Christos Kozyrakis は、クラスとインターフェイスに、やや曖昧だった以前の「thick」と「thin」ではなく、「deep」と「shallow」を使用することを提案しました。CS 190 の学生たちに感謝しています。彼らのコードを読んで彼らと議論するプロセスは、設計についての私の考え方を明確にするのに役立ちました。