新書推薦：
《
改变世界的哲学家们
》
售價：HK$
105.6
《
将军
》
售價：HK$
57.6
《
墓志的生成及其在唐代的衍变研究
》
售價：HK$
117.6
《
理解中国经济：在大变局中读懂新机遇
》
售價：HK$
54.0
《
饥饿与国家：苏丹的饥荒、奴隶制和权力（1883~1956）
》
售價：HK$
82.8
《
管好你的钱：人人都要懂的财富传承（一本书带你了解财富传承的7种方式）
》
售價：HK$
81.6
《
新质生产力：中国创新发展的着力点与内在逻辑
》
售價：HK$
94.8
《
“漫画强国科技”系列（全4册）
》
售價：HK$
168.0
|
| 編輯推薦： |
|
1.易学易用：从零开始讲解编程实践，每一个经验教训以“坏代码”开始，以“好代码”结束。2.贴合实际：通过50+条锦囊妙计、100+个案例手把手教你编写高质量代码。3.内容丰富：通过11大主题解读卓越软件工程师编写可靠的、易于维护的代码的关键概念与技术。4.源于实践：内容整合作者及团队成员多年的软件开发实践经验，通过理论介绍与实战相结合的方式详细分析软件开发实践。5.注重效率：通过清晰的注释及代码分析，帮你轻松理解和掌握编程技巧。
|
| 內容簡介： |
|
本书分享的实用技巧可以帮助你编写鲁棒、可靠且易于团队成员理解和适应不断变化需求的代码。内容涉及如何像高效的软件工程师一样思考代码，如何编写读起来像一个结构良好的句子的函数，如何确保代码可靠且无错误，如何进行有效的单元测试，如何识别可能导致问题的代码并对其进行改进，如何编写可重用并适应新需求的代码，如何提高读者的中长期生产力，同时还介绍了如何节省开发人员及团队的宝贵时间，等等。
|
| 關於作者： |
|
Tom Long，拥有剑桥大学信息工程专业硕士学位，目前担任Google公司高级开发工程师，领导一支针对移动设备广告的自动化及优化的技术团队。目前重点关注软件工程、Java开发、团队管理、数据分析、移动广告、技术创新等方向。
|
| 目錄：
|
|
第 一部分 理论第 1章 代码质量 31.1 代码如何变成软件 41.2 代码质量目标 61.2.1 代码应该正常工作 71.2.2 代码应该持续正常工作 71.2.3 代码应该适应不断变化的需求 81.2.4 代码不应该重复别人做过的工作 91.3 代码质量的支柱 101.3.1 编写易于理解的代码 101.3.2 避免意外 111.3.3 编写难以误用的代码 131.3.4 编写模块化的代码 141.3.5 编写可重用、可推广的代码 151.3.6 编写可测试的代码并适当测试 161.4 编写高质量代码是否会拖慢进度 171.5 小结 19第 2章 抽象层次 202.1 空值和本书中的伪代码惯例 202.2 为什么要创建抽象层次 222.3 代码层次 242.3.1 API和实现细节 252.3.2 函数 262.3.3 类 282.3.4 接口 362.3.5 当层次太薄的时候 392.4 微服务简介 402.5 小结 41第3章 其他工程师与代码契约 423.1 你的代码和其他工程师的代码 423.1.1 对你来说显而易见，但对其他人并不清晰的事情 443.1.2 其他工程师无意间试图破坏你的代码 443.1.3 过段时间，你会忘记自己的代码的相关情况 443.2 其他人如何领会你的代码的使用方法 453.2.1 查看代码元素的名称 453.2.2 查看代码元素的数据类型 453.2.3 阅读文档 463.2.4 亲自询问 463.2.5 查看你的代码 463.3 代码契约 473.3.1 契约的附属细则 473.3.2 不要过分依赖附属细则 493.4 检查和断言 533.4.1 检查 543.4.2 断言 553.5 小结 56第4章 错误 574.1 可恢复性 574.1.1 可以从中恢复的错误 574.1.2 无法从中恢复的错误 584.1.3 只有调用者知道能否从某种错误中恢复 584.1.4 让调用者意识到他们可能想从中恢复的错误 604.2 鲁棒性与故障 604.2.1 快速失败 614.2.2 大声失败 624.2.3 可恢复性的范围 624.2.4 不要隐藏错误 644.3 错误报告方式 674.3.1 回顾：异常 684.3.2 显式：受检异常 684.3.3 隐式：非受检异常 704.3.4 显式：允许为空的返回类型 714.3.5 显式：结果返回类型 724.3.6 显式：操作结果返回类型 744.3.7 隐式：承诺/未来 764.3.8 隐式：返回“魔法值” 784.4 报告不可恢复的错误 794.5 报告调用者可能想要从中恢复的错误 794.5.1 使用非受检异常的论据 794.5.2 使用显式报错技术的论据 824.5.3 我的观点：使用显式报错技术 844.6 不要忽视编译器警告 854.7 小结 86第二部分 实践第5章 编写易于理解的代码 915.1 使用描述性名称 915.1.1 非描述性名称使代码难以理解 915.1.2 用注释代替描述性名称是很不好的做法 925.1.3 解决方案：使名称具有描述性 935.2 适当使用注释 945.2.1 多余的注释可能有害 945.2.2 注释不是可读代码的合格替代品 955.2.3 注释可能很适合于解释代码存在的理由 965.2.4 注释可以提供有用的高层概述 965.3 不要执着于代码行数 975.3.1 避免简短但难以理解的代码 985.3.2 解决方案：编写易于理解的代码，即便需要更多行代码 995.4 坚持一致的编程风格 995.4.1 不一致的编程风格可能引发混乱 1005.4.2 解决方案：采纳和遵循风格指南 1005.5 避免深嵌套代码 1015.5.1 嵌套很深的代码可能难以理解 1025.5.2 解决方案：改变结构，最大限度地减少嵌套 1035.5.3 嵌套往往是功能过多的结果 1035.5.4 解决方案：将代码分解为更小的函数 1045.6 使函数调用易于理解 1055.6.1 参数可能难以理解 1055.6.2 解决方案：使用命名参数 1055.6.3 解决方案：使用描述性类型 1065.6.4 有时没有很好的解决方案 1075.6.5 IDE又怎么样呢 1085.7 避免使用未做解释的值 1085.7.1 未做解释的值可能令人困惑 1095.7.2 解决方案：使用恰当命名的常量 1105.7.3 解决方案：使用恰当命名的函数 1105.8 正确使用匿名函数 1115.8.1 匿名函数适合于小的事物 1125.8.2 匿名函数可能导致代码难以理解 1135.8.3 解决方案：用命名函数代替 1135.8.4 大的匿名函数可能造成问题 1145.8.5 解决方案：将大的匿名函数分解为命名函数 1155.9 正确使用新奇的编程语言特性 1165.9.1 新特性可能改善代码 1175.9.2 不为人知的特性可能引起混乱 1175.9.3 使用适合于工作的工具 1185.10 小结 118第6章 避免意外 1196.1 避免返回魔法值 1196.1.1 魔法值可能造成缺陷 1206.1.2 解决方案：返回空值、可选值或者错误 1216.1.3 魔法值可能偶然出现 1226.2 正确使用空对象模式 1246.2.1 返回空集可能改进代码 1256.2.2 返回空字符串有时可能造成问题 1266.2.3 较复杂的空对象可能造成意外 1286.2.4 空对象实现可能造成意外 1296.3 避免造成意料之外的副作用 1306.3.1 明显、有意的副作用没有问题 1316.3.2 意料之外的副作用可能造成问题 1316.3.3 解决方案：避免副作用或者使其显而易见 1346.4 谨防输入参数突变 1356.4.1 输入参数突变可能导致程序缺陷 1366.4.2 解决方案：在突变之前复制 1376.5 避免编写误导性的函数 1376.5.1 在关键输入缺失时什么都不做可能造成意外 1386.5.2 解决方案：将关键输入变成必要的输入 1406.6 永不过时的枚举处理 1416.6.1 隐式处理未来的枚举值可能造成问题 1416.6.2 解决方案：使用全面的switch语句 1436.6.3 注意默认情况 1446.6.4 注意事项：依赖另一个项目的枚举类型 1466.7 我们不能只用测试解决所有此类问题吗 1466.8 小结 147第7章 编写难以被误用的代码 1487.1 考虑不可变对象 1497.1.1 可变类可能很容易被误用 1497.1.2 解决方案：只在构建时设值 1517.1.3 解决方案：使用不可变性设计模式 1527.2 考虑实现深度不可变性 1577.2.1 深度可变性可能导致误用 1577.2.2 解决方案：防御性复制 1597.2.3 解决方案：使用不可变数据结构 1607.3 避免过于通用的类型 1617.3.1 过于通用的类型可能被误用 1627.3.2 配对类型很容易被误用 1647.3.3 解决方案：使用专用类型 1667.4 处理时间 1677.4.1 用整数表示时间可能带来问题 1687.4.2 解决方案：使用合适的数据结构表示时间 1707.5 拥有单一可信数据源 1727.5.1 第二个可信数据源可能导致无效状态 1727.5.2 解决方案：使用原始数据作为单一可信数据源 1737.6 拥有单一可信逻辑来源 1757.6.1 多个可信逻辑来源可能导致程序缺陷 1757.6.2 解决方案：使用单一可信来源 1777.7 小结 179第8章 实现代码模块化 1808.1 考虑使用依赖注入 1808.1.1 硬编程的依赖项可能造成问题 1818.1.2 解决方案：使用依赖注入 1828.1.3 在设计代码时考虑依赖注入 1848.2 倾向于依赖接口 1858.2.1 依赖于具体实现将限制适应性 1868.2.2 解决方案：尽可能依赖于接口 1868.3 注意类的继承 1878.3.1 类继承可能造成问题 1888.3.2 解决方案：使用组合 1928.3.3 真正的“is-a”关系该怎么办 1948.4 类应该只关心自身 1968.4.1 过于关心其他类可能造成问题 1968.4.2 解决方案：使类仅关心自身 1978.5 将相关联的数据封装在一起 1988.5.1 未封装的数据可能难以处理 1998.5.2 解决方案：将相关数据组合为对象或类 2008.6 防止在返回类型中泄露实现细节 2018.6.1 在返回类型中泄露实现细节可能造成问题 2028.6.2 解决方案：返回对应于抽象层次的类型 2038.7 防止在异常中泄露实现细节 2048.7.1 在异常中泄露实现细节可能造成问题 2048.7.2 解决方案：使异常适合抽象层次 2068.8 小结 208第9章 编写可重用、可推广的代码 2099.1 注意各种假设 2099.1.1 代码重用时假设将导致缺陷 2109.1.2 解决方案：避免不必要的假设 2109.1.3 解决方案：如果假设是必要的，则强制实施 2119.2 注意全局状态 2139.2.1 全局状态可能使重用变得不安全 2159.2.2 解决方案：依赖注入共享状态 2179.3 恰当地使用默认返回值 2199.3.1 低层次代码中的默认返回值可能损害可重用性 2209.3.2 解决方案：在较高层次代码中使用默认值 2219.4 保持函数参数的集中度 2239.4.1 如果函数参数超出需要，可能难以重用 2249.4.2 解决方案：让函数只取得需要的参数 2259.5 考虑使用泛型 2269.5.1 依赖于特定类型将限制可推广性 2269.5.2 解决方案：使用泛型 2279.6 小结 228第三部分 单元测试第 10章 单元测试原则 23110.1 单元测试入门 23210.2 是什么造就好的单元测试 23310.2.1 准确检测破坏 23410.2.2 与实现细节无关 23510.2.3 充分解释失败 23610.2.4 易于理解的测试代码 23710.2.5 便捷运行 23710.3 专注于公共API，但不要忽略重要的行为 23810.4 测试替身 24210.4.1 使用测试替身的理由 24210.4.2 模拟对象 24610.4.3 桩 24810.4.4 模拟对象和桩可能有问题 25010.4.5 伪造对象 25310.4.6 关于模拟对象的不同学派 25610.5 挑选测试思想 25710.6 小结 258第 11章 单元测试实践 25911.1 测试行为，而不仅仅是函数 25911.1.1 每个函数一个测试用例往往是不够的 26011.1.2 解决方案：专注于测试每个行为 26111.2 避免仅为了测试而使所有细节可见 26311.2.1 测试私有函数往往是个坏主意 26411.2.2 解决方案：首选通过公共API测试 26511.2.3 解决方案：将代码分解为较小的单元 26611.3 一次测试一个行为 27011.3.1 一次测试多个行为可能导致降低测试质量 27011.3.2 解决方案：以单独的测试用例测试每个行为 27211.3.3 参数化测试 27311.4 恰当地使用共享测试配置 27411.4.1 共享状态可能带来问题 27511.4.2 解决方案：避免共享状态或者重置状态 27711.4.3 共享配置可能带来问题 27811.4.4 解决方案：在测试用例中定义重要配置 28111.4.5 何时适用共享配置 28311.5 使用合适的断言匹配器 28411.5.1 不合适的匹配器可能导致无法充分解释失败 28411.5.2 解决方案：使用合适的匹配器 28611.6 使用依赖注入来提高可测试性 28711.6.1 硬编程的依赖项可能导致代码无法测试 28711.6.2 解决方案：使用依赖注入 28811.7 关于测试的一些结论 28911.8 小结 290附录A 巧克力糕饼食谱 291附录B 空值安全与可选类型 292附录C 额外的代码示例 295
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
