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