diff --git a/README.md b/README.md
index cf9cdef..ed304a7 100644
--- a/README.md
+++ b/README.md
@@ -1,166 +1,5 @@
-# A-Philosophy-of-Software-Design
+# A-Philosophy-of-Software-Design 中文版
《软件设计哲学》
+
-## 目录
-
-#### 前言
-
-#### 1引言
-##### 1.1如何使用本书
-
-#### 2复杂性的本质
-##### 2.1定义复杂性
-##### 2.2复杂性的症状
-##### 2.3复杂性的原因
-##### 2.4复杂性是递增的
-##### 2.5结论
-
-#### 3工作守则还不够
-##### 3.1战术编程
-##### 3.2战略规划
-##### 3.3投资多少？
-##### 3.4初创公司和投资
-##### 3.5结论
-
-#### 4个模块应该很深
-##### 4.1模块化设计
-##### 4.2界面中有什么？
-##### 4.3抽象
-##### 4.4深层模块
-##### 4.5浅模块
-##### 4.6 Classitis
-##### 4.7示例：Java和Unix I / O.
-##### 4.8结论
-
-#### 5信息隐藏（和泄漏）
-##### 5.1信息隐藏
-##### 5.2信息泄露
-##### 5.3时间分解
-##### 5.4示例：HTTP服务器
-##### 5.5示例：类太多了
-##### 5.6示例：HTTP参数处理
-##### 5.7示例：HTTP响应中的默认值
-##### 5.8隐藏在类中的信息
-##### 5.9太过分了
-##### 5.10结论
-
-#### 6个通用模块更深入
-##### 6.1使课程有点通用
-##### 6.2示例：为编辑器存储文本
-##### 6.3更通用的API
-##### 6.4一般性导致更好的信息隐藏
-##### 6.5问自己的问题
-##### 6.6结论
-
-#### 7个不同的层，不同的抽象
-##### 7.1传递方法
-##### 7.2接口复制何时可以？
-##### 7.3装饰
-##### 7.4接口与实现
-##### 7.5传递变量
-##### 7.6结论
-
-#### 8向下拉复杂性
-##### 8.1示例：编辑器文本类
-##### 8.2示例：配置参数
-##### 8.3太过分了
-##### 8.4结论
-
-#### 9更好地在一起还是更好？
-##### 9.1如果共享信息，请汇集在一起
-##### 9.2如果它将简化界面，汇集在一起
-##### 9.3汇集在一起以消除重复
-##### 9.4单独的通用和专用代码
-##### 9.5示例：插入光标和选择
-##### 9.6示例：用于记录的单独类
-##### 9.7示例：编辑器撤消机制
-##### 9.8分裂和连接方法
-##### 9.9结论
-
-#### 10定义存在的错误
-##### 10.1为什么例外会增加复杂性
-##### 10.2太多例外
-##### 10.3定义错误不存在
-##### 10.4示例：Windows中的文件删除
-##### 10.5示例：Java子串方法
-##### 10.6掩盖异常
-##### 10.7异常聚合
-##### 10.8刚崩溃？
-##### 10.9设计特殊情况不存在
-##### 10.10太过分了
-##### 10.11结论
-#### 11设计两次
-#### 12为什么写评论？ 四个借口
-##### 12.1好的代码是自我记录的
-##### 12.2我没时间写评论
-##### 12.3评论过时并变得具有误导性
-##### 12.4我看到的所有评论都毫无价值
-##### 12.5写得好的评论的好处
-
-#### 13评论应该描述代码中不明显的事情
-##### 13.1选择约定
-##### 13.2不要重复代码
-##### 13.3较低级别的注释增加了精度
-##### 13.4更高层次的评论增强了直觉
-##### 13.5接口文档
-##### 13.6实施意见：什么和为什么，而不是如何
-##### 13.7跨模块设计决策
-##### 13.8结论
-##### 13.9第13.5节中的问题答案
-#### 14选择名称
-##### 14.1示例：错误的名称会导致错误
-##### 14.2创建图像
-##### 14.3名称应该准确
-##### 14.4始终使用名称
-##### 14.5不同的意见：去风格指南
-##### 14.6结论
-
-#### 15首先写下评论
-##### 15.1延迟评论是不好的评论
-##### 15.2首先写下评论
-##### 15.3评论是一种设计工具
-##### 15.4早期评论是有趣的评论
-##### 15.5早期评论是否昂贵？
-##### 15.6结论
-
-#### 16修改现有代码
-##### 16.1保持战略性
-##### 16.2维护注释：将注释保留在代码附近
-##### 16.3注释属于代码，而不是提交日志
-##### 16.4维护评论：避免重复
-##### 16.5维护注释：检查差异
-##### 16.6更高级别的注释更容易维护
-
-#### 17一致性
-##### 17.1一致性的例子
-##### 17.2确保一致性
-##### 17.3太过分了
-##### 17.4结论
-
-#### 18代码应该是显而易见的
-##### 18.1使代码更加明显的事情
-##### 18.2使代码不那么明显的事情
-##### 18.3结论
-
-#### 19软件趋势
-##### 19.1面向对象的编程和继承
-##### 19.2敏捷开发
-##### 19.3单元测试
-##### 19.5设计模式
-##### 19.6吸气鬼和二传手
-##### 19.7结论
-
-#### 20性能设计
-##### 20.1如何考虑绩效
-##### 20.2修改前的测量
-##### 20.3围绕关键部分进行设计
-##### 20.4一个例子：RAMCloud缓冲区
-##### 20.5结论
-
-#### 21结论
-
-#### v指数
-
-#### 设计原则摘要
-
-#### 红旗总结
+在线阅读地址：
\ No newline at end of file
diff --git a/docs/.nojekyll b/docs/.nojekyll
new file mode 100644
index 0000000..e69de29
diff --git a/docs/Preface.md b/docs/Preface.md
new file mode 100644
index 0000000..cc7db58
--- /dev/null
+++ b/docs/Preface.md
@@ -0,0 +1,46 @@
+# 前言
+
+80 多年来，人们一直在为电子计算机编写程序，但令人惊讶的是，关于如何设计这些程序或什么是好的程序应该是什么样子的讨论却很少。关于软件开发过程(如敏
+捷开发)和开发工具(如调试器、版本控制系统和测试覆盖工具)，已经有了相当多的讨论。还广泛分析了编程技术，如面向对象编程和函数式编程，以及设计模式和算法。所有这些讨论都是有价值的，但是软件设计的核心问题在很大程度上仍然没有触及。David Parnas 的经典论文“关于将系统分解成模块的标准”发表于 1971 年，但是在随后的 45 年里，软件设计的技术水平并没有超过这篇论文。
+
+
+计算机科学中最基本的问题是问题分解：如何处理复杂的问题并将其分解为可以独立解决的部分。问题分解是程序员每天都要面对的中心设计任务，但是，除了这里描述的工作之外，我还无法在任何将问题分解作为中心主题的大学中确定一个班级。我们讲授循环和面向对象的程序设计，而不是软件设计。
+
+
+
+此外，程序员之间在质量和生产率上存在巨大差异，但是我们几乎没有尝试去了解什么使最好的程序员变得更好，或者在我们的课堂上教授这些技能。我曾与几位我认为是优秀的程序员的人进行过交谈，但是他们中的大多数人都难以阐明赋予他们优势的特定技术。许多人认为软件设计技能是天生的天赋，无法教授。但是，有相当多的科学证据表明，许多领域的杰出表现更多地与高质量的实践有关，而不是与先天能力有关（例如，参见 Geoff Colvin 的《人才被高估》）。
+
+
+
+多年来，这些问题使我感到困惑和沮丧。我想知道是否可以教授软件设计，并且我假设设计技巧是区分优秀程序员和普通程序员的原因。我最终决定，回答这些问题的唯一方法是尝试教授软件设计课程。结果是斯坦福大学的 CS 190。在这一节课中，我提出了一套软件设计原则。然后，学生将通过一系列项目来吸收和实践这些原理。该课程的授课方式类似于传统的英语写作课。在英语课堂上，学生使用迭代过程，在其中编写草稿，获取反馈，然后重写以进行改进。在 CS 190 中，学生从头开始开发大量软件。然后，我们将进行大量的代码审查以识别设计问题，然后学生修订其项目以解决问题。这使学生可以了解如何通过应用设计原理来改进其代码。
+
+
+
+现在，我已经教过 3 次软件设计课程，并且本书是基于该课程中出现的设计原理编写的。这些原则是相当高的水平，并且是哲学上的边界（“定义错误不再存在”），因此学生很难以抽象的方式理解这些思想。通过编写代码，犯错误，然后查看他们的错误以及后续的修正与这些原则之间的关系，学生将学得最好。
+
+
+在这一点上，您可能会想知道：是什么让我认为我知道有关软件设计的所有答案？老实说，我没有。当我学会编程时，没有关于软件设计的课程，而且我从来没有导师来教我设计原理。在我学习编程时，几乎没有代码审查。我对软件设计的想法来自于编写和阅读代码的个人经验。在我的职业生涯中，我已经用多种语言编写了大约 250,000 行代码。我曾在团队中工作过，这些团队从零开始创建了三个操作系统，多个文件和存储系统，基础结构工具（例如调试器，构建系统和 GUI 工具包），脚本语言以及用于文本，图形，演示文稿和集成电路的交互式编辑器。一路上，我亲身经历了大型系统的问题，并尝试了各种设计技术。另外，我已经阅读了很多其他人编写的代码，这使我接触到了很多方法，无论是好是坏。
+
+
+
+从所有这些经验中，我尝试提取通用线程，包括有关避免的错误和使用的技巧。本书反映了我的经验：这里描述的每个问题都是我亲身经历的，每种建议的技术都是我在自己的编码中成功使用的一种技术。
+
+
+
+我不希望这本书成为软件设计的定论。我敢肯定，我错过了一些有价值的技术，从长远来看，我的一些建议可能会变成坏主意。但是，我希望本书能开始有关软件设计的对话。将本书中的想法与您自己的经验进行比较，并自己决定此处介绍的方法是否确实降低了软件复杂性。这本书是一个观点，所以有些读者会不同意我的一些建议。如果您不同意，请尝试理解原因。我有兴趣了解对您有用的东西，不起作用的东西以及您可能对软件设计有任何其他想法。我希望随后的对话将增进我们对软件设计的集体理解。
+
+
+与我交流有关这本书的最好方法是将电子邮件发送到以下地址：software-design-book@googlegroups.com
+
+
+我有兴趣听取有关本书的特定反馈，例如错误或改进建议，以及与软件设计相关的一般思想和经验。我对可以在本书未来版本中使用的引人注目的示例特别感兴趣。最好的示例说明了重要的设计原理，并且足够简单，可以在一两个段落中进行解释。如果您想在电子邮件地址上看到其他人在说什么并参与讨论，可以加入 Google Group 软件设计手册。
+
+
+如果出于某种原因该软件设计手册 Google Group 将来会消失，请在 Web 上搜索我的主页；它将包含有关如何与这本书进行交流的更新说明。请不要将与图书相关的电子邮件发送到我的个人电子邮件地址。
+
+
+我建议您在本书中加些建议。总体目标是降低复杂性；这比您在此处阅读的任何特定原理或想法更为重要。如果您尝试从本书中获得一个想法并发现它实际上并没有降低复杂性，那么您就不必继续使用它（但是，请让我知道您的经验；我想获得有关有效方法的反馈意见而不是）。
+
+
+
+许多人提出了批评或提出建议，以提高本书的质量。以下人员对本书的各种草稿提供了有用的意见：杰夫·迪恩，桑杰·格玛瓦特，约翰·哈特曼，布莱恩·科尼根，詹姆斯·科佩尔，艾米·奥斯特豪特，凯·奥斯特豪特，罗伯·派克，帕塔·朗格纳森，基思·施瓦茨和亚历克斯·斯内普斯。Christos Kozyrakis 为类和接口建议了术语“深层”和“浅层”，代替了之前有点模糊的术语“厚”和“薄”。我很感激 CS 190 中的学生；阅读他们的代码并与他们讨论的过程有助于明确我对设计的想法。
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 0000000..a3cbd82
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,12 @@
+# A-Philosophy-of-Software-Design
+《软件设计哲学》
+
+## 目录
+
+#### [前言](./preface)
+
+#### [第一章：介绍](./ch1.md)
+
+
+#### [第二章：复杂性的本质](./ch2.md)
+
diff --git a/docs/_sidebar.md b/docs/_sidebar.md
new file mode 100644
index 0000000..2e0ae0e
--- /dev/null
+++ b/docs/_sidebar.md
@@ -0,0 +1,6 @@
+
+
+* [首页](/)
+* [前言](./Preface.md)
+* [第一章：介绍](./ch1.md)
+* [第二章：复杂性的本质](./ch2.md)
\ No newline at end of file
diff --git a/docs/ch1.md b/docs/ch1.md
new file mode 100644
index 0000000..d905a4a
--- /dev/null
+++ b/docs/ch1.md
@@ -0,0 +1,57 @@
+# 第一章：介绍
+
+编写计算机软件是人类历史上最纯粹的创作活动之一。程序员不受诸如物理定律等实际限制的约束。我们可以用现实世界中永远不会存在的行为创建令人兴奋的虚拟世界。编程不需要很高的身体技能或协调能力，例如芭蕾或篮球。所有编程都需要具有创造力的头脑和组织思想的能力。如果您可以可视化系统，则可以在计算机程
+序中实现它。
+
+
+这意味着编写软件的最大限制是我们了解所创建系统的能力。随着程序的发展和获得更多功能，它变得复杂，其组件之间具有微妙的依赖性。随着时间的流逝，复杂性不断累积，程序员在修改系统时将所有相关因素牢记在心中变得越来越难。这会减慢开发速度并导致错误，从而进一步延缓开发速度并增加成本。在任何程序的生命周期中，复杂性都会不可避免地增加。程序越大，工作的人越多，管理复杂性就越困难。
+
+
+好的开发工具可以帮助我们应对复杂性，并且在过去的几十年中已经创建了许多出色的工具。但是，仅凭工具我们只能做些事情。如果我们想简化编写软件的过程，从而可以更便宜地构建功能更强大的系统，则必须找到简化软件的方法。尽管我们尽了最大努力，但复杂度仍会随着时间的推移而增加，但是更简单的设计使我们能够在复杂性压倒性优势之前构建更大，功能更强大的系统。
+
+
+
+有两种解决复杂性的通用方法，这两种方法都将在本书中进行讨论。
+**第一种方法是通过使代码更简单和更明显来消除复杂性。例如，可以通过消除特殊情况或以一致的方式使用标识符来降低复杂性。**
+
+**解决复杂性的第二种方法是封装它，以便程序员可以在系统上工作而不会立即暴露其所有复杂性。这种方法称为模块化设计。在模块化设计中，软件系统分为模块，例如面向对象语言的类。这些模块被设计为彼此相对独立，以便程序员可以在一个模块上工作而不必了解其他模块的细节。**
+
+
+由于软件具有很好的延展性，因此软件设计是一个贯穿软件系统整个生命周期的连续过程。这使得软件设计与诸如建筑物，船舶或桥梁的物理系统的设计不同。但是，并非总是以这种方式查看软件设计。在编程的大部分历史中，设计都集中在项目的开始，就像其他工程学科一样。这种方法的极端称为瀑布模型，该模型将项目划分为离散的阶段，例如需求定义，设计，编码，测试和维护。在瀑布模型中，每个阶段都在下一阶段开始之前完成；在许多情况下，每个阶段都由不同的人负责。在设计阶段，立即设计整个系统。
+
+
+不幸的是，瀑布模型很少适用于软件。软件系统本质上比物理系统复杂。在构建任何东西之前，不可能充分可视化大型软件系统的设计，以了解其所有含义。结果，初始设计将有许多问题。在实施良好之前，问题不会变得明显。但是，瀑布模型的结构此时无法适应主要的设计更改（例如，设计师可能已转移到其他项目）。因此，开发人员尝试在不改变整体设计的情况下解决问题。这导致复杂性的爆炸式增长。
+
+
+由于这些问题，当今大多数软件开发项目都使用诸如敏捷开发之类的增量方法，其中初始设计着重于整体功能的一小部分。设计，实施和评估此子集。发现和纠正原始设计的问题，然后设计，实施和评估更多功能。每次迭代都会暴露现有设计的问题，这些问题在设计下一组功能之前就已得到解决。通过以这种方式扩展设计，可以在系统仍然很小的情况下解决初始设计的问题。较新的功能受益于较早功能的实施过程中获得的经验，因此问题较少。
+
+
+增量方法适用于软件，因为软件具有足够的延展性，可以在实施过程中进行重大的设计更改。相比之下，对物理系统而言，主要的设计更改更具挑战性：例如，在建筑过程中更改支撑桥梁的塔架数量不切实际。
+
+增量开发意味着永远不会完成软件设计。设计在系统的整个生命周期中不断发生：开发人员应始终在思考设计问题。增量开发还意味着不断的重新设计。系统或组件的初始设计几乎从来都不是最好的。经验不可避免地显示出更好的做事方式。作为软件开发人员，您应该始终在寻找机会来改进正在开发的系统的设计，并且应该计划将部分时间花费在设计改进上。
+
+
+如果软件开发人员应始终考虑设计问题，而降低复杂性是软件设计中最重要的要素，则软件开发人员应始终考虑复杂性。**这本书是关于如何使用复杂性来指导软件设计的整个生命周期。**
+
+这本书有两个总体目标。**首先是描述软件复杂性的性质：“复杂性”是什么意思，为什么重要，以及当程序具有不必要的复杂性时如何识别？本书的第二个也是更具挑战性的目标是介绍可在软件开发过程中使用的技术，以最大程度地减少复杂性。**不幸的是，没有简单的方法可以保证出色的软件设计。取而代之的是，我将提出一些与哲学紧密相关的高级概念，例如“类应该很深”或“定义不存在的错误”。这些概念可能不会立即确定最佳设计，但您可以使用它们来比较设计备选方案并指导您探索设计空间。
+
+## 1.1 How to use this book 如何使用这本书
+
+
+
+这里描述的许多设计原则有些抽象，因此如果不看实际的代码，可能很难理解它们。找到足够小的示例以包含在书中，但是又足够大以说明真实系统的问题是一个挑战（如果遇到好的示例，请发给我）。因此，这本书可能不足以让您学习如何应用这些原理。
+
+
+
+使用本书的最佳方法是与代码审查结合使用。阅读其他人的代码时，请考虑它是否符合此处讨论的概念，以及它与代码的复杂性之间的关系。在别人的代码中比在您的代码中更容易看到设计问题。您可以使用此处描述的红色标记来发现问题并提出改进建议。查看代码还将使您接触到新的设计方法和编程技术。
+
+
+改善设计技能的最好方法之一就是学会识别危险信号：信号表明一段代码可能比需要的复杂。在本书的过程中，我将指出一些危险信号，这些危险信号指示与每个主要设计问题有关的问题；最重要的内容总结在书的后面。然后，您可以在编码时使用它们：当看到红色标记时，停下来寻找可消除问题的替代设计。当您第一次尝试这种方法时，您可能必须尝试几种设计替代方案，然后才能找到消除危险信号的方案。不要轻易放弃：解决问题之前尝试的替代方法越多，您就会学到更多。随着时间的流逝，您会发现代码中的危险信号越来越少，并且您的设计越来越清晰。
+
+在应用本书中的思想时，务必要节制和谨慎。每条规则都有例外，每条原则都有其局限性。如果您将任何设计创意都发挥到极致，那么您可能会陷入困境。精美的设计反映了相互竞争的思想和方法之间的平衡。有几章的标题为“太过分”，它们描述了如何在做得过大的事情上识别自己。
+
+
+本书中几乎所有示例都是使用 Java 或 C ++编写的，并且大部分讨论都是针对以面向对象的语言设计类的。但是，这些想法也适用于其他领域。几乎所有与方法有关的思想也可以应用于没有面向对象功能的语言中的功能，例如 C。设计思想还适用于除类之外的模块，例如子系统或网络服务。
+
+
+在这种背景下，让我们详细讨论导致复杂性的原因以及如何简化软件系统。
\ No newline at end of file
diff --git a/docs/ch2.md b/docs/ch2.md
new file mode 100644
index 0000000..e69de29
diff --git a/docs/index.html b/docs/index.html
new file mode 100644
index 0000000..8302d10
--- /dev/null
+++ b/docs/index.html
@@ -0,0 +1,22 @@
+
+
+
+
+ Document
+
+
+
+
+
+
+
+
+
+
+
diff --git a/前言/index.md b/前言/index.md
deleted file mode 100644
index 02b3c82..0000000
--- a/前言/index.md
+++ /dev/null
@@ -1,24 +0,0 @@
-80多年来，人们一直在为电子计算机编写程序，但关于如何设计这些程序或者应该是什么样的好程序的讨论却令人惊讶。关于软件开发过程（如敏捷开发）和开发工具（如调试器，版本控制系统和测试覆盖率工具）的讨论已经有了很多。还对编程技术进行了广泛的分析，例如面向对象编程和函数编程，以及设计模式和算法。所有这些讨论都很有价值，但软件设计的核心问题仍然基本上没有受到影响。 David Parnas的经典论文“关于将系统分解为模块的标准”出现于1971年，但在随后的45年中，软件设计的最新进展并未超过该论文。
-
-计算机科学中最基本的问题是问题分解：如何解决复杂问题并将其分解为可以独立解决的问题。问题分解是程序员每天面临的中心设计任务，然而，除了这里描述的工作之外，我还没有能够在任何大学中识别出问题分解是一个中心主题的单一课程。我们教授循环和面向对象的编程，但不教授软件设计。
-
-此外，程序员在质量和生产力方面存在巨大差异，但我们很少尝试理解是什么让最好的程序员变得更好或者在我们的课程中教授这些技能。我和几个我认为很棒的人交谈过
-程序员，但他们中的大多数都难以阐明能够为他们提供优势的特定技术。许多人认为软件设计技能是一种无法教授的天赋。然而，有相当多的科学证据表明，许多领域的杰出表现更多地与高质量的实践相关而不是天生的能力（例如，参见Geoff被Geoff Colvin高估）。
-
-多年来，这些问题让我感到困惑和沮丧。我想知道是否可以教授软件设计，我假设设计技巧是伟大的程序员与普通程序员的区别。我终于决定回答这些问题的唯一方法是尝试教授软件设计课程。结果是斯坦福大学的CS 190。在本课程中，我提出了一套软件设计原则。然后学生通过一系列项目来吸收和实践这些原则。课程的教学方式类似于传统的英语写作课程。在英语课上，学生使用迭代过程，他们写一个草稿，获得反馈，然后重写以进行改进。在CS 190中，学生从头开始开发大量软件。然后，我们通过广泛的代码审查来识别设计问题，学生修改他们的项目来解决问题。这样，学生可以通过应用设计原则来了解如何改进代码。
-
-我现在已经三次教授软件设计课程，本书基于课堂上出现的设计原则。这些原则在哲学上是相当高的水平和边界（“定义错误不存在”），因此学生很难理解抽象中的思想。学生通过编写代码，犯错误，然后了解他们的错误以及随后的修复如何与原则相关来学习。
-
-在这一点上你可能会想知道：是什么让我觉得我知道关于软件设计的所有答案？说实话，我没有。当我学习编程时，没有关于软件设计的课程，我从来没有一个导师教我设计原则。在我学习编程的时候，代码评审实际上是不存在的。我对软件设计的看法来自于编写和阅读代码的个人经验。在我的职业生涯中，我用各种语言编写了大约250,000行代码。我从事过从头开始创建三个操作系统，多个文件和存储系统，基础设施工具（如调试器，构建系统和GUI工具包），脚本语言以及用于文本，绘图，演示和集成电路的交互式编辑器的团队。在此过程中，我亲身体验了大型系统的问题，并尝试了各种设计技术。另外，我读过很多其他人编写的代码，这让我接触到各种各样的方法，包括好的和坏的。
-在所有这些经验中，我试图提取共同的线程，包括要避免的错误和使用的技术。这本书反映了我的经历：这里描述的每一个问题都是我个人经历的问题，每一个建议的技术都是我在自己的编码中成功使用的技术。
-
-我不希望这本书成为软件设计的最后一句话;我确信我错过了一些有价值的技术，从长远来看，我的一些建议可能会成为糟糕的想法。但是，我希望本书能够开始讨论软件设计。将本书中的想法与您自己的经验进行比较，并自己决定这里描述的方法是否确实降低了软件的复杂性。这本书是一篇评论文章，所以有些读者会不同意我的一些建议。如果你不同意，试着理解为什么。我很想知道对你有用的东西，不起作用的东西，以及你对软件设计可能有的任何其他想法。我希望随后的对话能够提高我们对软件设计的集体理解。我将在本书的未来版本中加入我学到的内容。
-
-与我沟通有关本书的最佳方式是发送电子邮件至以下地址：
-`software-design-book@googlegroups.com`
-
-我很想听听有关本书的具体反馈，例如错误或改进建议，以及与软件设计相关的一般想法和经验。我特别感兴趣的是我可以在本书的未来版本中使用的引人注目的例子。最好的例子说明了一个重要的设计原则，并且很简单，可以用一两段来解释。如果您想查看其他人在电子邮件地址上发表的言论并参与讨论，您可以加入Google Group软件设计手册。
-
-如果出于某种原因，软件设计书Google Group将来会消失，请在Web上搜索我的主页; 它将包含有关如何沟通书籍的更新说明。 请勿将与图书相关的电子邮件发送到我的个人电子邮件地址。
-我建议你尽量采用本书中的建议。 总体目标是降低复杂性; 这比你在这里阅读的任何特定原则或想法更重要。 如果您尝试从本书中获得一个想法并发现它实际上并没有降低复杂性，那么就不要觉得有必要继续使用它（但是，请让我知道您的体验;我想获得有关哪些有效的反馈 什么不是。
-许多人提出批评或提出改善书籍质量的建议。 以下人员对各种草稿提出了有益的评论...