思维导图备注

软件设计的哲学

首页

小程序下载阅读记录

我的书签
添加书签移除书签

编辑文档

第 3 章工作代码是不够的

来源 1 浏览 968 扫码分享 2020-10-20 22:09:58

第 3 章工作代码是不够的

上一篇:

下一篇:

第 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文档

微信小程序阅读

BookChat 微信小程序阅读

微信扫一扫，知识掌上学

书签列表

阅读记录

阅读进度: 0.00% ( 0/0 ) 重置阅读进度