Update README.md

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