×
思维导图备注
软件设计的哲学
首页
小程序
下载
阅读记录
书签管理
我的书签
添加书签
移除书签
编辑文档
第 14 章 选择的名字
来源 1
浏览
702
扫码
分享
2020-10-20 22:11:14
第 14 章 选择的名字
上一篇:
下一篇:
第 1 章 介绍
1.1 How to use this book 如何使用这本书
第 10 章 定义不存在的错误
10.1 Why exceptions add complexity 为什么异常会增加复杂性
10.10 Taking it too far 走得太远
10.11 Conclusion 结论
10.2 Too many exceptions 异常过多
10.3 Define errors out of existence 定义错误不存在
10.4 Example: file deletion in Windows 示例:Windows 中的文件删除
10.5 Example: Java substring method 示例:Java 子字符串方法
10.6 Mask exceptions 掩码异常
10.7 Exception aggregation 异常聚集
10.8 Just crash? 崩溃了吗?
10.9 Design special cases out of existence 设计特殊情况不存在
第 11 章 设计它两次
第 12 章 为什么写注释?四个理由
12.1 Good code is self-documenting 好的代码可以自我记录
12.2 I don’t have time to write comments 我没有时间写注释
12.3 Comments get out of date and become misleading 注释过时并产生误导
12.4 All the comments I have seen are worthless 我所看到的所有注释都是毫无价值的
12.5 Benefits of well-written comments
第 13 章 注释应该描述代码中不明显的内容
13.1 Pick conventions 选择约定
13.2 Don’t repeat the code 不要重复代码
13.3 Lower-level comments add precision 低级注释可提高精度
13.4 Higher-level comments enhance intuition 高级注释可增强直觉
13.5 Interface documentation 接口文档
13.6 Implementation comments: what and why, not how 实现注释:什么以及为什么,而不是如何
13.7 Cross-module design decisions 跨模块设计决策
13.8 Conclusion 结论
13.9 Answers to questions from Section 13.5 回答第 13.5 节中的问题
第 14 章 选择的名字
14.1 Example: bad names cause bugs 示例:名称错误会导致错误
14.2 Create an image 创建图像
14.3 Names should be precise 名称应准确
14.4 Use names consistently 一致使用名称
14.5 A different opinion: Go style guide 不同的意见:Go 样式指南
14.6 Conclusion 结论
第 15 章 先写注释
15.1 Delayed comments are bad comments 迟到的注释不是好注释
15.2 Write the comments first 首先写注释
15.3 Comments are a design tool 注释是一种设计工具
15.4 Early comments are fun comments 早期注释很有趣
15.5 Are early comments expensive? 早期注释是否昂贵?
15.6 Conclusion 结论
第 16 章 修改现有的代码
16.1 Stay strategic 保持战略
16.2 Maintaining comments: keep the comments near the code 维护注释:将注释保留在代码附近
16.3 Comments belong in the code, not the commit log 注释属于代码,而不是提交日志
16.4 Maintaining comments: avoid duplication 维护注释:避免重复
16.5 Maintaining comments: check the diffs 维护注释:检查差异
16.6 Higher-level comments are easier to maintain 更高级的注释更易于维护
第 17 章 一致性
17.1 Examples of consistency 一致性示例
17.2 Ensuring consistency 确保一致性
17.3 Taking it too far 走得太远
17.4 Conclusion 结论
第 18 章 代码应该是显而易见的
18.1 Things that make code more obvious
18.2 Things that make code less obvious 使代码不那么明显的事情
18.3 Conclusion 结论
第 19 章 软件发展趋势
19.1 Object-oriented programming and inheritance 面向对象的编程和继承
19.2 Agile development 敏捷开发
19.3 Unit tests 单元测试
19.4 Test-driven development 测试驱动的开发
19.5 Design patterns 设计模式
19.6 Getters and setters Getter 和 Setters
19.7 Conclusion 结论
第 2 章 复杂性的本质
2.1 Complexity defined 复杂性的定义
2.2 Symptoms of complexity 复杂性的症状
2.3 Causes of complexity 复杂性的原因
2.4 Complexity is incremental 复杂度是递增的
2.5 Conclusion 结论
第 20 章 设计性能
20.1 How to think about performance 如何考虑性能
20.2 Measure before modifying 修改前的度量
20.3 Design around the critical path 围绕关键路径进行设计
20.4 An example: RAMCloud Buffers 示例:RAMCloud 缓冲区
20.5 Conclusion 结论
第 21 章 结论
第 3 章 工作代码是不够的
3.1 Tactical programming 战术编程
3.2 Strategic programming 战略规划
3.3 How much to invest? 投资多少?
3.4 Startups and investment 创业与投资
3.5 Conclusion 结论
第 4 章 模块应该是深的
4.1 Modular design 模块化设计
4.2 What’s in an interface? 接口中有什么?
4.3 Abstractions 抽象
4.4 Deep modules 深度模块
4.5 Shallow modules 浅模块
4.6 Classitis
4.7 Examples: Java and Unix I/O 示例:Java 和 Unix I/O
4.8 Conclusion 结论
第 5 章 信息隐藏(和泄漏)
5.1 Information hiding 信息隐藏
5.10 Conclusion 结论
5.2 Information leakage 信息泄漏
5.3 Temporal decomposition 时间分解
5.4 Example: HTTP server 示例:HTTP 服务器
5.5 Example: too many classes 示例:太多的类
5.6 Example: HTTP parameter handling 示例:HTTP 参数处理
5.7 Example: defaults in HTTP responses 示例:HTTP 响应中的默认值
5.8 Information hiding within a class 信息隐藏在类中
5.9 Taking it too far 走得太远
第 6 章 通用模块更深入
6.1 Make classes somewhat general-purpose 使类变得通用
6.2 Example: storing text for an editor 示例:为编辑器存储文本
6.3 A more general-purpose API 更通用的 API
6.4 Generality leads to better information hiding 通用性可以更好地隐藏信息
6.5 Questions to ask yourself 问自己的问题
6.6 Conclusion 结论
第 7 章 不同的层,不同的抽象
7.1 Pass-through methods 直通方法
7.2 When is interface duplication OK? 接口复制何时可以?
7.3 Decorators 装饰器
7.4 Interface versus implementation 接口与实现
7.5 Pass-through variables 传递变量
7.6 Conclusion 结论
第 8 章 降低复杂性
8.1 Example: editor text class 示例:编辑器文本类
8.2 Example: configuration parameters 示例:配置参数
8.3 Taking it too far 走得太远
8.4 Conclusion 结论
第 9 章 在一起更好还是分开更好?
9.1 Bring together if information is shared 如果信息共享则汇聚在一起
9.2 Bring together if it will simplify the interface 汇集在一起 是否可以简化接口
9.3 Bring together to eliminate duplication 消除重复
9.4 Separate general-purpose and special-purpose code 单独的通用代码和专用代码
9.5 Example: insertion cursor and selection 示例:插入光标和选择
9.6 Example: separate class for logging 示例:用于记录的单独类
9.7 Example: editor undo mechanism 示例:编辑器撤消机制
9.8 Splitting and joining methods 拆分和合并方法
9.9 Conclusion 结论
前言
目录
总结
《软件设计的哲学》中文翻译
暂无相关搜索结果!
本文档使用
BookStack
构建
×
分享,让知识传承更久远
×
文章二维码
手机扫一扫,轻松掌上读
×
文档下载
请下载您需要的格式的文档,随时随地,享受汲取知识的乐趣!
PDF
文档
EPUB
文档
MOBI
文档
×
微信小程序阅读
微信扫一扫,知识掌上学
×
书签列表
×
阅读记录
阅读进度:
0.00%
(
0/0
)
重置阅读进度