更新时间:2024-12-12 17:55:02
封面
版权信息
版权
内容提要
献词
前言
致谢
本书介绍
本书面向的读者
本书的组织结构
关于本书的代码
作者介绍
托马斯·莱莱克(Tomasz Lelek)
乔恩·斯基特(Jon Skeet)
本书封面插图介绍
资源与支持
资源获取
提交勘误信息
与我们联系
关于异步社区和异步图书
第1章 引言
1.1 决策的后果与模式
1.1.1 单元测试
1.1.2 单元测试与集成测试的比例
1.2 设计模式及其失效分析
度量代码
1.3 架构设计模式及其失效分析
1.3.1 可扩展性与弹性
1.3.2 开发速度
1.3.3 微服务的复杂性
小结
第2章 代码重复不一定是坏事:代码重复与灵活性的权衡
2.1 代码库间的通用代码及重复代码
2.1.1 添加新需求导致的代码重复
2.1.2 实现新的业务需求
2.1.3 结果评估
2.2 通过库在代码库之间共享代码
2.2.1 共享库的取舍与不足
2.2.2 创建共享库
2.3 抽取代码为一个独立的微服务
2.3.1 采用独立微服务方式的取舍与弊端
2.3.2 关于独立微服务的总结
2.4 通过代码重复改善松耦合
2.5 利用继承减少API设计中的重复
2.5.1 抽取出一个请求处理器作为基类
2.5.2 继承与紧耦合的取舍
2.5.3 继承与组合的取舍
2.5.4 一贯性的重复与偶然性的重复
第3章 异常及其他——代码错误的处理模式
3.1 异常的层次结构
捕获所有异常vs更细粒度的错误处理方案
3.2 代码异常处理的最佳模式
3.2.1 公共API的已检测异常处理
3.2.2 公共API的未检测异常处理
3.3 异常处理的反模式
3.3.1 异常时,关闭资源
3.3.2 反模式:利用异常控制应用流
3.4 源自第三方库的异常
3.5 多线程环境中的异常
使用promise API处理异步工作流中的异常
3.6 使用Try以函数式的途径处理异常
3.6.1 在生产代码中使用Try
3.6.2 混合使用Try与抛出异常的代码
3.7 异常处理策略的性能对比
第4章 灵活性与复杂性的权衡
4.1 一个健壮但无法扩展的API
4.1.1 设计一个新组件
4.1.2 从最简单的代码开始
4.2 允许客户使用自己的指标框架
4.3 通过钩子为你的API提供可扩展性
4.3.1 防范钩子API的过度使用
4.3.2 钩子API的性能影响
4.4 通过侦听器为你的API提供可扩展性
4.4.1 使用侦听器与钩子的取舍
4.4.2 设计的不可修改性
4.5 API的灵活性分析及维护开销的权衡
第5章 过早优化vs热路径优化:影响代码性能的决策
5.1 过早优化是万恶之源
5.1.1 构建账户处理管道
5.1.2 依据错误的假设进行优化处理
5.1.3 对性能优化进行基准测试
5.2 代码中的热路径
5.2.1 从软件系统的角度理解帕累托法则
5.2.2 依据SLA配置线程(并发用户)数
5.3 具有潜在热路径的单词服务
5.3.1 获取每日一词
5.3.2 验证单词是否存在
5.3.3 使用HTTP服务,向外提供单词服务
5.4 检测代码中的热路径
5.4.1 使用Gatling创建API的性能测试
5.4.2 使用MetricRegistry度量代码路径
5.5 改进热路径的性能
5.5.1 为现有代码创建JMH基准测试
5.5.2 利用缓存优化word-exists程序
5.5.3 调整性能测试,使用更多的输入单词
第6章 API的简洁性vs维护成本