1个示例，7次重构，助你辨别优劣代码。
电子书
编辑推荐
本书分享的实用技巧可以帮助你编写可靠且易于团队成员理解和适应不断变化需求的代码。
内容简介
本书分享的实用技巧可以帮助你编写鲁棒、可靠且易于团队成员理解和适应不断变化需求的代码。内容涉及如何像高效的软件工程师一样思考代码，如何编写读起来像一个结构良好的句子的函数，如何确保代码可靠且无错误，如何进行有效的单元测试，如何识别可能导致问题的代码并对其进行改进，如何编写可重用并适应新需求的代码，如何提高读者的中长期生产力，同时还介绍了如何节省开发人员及团队的宝贵时间，等等。
章节目录
- fy
- 内容提要
- 序言
- 前言
- 作者简介
- 封面简介
- 资源与支持
- 目录
- 第一部分 理论
- 第1章 代码质量
- 1.1代码如何变成软件
- 1.2代码质量目标
- 1.2.1 代码应该正常工作
- 1.2.2 代码应该持续正常工作
- 1.2.3 代码应该适应不断变化的需求
- 1.2.4 代码不应该重复别人做过的工作
- 1.3代码质量的支柱
- 1.3.1 编写易于理解的代码
- 1.3.2 避免意外
- 1.3.3 编写难以误用的代码
- 1.3.4 编写模块化的代码
- 1.3.5 编写可重用、可推广的代码
- 1.3.6 编写可测试的代码并适当测试
- 1.4编写高质量代码是否会拖慢进度
- 1.5小结
- 第2章 抽象层次
- 2.1空值和本书中的伪代码惯例
- 2.2为什么要创建抽象层次
- 2.3代码层次
- 2.3.1 API 和实现细节
- 2.3.2 函数
- 2.3.3 类
- 2.3.4 接口
- 2.3.5 当层次太薄的时候
- 2.4微服务简介
- 2.5小结
- 第3章 其他工程师与代码契约
- 3.1你的代码和其他工程师的代码
- 3.1.1 对你来说显而易见，但对其他人并不清晰的事情
- 3.1.2 其他工程师无意间试图破坏你的代码
- 3.1.3 过段时间，你会忘记自己的代码的相关情况
- 3.2其他人如何领会你的代码的使用方法
- 3.2.1 查看代码元素的名称
- 3.2.2 查看代码元素的数据类型
- 3.2.3 阅读文档
- 3.2.4 亲自询问
- 3.2.5 查看你的代码
- 3.3代码契约
- 3.3.1 契约的附属细则
- 3.3.2 不要过分依赖附属细则
- 3.4检查和断言
- 3.4.1 检查
- 3.4.2 断言
- 3.5小结
- 第4章 错误
- 4.1可恢复性
- 4.1.1 可以从中恢复的错误
- 4.1.2 无法从中恢复的错误
- 4.1.3 只有调用者知道能否从某种错误中恢复
- 4.1.4 让调用者意识到他们可能想从中恢复的错误
- 4.2鲁棒性与故障
- 4.2.1 快速失败
- 4.2.2 大声失败
- 4.2.3 可恢复性的范围
- 4.2.4 不要隐藏错误
- 4.3错误报告方式
- 4.3.1 回顾：异常
- 4.3.2 显式：受检异常
- 4.3.3 隐式：非受检异常
- 4.3.4 显式：允许为空的返回类型
- 4.3.5 显式：结果返回类型
- 4.3.6 显式：操作结果返回类型
- 4.3.7 隐式：承诺/未来
- 4.3.8 隐式：返回“魔法值”
- 4.4报告不可恢复的错误
- 4.5报告调用者可能想要从中恢复的错误
- 4.5.1 使用非受检异常的论据
- 4.5.2 使用显式报错技术的论据
- 4.5.3 我的观点：使用显式报错技术
- 4.6不要忽视编译器警告
- 4.7小结
- 第二部分 实践
- 第5章 编写易于理解的代码
- 5.1使用描述性名称
- 5.1.1 非描述性名称使代码难以理解
- 5.1.2 用注释代替描述性名称是很不好的做法
- 5.1.3 解决方案：使名称具有描述性
- 5.2适当使用注释
- 5.2.1 多余的注释可能有害
- 5.2.2 注释不是可读代码的合格替代品
- 5.2.3 注释可能很适合于解释代码存在的理由
- 5.2.4 注释可以提供有用的高层概述
- 5.3不要执着于代码行数
- 5.3.1 避免简短但难以理解的代码
- 5.3.2 解决方案：编写易于理解的代码，即便需要更多行代码
- 5.4坚持一致的编程风格
- 5.4.1 不一致的编程风格可能引发混乱
- 5.4.2 解决方案：采纳和遵循风格指南
- 5.5避免深嵌套代码
- 5.5.1 嵌套很深的代码可能难以理解
- 5.5.2 解决方案：改变结构，昀大限度地减少嵌套
- 5.5.3 嵌套往往是功能过多的结果
- 5.5.4 解决方案：将代码分解为更小的函数
- 5.6使函数调用易于理解
- 5.6.1 参数可能难以理解
- 5.6.2 解决方案：使用命名参数
- 5.6.3 解决方案：使用描述性类型
- 5.6.4 有时没有很好的解决方案
- 5.6.5 IDE又怎么样呢
- 5.7避免使用未做解释的值
- 5.7.1 未做解释的值可能令人困惑
- 5.7.2 解决方案：使用恰当命名的常量
- 5.7.3 解决方案：使用恰当命名的函数
- 5.8正确使用匿名函数
- 5.8.1 匿名函数适合于小的事物
- 5.8.2 匿名函数可能导致代码难以理解
- 5.8.3 解决方案：用命名函数代替
- 5.8.4 大的匿名函数可能造成问题
- 5.8.5 解决方案：将大的匿名函数分解为命名函数
- 5.9正确使用新奇的编程语言特性
- 5.9.1 新特性可能改善代码
- 5.9.2 不为人知的特性可能引起混乱
- 5.9.3 使用适合于工作的工具
- 5.10小结
- 第6章 避免意外
- 6.1避免返回魔法值
- 6.1.1 魔法值可能造成缺陷
- 6.1.2 解决方案：返回空值、可选值或者错误
- 6.1.3 魔法值可能偶然出现
- 6.2正确使用空对象模式
- 6.2.1 返回空集可能改进代码
- 6.2.2 返回空字符串有时可能造成问题
- 6.2.3 较复杂的空对象可能造成意外
- 6.2.4 空对象实现可能造成意外
- 6.3避免造成意料之外的副作用
- 6.3.1 明显、有意的副作用没有问题
- 6.3.2 意料之外的副作用可能造成问题
- 6.3.3 解决方案：避免副作用或者使其显而易见
- 6.4谨防输入参数突变
- 6.4.1 输入参数突变可能导致程序缺陷
- 6.4.2 解决方案：在突变之前复制
- 6.5避免编写误导性的函数
- 6.5.1 在关键输入缺失时什么都不做可能造成意外
- 6.5.2 解决方案：将关键输入变成必要的输入
- 6.6永不过时的枚举处理
- 6.6.1 隐式处理未来的枚举值可能造成问题
- 6.6.2 解决方案：使用全面的 switch 语句
- 6.6.3 注意默认情况
- 6.6.4 注意事项：依赖另一个项目的枚举类型
- 6.7我们不能只用测试解决所有此类问题吗
- 6.8小结
- 第7章 编写难以被误用的代码
- 7.1考虑不可变对象
- 7.1.1 可变类可能很容易被误用
- 7.1.2 解决方案：只在构建时设值
- 7.1.3 解决方案：使用不可变性设计模式
- 7.2考虑实现深度不可变性
- 7.2.1 深度可变性可能导致误用
- 7.2.2 解决方案：防御性复制
- 7.2.3 解决方案：使用不可变数据结构
- 7.3避免过于通用的类型
- 7.3.1 过于通用的类型可能被误用
- 7.3.2 配对类型很容易被误用
- 7.3.3 解决方案：使用专用类型
- 7.4处理时间
- 7.4.1 用整数表示时间可能带来问题
- 7.4.2 解决方案：使用合适的数据结构表示时间
- 7.5拥有单一可信数据源
- 7.5.1 第二个可信数据源可能导致无效状态
- 7.5.2 解决方案：使用原始数据作为单一可信数据源
- 7.6拥有单一可信逻辑来源
- 7.6.1 多个可信逻辑来源可能导致程序缺陷
- 7.6.2 解决方案：使用单一可信来源
- 7.7小结
- 第8章 实现代码模块化
- 8.1考虑使用依赖注入
- 8.1.1 硬编程的依赖项可能造成问题
- 8.1.2 解决方案：使用依赖注入
- 8.1.3 在设计代码时考虑依赖注入
- 8.2倾向于依赖接口
- 8.2.1 依赖于具体实现将限制适应性
- 8.2.2 解决方案：尽可能依赖于接口
- 8.3注意类的继承
- 8.3.1 类继承可能造成问题
- 8.3.2 解决方案：使用组合
- 8.3.3 真正的“is-a”关系该怎么办
- 8.4类应该只关心自身
- 8.4.1 过于关心其他类可能造成问题
- 8.4.2 解决方案：使类仅关心自身
- 8.5将相关联的数据封装在一起
- 8.5.1 未封装的数据可能难以处理
- 8.5.2 解决方案：将相关数据组合为对象或类
- 8.6防止在返回类型中泄露实现细节
- 8.6.1 在返回类型中泄露实现细节可能造成问题
- 8.6.2 解决方案：返回对应于抽象层次的类型
- 8.7防止在异常中泄露实现细节
- 8.7.1 在异常中泄露实现细节可能造成问题
- 8.7.2 解决方案：使异常适合抽象层次
- 8.8小结
- 第9章 编写可重用、可推广的代码
- 9.1注意各种假设
- 9.1.1 代码重用时假设将导致缺陷
- 9.1.2 解决方案：避免不必要的假设
- 9.1.3 解决方案：如果假设是必要的，则强制实施
- 9.2注意全局状态
- 9.2.1 全局状态可能使重用变得不安全
- 9.2.2 解决方案：依赖注入共享状态
- 9.3恰当地使用默认返回值
- 9.3.1 低层次代码中的默认返回值可能损害可重用性
- 9.3.2 解决方案：在较高层次代码中使用默认值
- 9.4保持函数参数的集中度
- 9.4.1 如果函数参数超出需要，可能难以重用
- 9.4.2 解决方案：让函数只取得需要的参数
- 9.5考虑使用泛型
- 9.5.1 依赖于特定类型将限制可推广性
- 9.5.2 解决方案：使用泛型
- 9.6小结
- 第三部分 单元测试
- 第10章 单元测试原则
- 10.1单元测试入门
- 10.2是什么造就好的单元测试
- 10.2.1 准确检测破坏
- 10.2.2 与实现细节无关
- 10.2.3 充分解释失败
- 10.2.4 易于理解的测试代码
- 10.2.5 便捷运行
- 10.3专注于公共API，但不要忽略重要的行为
- 10.4测试替身
- 10.4.1 使用测试替身的理由
- 10.4.2 模拟对象
- 10.4.3 桩
- 10.4.4 模拟对象和桩可能有问题
- 10.4.5 伪造对象
- 10.4.6 关于模拟对象的不同学派
- 10.5挑选测试思想
- 10.6小结
- 第11章 单元测试实践
- 11.1测试行为，而不仅仅是函数
- 11.1.1 每个函数一个测试用例往往是不够的
- 11.1.2 解决方案：专注于测试每个行为
- 11.2避免仅为了测试而使所有细节可见
- 11.2.1 测试私有函数往往是个坏主意
- 11.2.2 解决方案：首选通过公共 API 测试
- 11.2.3 解决方案：将代码分解为较小的单元
- 11.3一次测试一个行为
- 11.3.1 一次测试多个行为可能导致降低测试质量
- 11.3.2 解决方案：以单独的测试用例测试每个行为
- 11.3.3 参数化测试
- 11.4恰当地使用共享测试配置
- 11.4.1 共享状态可能带来问题
- 11.4.2 解决方案：避免共享状态或者重置状态
- 11.4.3 共享配置可能带来问题
- 11.4.4 解决方案：在测试用例中定义重要配置
- 11.4.5 何时适用共享配置
- 11.5使用合适的断言匹配器
- 11.5.1 不合适的匹配器可能导致无法充分解释失败
- 11.5.2 解决方案：使用合适的匹配器
- 11.6使用依赖注入来提高可测试性
- 11.6.1 硬编程的依赖项可能导致代码无法测试
- 11.6.2 解决方案：使用依赖注入
- 11.7关于测试的一些结论
- 11.8小结
- 附录A巧克力糕饼食谱
- 附录B空值安全与可选类型
- B.1使用空值安全
- B.2使用可选类型
- 附录C额外的代码示例
展开全部
好代码，坏代码是2022年由人民邮电出版社出版,作者[英] 汤姆·朗。
版权说明：本电子书已获得正版授权，由出版社通过知传链发行。
得书感谢您对《好代码，坏代码》关注和支持，如本书内容有不良信息或侵权等情形的，请联系本网站。
电子书
1个示例，7次重构，助你辨别优劣代码。
电子书
Java代码审计初学者指南，系统介绍Java代码安全审计入门技术。
电子书
本书基于NumPy与sklearn，介绍26个主流机器学习算法的实现。
电子书
16个有趣的编程项目，提升Python编程技能，培养解决现实问题的思维。
电子书
本书详解Android开发知识，基于Android10.0、Kotlin编写，适合初学者和进阶开发者。
电子书
Java基础知识、面向对象、多线程、编程技巧、类库。