新書推薦：
《
纯粹·十三个小津
》
售價：HK$
101.2
《
海外中国研究·米芾：风格与中国北宋的书法艺术（艺术系列）
》
售價：HK$
194.4
《
华南地区边坡绿化乡土植物图鉴
》
售價：HK$
147.2
《
千秋堂丛书002：北洋之乱——一本书讲清武夫治国、军阀混战的北洋时代
》
售價：HK$
112.7
《
声学手册 第7版 声学设计与建筑声学实用指南
》
售價：HK$
218.3
《
掼蛋入门到精通（礼盒版）
》
售價：HK$
193.2
《
中国书法散论（熊秉明文艺三书）
》
售價：HK$
71.3
《
战争事典083：细说靖难之役 ： 明成祖朱棣的戎马征程
》
售價：HK$
114.8
|
| 編輯推薦： |
一句话推荐
重获代码的控制权
编辑推荐
对大型、复杂的代码库进行重大修改是一项艰巨的任务，除非你有合适的团队、工具和思维方式，否则几乎不可能成功。如果你的应用程序需要进行重大改造，但你又不确定以何种可持续的方式进行，那么这本书就是为你准备的。
软件工程师Maude Lemaire将带领你从头到尾经历整个重构过程。你将了解她在Slack的关键发展时期是如何提高性能和重构的，并从这些经验中得到启发，书中利用两个案例研究来说明这些技术是如何在实际工作中产生影响的。本书将有助于你获得一种新的能力，使你更高效地进行重构。
专家推荐
“在一个巨大的、不断变化的代码库中，保持生产力似乎是一个西西弗斯式的任务。本书将这一过程分解成一个个你可以立即应用的步骤。”
——Cal Henderson
Slack首席技术官
“我喜欢这本书中的案例研究。我希望我能把这本书送给过去的自己，帮助以前的我更好的规划大型迁移。书中有很多我需要去努力学习的经验。”
——Julia Evans
《Wizard Zines》的作者
|
| 內容簡介： |
|
本书的主要内容有：理解代码是如何退化的，以及为什么一些退化是不可避免的。在重构之前，量化和评定你的代码状态。起草一个具有战略里程碑且精心设计的执行计划。赢得领导层的支持。建立和协调一个最z适合项目的团队。在团队内外进行高效沟通。正确使用重构的最z佳实践。
|
| 關於作者： |
|
Maude Lemaire是Slack的一名软件工程师，她的工作是提升产品性能，以支持一些世界上最z大的组织。她的大部分时间都在进行人员管理、网络调用、重构复杂的代码块、整合冗余的数据库，以及为其他开发者构建工具。
|
| 目錄：
|
目录
前言 1
第一部分 概述
第1 章 重构 11
1.1 什么是重构？ .12
1.2 什么是大规模重构？ 14
1.3 你为什么要关心重构？ .16
1.4 重构的好处 17
1.4.1 开发者的生产力 17
1.4.2 识别bug 19
1.5 重构的风险 19
1.5.1 严重的退步 20
1.5.2 挖掘出休眠的bug 20
1.5.3 范围蔓延 .20
1.5.4 不必要的复杂度 21
1.6 何时重构21
1.6.1 小范围 22
1.6.2 代码的复杂度明显地阻碍了开发 22
1.6.3 产品需求的转变 22
1.6.4 性能 23
1.6.5 使用新技术 23
1.7 何时不要重构 .24
1.7.1 为了好玩或出于无聊的原因 .24
1.7.2 因为你恰好路过 25
1.7.3 使代码更具可扩展性.26
1.7.4 当你没时间时 27
1.8 我们的第一个重构示例 .27
1.8.1 简化条件语句 29
1.8.2 提取魔法数字 31
1.8.3 提取自包含逻辑 32
第2 章 代码是如何退化的 .37
2.1 为什么理解代码退化很重要 38
2.2 需求的转变 39
2.2.1 可扩展性 .39
2.2.2 可访问性 .40
2.2.3 设备兼容性 40
2.2.4 环境改变 .41
2.2.5 外部依赖 .42
2.2.6 未使用的代码 42
2.2.7 产品需求变化 43
2.3 技术债 46
2.3.1 技术决策 .47
2.3.2 缺乏持续的整理 50
2.3.3 移动得太快 51
2.4 应用我们的知识 53
第二部分 规划
第3 章 测量我们的起点状态 .57
3.1 为什么测量重构的影响很难？ 58
3.2 测量代码复杂性 59
3.2.1 哈尔斯特德（Halstead）度量 59
3.2.2 循环复杂度 62
3.2.3 NPath 复杂度 65
3.2.4 代码行数 .68
3.3 测试覆盖率指标 69
3.4 文档 .73
3.4.1 正式文档 .73
3.4.2 非正式文档 75
3.5 版本控制76
3.5.1 提交信息 .77
3.5.2 聚合提交 .77
3.6 声誉 .79
3.7 构建完整的画面 82
第4 章 起草计划 83
4.1 定义你的最终状态 84
4.1.1 旅途中 84
4.1.2 工作中 85
4.2 映射最短的距离 86
4.2.1 旅途中 86
4.2.2 工作中 87
4.3 确定战略中间里程碑 89
4.3.1 旅途中 89
4.3.2 工作中 90
4.4 选择推出策略 .94
4.4.1 明模式（Light）/ 暗模式（Dark） 95
4.4.2 Smart DNA 案例的推出 99
4.5 清理工件.100
4.6 在你的计划中引用指标 102
4.6.1 将目标指标延伸至中间里程碑 102
4.6.2 不同的里程碑指标 103
4.7 估算 104
4.8 与其他团队分享你的计划 .105
4.8.1 透明度 106
4.8.2 观点 .106
4.9 精细化计划 108
第5 章 获取支持 111
5.1 为什么你的经理没有上船 . 112
5.1.1 经理不编码 . 112
5.1.2 经理们的评估方式不同 . 113
5.1.3 管理者看到的风险 113
5.1.4 管理者需要协调 114
5.2 制定令人信服的策略 115
5.2.1 使用对话策略 . 117
5.2.2 构建对齐的“三明治” . 118
5.2.3 依赖证据 121
5.2.4 采取强硬手段 .122
5.3 认同塑造重构 124
第6 章 构建正确的团队 125
6.1 识别不同类型的专家 126
6.2 匹配制度.128
6.2.1 多行业专家 .129
6.2.2 重新审视活跃贡献者130
6.2.3 我们专家名单中的偏见 .130
6.3 重构团队的类型 .132
6.3.1 所有者 132
6.3.2 建议的方法 .134
6.3.3 清洁人员 134
6.4 招募动员.136
6.4.1 指标 .137
6.4.2 慷慨 .138
6.4.3 机会 .139
6.4.4 交换筹码 139
6.4.5 重复 .140
6.5 一些结果.141
6.5.1 现实的场景 .141
6.5.2 最坏的情况 .141
6.6 培养强大的团队 .142
第三部分 执行
第7 章 沟通 . 147
7.1 在你的团队内 148
7.1.1 站会 .150
7.1.2 每周同步 151
7.1.3 回顾会议 153
7.2 在你的团队外 154
7.2.1 开始项目时 .154
7.2.2 在项目执行期间 157
7.3 始终迭代.162
第8 章 执行策略 . 163
8.1 团队建设.163
8.1.1 结对编程 164
8.1.2 保持每个人的动力 166
8.2 保持记录.168
8.2.1 中期指标度量 .168
8.2.2 发现的漏洞 .169
8.2.3 清理项 170
8.2.4 记录超出范围的内容170
8.3 高效编程.171
8.3.1 原型 .171
8.3.2 保持事物小巧 .172
8.3.3 测试，测试，测试 173
8.3.4 提出“愚蠢”的问题173
8.4 结论 174
第9 章 让重构保持有效 175
9.1 推动支持.176
9.2 传授 177
9.2.1 主动传授 177
9.2.2 被动传授 180
9.3 强化 181
9.3.1 渐进式代码检查 181
9.3.2 代码分析工具 .182
9.3.3 门槛与护栏 .182
9.4 将改进融入企业文化 184
第四部分 用例
第10 章 案例研究：冗余数据库模式（Schemas） 189
10.1 Slack 101 .190
10.2 Slack 架构101 192
10.3 可扩展性问题 195
10.3.1 启动Slack 客户端 .196
10.3.2 文件可见性196
10.3.3 提及 197
10.4 合并表格 198
10.4.1 收集分散的查询 .199
10.4.2 制定迁移策略 202
10.4.3 量化我们的进展 .205
10.4.4 试图保持团队的动力 206
10.4.5 沟通我们的进展 .207
10.5 整理 209
10.6 经验教训 211
10.7 了解代码的历史 212
10.7.1 确保充分的测试覆盖率 213
10.7.2 保持团队的动力 .213
10.7.3 专注于战略里程碑 214
10.7.4 识别并依赖有意义的指标 .214
10.8 收获 215
第11 章 案例研究：迁移到新数据库 217
11.1 工作区分片数据 218
11.2 将channels_members 迁移到Vitess 219
11.2.1 分片方案 220
11.2.2 开发新模式 221
11.3 解决JOIN 操作中的纠缠问题 224
11.4 一个困难的推出 228
11.4.1 回填模式 229
11.4.2 暗模式 .230
11.4.3 明模式 .235
11.4.4 日落模式 237
11.5 整理 237
11.6 经验教训 239
11.6.1 设定现实的估算 .240
11.6.2 寻找你需要的团队成员 240
11.6.3 仔细规划范围 241
11.6.4 选择一个项目沟通的单一地点 241
11.6.5 设计一个周到的推出计划 .242
11.7 收获 243
|
| 內容試閱：
|
|
前言虽然有很多关于重构的书籍，但大多数都是处理如何一行行改进代码的细节问题。我认为重构最困难的部分通常不是找到改进手头代码的精确方法，而是需要在其周围进行的所有其他事情。事实上，我甚至可能会说，在任何大型软件项目中，小事情很少有意义，协调复杂的变化才是最大的挑战。这本书是我试图帮助你解决那些困难问题的尝试。它是多年经验的结晶，我曾经进行过各种规模的重构项目。在Slack 任职期间，我领导的许多项目使公司得以大规模扩展，我们的产品已经能够支持拥有25000 名员工的客户，甚至是拥有高达500000 名员工的客户。我们开发的有效重构策略需要能够适应组织的爆炸性增长，与此同时，我们的工程团队在同一时期几乎增长了6 倍。成功地规划和执行一个既影响到你的大部分代码库又涉及越来越多工程师的项目绝非易事。我希望这本书能给你提供你所需要的工具和资源来做到这一点。谁应该阅读这本书如果你在与几十个甚至更多的工程师一起处理大型、复杂的代码库，那么本书就适合你！如果你是一名初级工程师，想通过对公司产生广泛、有意义的影响并开始构建更高级别的技能，大规模重构项目可以是实现这一目标的好方法。这些项目的影响范围广泛，超越了你所在的团队（它们也不是高级工程师马上就能抢走的那种光鲜项目）。这是一个非常好的机会，让你获得新的专业技能（并加强你已有的技能）。本书将教会你如何从头到尾顺利地完成这类项目。本书也是高度技术性的高级工程师的有价值资源，这类工程师可以自己编写没有任何问题的代码，但却感到其他人不理解他们工作的价值而感到沮丧。如果你感到孤立无援，正在寻找方法提升你周围其他人的水平，本书可以教给你所需的策略，帮助他人从你的角度看到重要的技术问题。对于希望帮助团队通过大规模重构的技术经理，本书可以帮助你了解如何在每个步骤中更好地支持你的团队。这里没有大量的技术内容，因此，如果你会以管理的角色参与到大规模重构（工程经理、产品经理、项目经理），都可以从这些思想中受益。为什么写这本书当我开始进行第一个大规模的重构时，我理解代码需要改变的原因和方式，但最困惑我的是如何安全、逐步地引入这些变化，而不会伤及其他人的利益。我渴望产生跨职能影响，并没有停下来思考重构可能对其他人的工作产生的影响，以及我如何激励他们帮助我完成它。我只是一直在冲刺（可以在第10 章中阅读有关此重构的内容）。随后的几年中，我重构了许多行代码，并成为一些重构不当的受害者。我从这些经历中学到的教训似乎很重要，因此我开始在许多会议上演讲。我的演讲引起了数百名工程师的共鸣，他们都像我一样，在自己的公司中经历了有效重构大面积代码的问题。显然，我们的软件教育存在某种差距，特别是在专业软件编写的核心方面。在许多方面，这本书试图教授计算机科学课程中未涵盖的重要内容，仅仅因为在课堂上教授这些内容太困难了。也许这些内容在书中也无法教授，但为什么不试一试呢？本书的组织结构本书分为四部分，按照计划和执行大规模重构所需的工作的大致时间顺序进行组织，如下所述。 第一部分概述。介绍重构背后的重要概念。─ 第 1 章重构。讨论了重构的基础知识以及对比大规模重构与较小规模的重构有何不同。─ 第 2 章代码是如何退化的。描述代码可能退化的多种方式以及如何将其纳入有效的重构中。 第二部分规划。涵盖了计划成功重构所需的所有知识。─ 第 3 章测量我们的起点状态。提供一个概述，介绍在进行任何改进之前，你可以使用哪些指标来衡量你的重构旨在解决的问题。─ 第 4 章起草计划。解释了一个全面的执行计划的重要组成部分以及如何制定一个执行计划。─ 第 5 章获取支持。讨论了不同的方法来获取工程领导支持你的重构。─ 第 6 章构建正确的团队。描述了如何确定哪些工程师最适合参与重构以及如何为他们提供建议。 第三部分执行。关注在重构过程中如何确保重构顺利进行。─ 第 7 章沟通。探讨如何最好地促进团队内部和与任何外部利益相关者之间的良好沟通。─ 第 8 章执行策略。看看如何在重构过程中保持动力的几种方法。─ 第 9 章让重构保持有效。提供了几个建议，以确保你进行的重构所引入的更改得以保留。 第四部分用例，包含两个案例研究，都是从我在Slack 工作期间参与的项目中提取的。这些重构影响了我们核心应用程序的大部分，真正地达到了规模。我希望这些能够帮助阐述书中第一部分到第三部分讨论的概念。这个顺序并不是一成不变的，仅仅因为我们进入了新的阶段，并不意味着我们不应该在必要时重新审视我们之前的假设。例如，你可能会以一个强烈的团队意识开始你的重构工作，但是在起草执行计划的过程中，你可能会发现你需要比最初预期的更多的工程师。这没关系，这种情况经常发生！排版约定本书使用以下排版约定。斜体（Italic）表示新术语、URL、电子邮件地址、文件名和文件扩展名。等宽字体（Constant width）表示程序片段，以及正文中出现的程序元素，例如变量、函数名、数据类型、语句和关键字。使用代码示例补充材料（代码示例、练习等）可在以下链接下载：https://github.com/qcmaude/refactoring-at-scale。本书是要帮你完成工作的。一般来说，如果本书提供了示例代码，你可以把它用在你的程序或文档中。除非你使用了很大一部分代码，否则无需联系我们获得许可。比如，用本书的几个代码片段写一个程序就无需获得许可。销售或分发O’Reilly图书的示例需要获得许可，引用本书中的示例代码回答问题无需获得许可，将书中大量的代码放到你的产品文档中需要获得许可。我们很希望但并不强制要求你在引用本书内容时加上引用说明。引用说明一般包括书名、作者、出版社和ISBN，例如：“Refactoring at Scale by Maude Lemaire(O’Reilly). Copyright 2021 Maude Lemaire， 978-1-492-07553-0 ”。如果你觉得自己对示例代码的使用超出了上述许可范围，请通过permissions@oreilly.com 与我们联系。O’Reilly 在线学习平台（O’Reilly Online Learning）近40 年来，O’Reilly Media 致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。公司独有的专家和改革创新者网络通过O’Reilly 书籍、文章以及在线学习平台，分享他们的专业知识和实践经验。O’Reilly 在线学习平台按照您的需要提供实时培训课程、深入学习渠道、交互式编程环境以及来自O’Reilly 和其他200 多家出版商的大量书籍与视频资料。更多信息，请访问网站：https://www.oreilly.com/。联系我们任何有关本书的意见或疑问，请按照以下地址联系出版社。美国：O’Reilly Media， Inc.1005 Gravenstein Highway NorthSebastopol， CA 95472中国：北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035）奥莱利技术咨询（北京）有限公司勘误、示例和其他信息，请访问https://oreil.ly/refactoring-at-scale。对于本书的评论和技术性问题，请发送电子邮件到errata@oreilly.com.cn。要了解更多O’Reilly 图书和培训的信息，请访问https://oreilly.com。我们的Facebook：https://linkedin.com/company/oreilly-media。我们的Twitter：https://twitter.com/oreillymedia。我们的YouTube：https://www.youtube.com/oreillymedia。致谢写一本书并不是一件容易的事情，这本书也不例外，没有很多人的贡献是不可能完成的。首先，我要感谢O’Reilly 的编辑Jeff Bleiel。Jeff 把一个没有经验的作者（我）变成了一位出版的作者。他的反馈总是非常准确，帮助我更有条理地组织我的思路，并鼓励我在我写得太啰嗦时进行删减（这种情况经常发生）。我简直无法想象有比他更好的编辑。其次，我要感谢少数几个朋友和同事，他们阅读了几章的早期版本：Morgan Jones、Ryan Greenberg 和Jason Liszka。他们的反馈让我确信我的想法是正确的，并且对广泛的读者有价值。对于鼓励和引发思考的谈话，感谢Joann、Kevin、Chase 和Ben。我要感谢Maggie Zhou，在第二个案例研究章节（第11 章）中与我共同撰写。她是我曾经一起工作过的最有思想、最聪明、最有活力的同事之一，我很高兴让世界读到我们一起的冒险！非常感谢我的技术审稿人David Cottrell 和Henry Robinson。David 是我大学时的好朋友，在Google 工作多年，领导了许多大规模的重构。他后来创立了自己的公司。Henry 是我在Slack 的同事，做出了无数的开源贡献，并亲眼见证了硅谷公司的爆炸式增长。他们都是非常有责任心的工程师，这本书从他们的指导和智慧中受益匪浅。我感激他们花费许多时间来验证书中的内容。最终手稿中的任何不准确之处都是我的错误。感谢所有曾经和我一起重构过东西的人。你们太多了，无法一一列举，但你们知道自己是谁。你们都对本书中的思想产生了影响。感谢我的家人（Simon、Marie-Josée、Fran?ois-Rémi、Sophie、Sylvia、Gerry、Stephanie 和Celia）在场外为我加油。最后，感谢我的丈夫Avery。谢谢你的耐心，谢谢你给我写作的时间、空间和鼓励。谢谢你让我占用了无数个下午来讨论一个、两个（或三个、四个）想法。谢谢你相信我。这本书和你一样属于我。我爱你。
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
