前言

README.md

@@ -1 +1,165 @@
-# 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指数
+
+#### 设计原则摘要
+#### 红旗总结

前言/index.md

@@ -0,0 +1,24 @@
+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上搜索我的主页; 它将包含有关如何沟通书籍的更新说明。 请勿将与图书相关的电子邮件发送到我的个人电子邮件地址。
+我建议你尽量采用本书中的建议。 总体目标是降低复杂性; 这比你在这里阅读的任何特定原则或想法更重要。 如果您尝试从本书中获得一个想法并发现它实际上并没有降低复杂性，那么就不要觉得有必要继续使用它（但是，请让我知道您的体验;我想获得有关哪些有效的反馈 什么不是。
+许多人提出批评或提出改善书籍质量的建议。 以下人员对各种草稿提出了有益的评论...