译者: 赵睿 / 茹炳晟
出版社: 人民邮电出版社
出品方: 异步图书
出版年: 2023-6-20
ISBN: 9787115599582
页数: 232
装帧: 平装
定价: 79.8
原作名: Modern Software Engineering: Doing What Works to Build Better Software Faster
丛书: 异步图书-程序员必读经典系列
内容简介 · · · · · ·
*内容简介
本书探讨了软件工程的真正含义,汇集了一些重要的软件开发基本原则,将它们紧密结合成一个一致的模型,旨在帮助读者有效、快速地构建软件。全书共4个部分:第1部分探讨软件工程的真正含义,以及如何将工程的原则和原理应用到软件开发中;第2部分讲述运用科学思想优化软件开发过程的方法,包括迭代式、增量式工作,获得并利用快速、高质量的反馈,采用实验性和经验主义的科学方法;第3部分介绍管理软件复杂性的方法,深入探讨模块化、内聚力、关注点分离、信息隐藏和抽象、管理耦合等原则;第4部分介绍支持软件工程的工具,以及一些贯穿本书的软件开发理念,包括可测试性、可部署性、速度、控制变量、持续交付等。
*编辑推荐
(1)持续交付先驱戴维·法利全新力作。曾与耶斯·亨布尔(JezHumble)共同撰写了获Jolt大奖的图书《持续交付:发布可靠软件的系统方法》。
(2)改进复杂...
*内容简介
本书探讨了软件工程的真正含义,汇集了一些重要的软件开发基本原则,将它们紧密结合成一个一致的模型,旨在帮助读者有效、快速地构建软件。全书共4个部分:第1部分探讨软件工程的真正含义,以及如何将工程的原则和原理应用到软件开发中;第2部分讲述运用科学思想优化软件开发过程的方法,包括迭代式、增量式工作,获得并利用快速、高质量的反馈,采用实验性和经验主义的科学方法;第3部分介绍管理软件复杂性的方法,深入探讨模块化、内聚力、关注点分离、信息隐藏和抽象、管理耦合等原则;第4部分介绍支持软件工程的工具,以及一些贯穿本书的软件开发理念,包括可测试性、可部署性、速度、控制变量、持续交付等。
*编辑推荐
(1)持续交付先驱戴维·法利全新力作。曾与耶斯·亨布尔(JezHumble)共同撰写了获Jolt大奖的图书《持续交付:发布可靠软件的系统方法》。
(2)改进复杂软件系统的工程实践指南。纠正人们对软件工程的传统认知误区,阐述生产力和创造力在软件工程中缺一不可的辩证关系;跳出特定的工具或技术,抽象、提炼、连贯为一套具有普适性、基础性的现代软件工程思想和范式;以实用有效的方法为重点,讲解科学原理、工程技术如何应用于软件开发。
(3)广泛适用于各类软件开发团队。书中提及的“道法术器”,对于初创公司或大型企业都适用,促进软件组织更加可靠、高效、高质量地构建软件,交付业务价值,激发创新活力。
(4)国家卫星气象中心风云四号气象卫星地面系统副总设计师 杨磊、中国信息通信研究院云计算与大数据研究所副总工程师 陈屹力等业界学者、实践者亲笔推荐。
*专业书评
我们处在信息化时代中,软件技术正在影响着我们现在的生活,对未来也会产生深远的影响,从人工智能、商业航天到我们的手机、计算机、电动汽车、智能家电等。信息化时代的开启,软件工程在其中起着不可估量的作用。软件工程又是一门理论性和实践性都很强的学科,它采用工程化的概念、理论、技术和方法来指导开发与维护计算机软件。《现代软件工程:如何高效构建软件》通过探讨软件工程的真正含义、利用科学思想优化开发过程、管理软件复杂性,汇集了软件开发中的一些基本原则,能够帮助读者快速、有效地构建现代软件。这本书可作为高等院校、继续教育院校“软件工程”课程的教材和教学参考书,也可供有一定实践经验的软件开发人员和管理人员参考。
——杨磊,国家卫星气象中心风云四号气象卫星地面系统副总设计师
近年来,随着云计算、人工智能、大数据、区块链等新一代信息技术的发展,传统软件形态发生变化,新型智能化应用和产品呈现爆发式增长。软件架构向分布式、松耦合和工程化等方向演进,快速变化的业务需求亟需高效的软件构建来支撑。这本书从纠正人们对软件工程的传统认知误区出发,阐述生产力和创造力在软件工程中缺一不可的辩证关系,并跳出特定的工具或技术,抽象、提炼、连贯为一套具有普适性、基础性的现代软件工程思想和范式;进而以实用有效的方法为重点,讲解科学原理、工程技术如何应用于软件开发。书中提及的现代软件工程“道法术器”,广泛适用于各类软件开发团队,无论是初创公司还是大型企业,对于改进复杂软件系统的工程实践十分有帮助,促进软件组织更加可靠、高效、高质量地构建软件,交付业务价值,激发创新活力。
——陈屹力,中国信息通信研究院云计算与大数据研究所副总工程师
经历了上百个软件项目后,在“如何高效地构建软件、保质保量地交付软件产品”方面我有了一些体会,但却感觉知识、经验零散,不成体系。于是我迫切地想找到一套工具,把这些零散的知识、经验链接起来,形成一整套理论体系。恰好此时我遇见了这本书,如同犯困的时候有人递枕头,读完仿佛睡了一个好觉,有神清气爽、酣畅淋漓之感。
——王旭东,中银保险有限公司信息科技部副总经理
这本书从软件设计的角度阐明了什么是软件工程,贯穿了实用的设计理念和开发原则,帮我们梳理了进化式地扩展我们的系统、即便在不清楚目标的前提下也可以取得进展的方法,同时整理了随着系统变得越来越复杂,管理系统复杂性的各种设计和开发思想。我们在项目中遇到的实际问题,都可以在这本书中找到借鉴之处。这本书既适合初学者学习,又适合有经验的软件开发人员和架构师作为参考用书,甚至对于管理者在组织架构方面都提出了很好的建议。
——黄海,北京邮电大学信息与通信工程学院多媒体技术教研中心主任、硕士生导师
读了这本书,我明白了为什么在我和戴维一起工作的那段时间里,我们作为“软件工程师”是如此成功和满意。我希望你通过阅读这本书,可以从戴维的经验和建议中受益,而不必为你的团队雇用一位戴维·法利。
——特丽莎·吉(Trisha Gee),开发技术推广工程师和Java 拥护者
《现代软件工程:如何高效构建软件》这本书非常好,它描述了当今有经验的从业者们实际构建软件的方式。法利介绍的技术不是死板的、规定性的或线性的,但是它们严格遵循软件构建所需要的方式:经验主义的、迭代的、反馈驱动的、经济的,并且专注于可运行的代码。
——格伦·范德堡(Glenn Vanderburg),Nubank 公司的工程总监
有很多书会告诉你如何效仿一个特定的软件工程实践,但这本书不一样。戴维在书中所做的是,阐述软件工程的本质,以及它与简单工艺的区别。他解释了为什么为了掌握软件工程,你必须成为学习和管理复杂性的专家,如何用已经存在的实践支持这一结论,以及如何判断关于软件工程价值的其他观点。这本书适用于任何认真考虑把软件开发当作一门真正的工程学科的人,无论你是刚刚起步还是已经构建软件几十年了。
——戴夫·豪恩斯洛(Dave Hounslow),软件工程师
这些都是重要的话题,有一个纲要把它们汇集成一个整体太好了。
——迈克尔·尼加德(Michael Nygard),《发布!软件的设计与部署》一书的作者,专业程序员和软件架构师
我一直在看戴维·法利这本书的评阅样书,这本书正是我们需要的。任何有志成为软件工程师或想要掌握这项工艺的人都应该阅读这本书。这本书给了我们关于专业工程的务实、实用的建议。它应该成为大学和训练营的必读书。
——布赖恩·芬斯特(Bryan Finster),杰出的工程师和美国空军一号平台的价值流架构师
作者简介 · · · · · ·
【作者】戴维·法利(David Farley)是持续交付的先驱、思想领袖,也是持续交付、DevOps、测试驱动开发和软件开发领域的专家。
从现代计算的早期开始,戴维曾担任过程序员、软件工程师、系统架构师和成功团队的领导者,他掌握了计算机和软件开发的基本原理,并形成了开创性的方法,改变了开发人员和团队的工作方式。他挑战了传统的思维方式,带领团队开发了世界级的软件。
戴维是获Jolt大奖的《持续交付:发布可靠软件的系统方法》一书的作者之一,是一位受欢迎的会议演讲者,并在YouTube上运营着广受欢迎的“持续交付”频道,主题是软件工程。他建立了世界上速度最快的金融交易所之一,是行为驱动开发的先驱,是《反应式宣言》的作者之一,并凭借LMAX Disruptor获得了杜克开源软件奖。
戴维热衷于通过咨询、YouTube 频道和培训课程分享他的专业知识,帮助世界...
【作者】戴维·法利(David Farley)是持续交付的先驱、思想领袖,也是持续交付、DevOps、测试驱动开发和软件开发领域的专家。
从现代计算的早期开始,戴维曾担任过程序员、软件工程师、系统架构师和成功团队的领导者,他掌握了计算机和软件开发的基本原理,并形成了开创性的方法,改变了开发人员和团队的工作方式。他挑战了传统的思维方式,带领团队开发了世界级的软件。
戴维是获Jolt大奖的《持续交付:发布可靠软件的系统方法》一书的作者之一,是一位受欢迎的会议演讲者,并在YouTube上运营着广受欢迎的“持续交付”频道,主题是软件工程。他建立了世界上速度最快的金融交易所之一,是行为驱动开发的先驱,是《反应式宣言》的作者之一,并凭借LMAX Disruptor获得了杜克开源软件奖。
戴维热衷于通过咨询、YouTube 频道和培训课程分享他的专业知识,帮助世界各地的开发团队改进软件的设计,提高软件的质量和可靠性。
【译者】赵睿,计算机硕士,拥有20 年IT从业经验;曾先后就职于LG CNS China(北京乐金系统集成有限公司)和中国惠普有限公司,担任过软件工程师、架构师、项目经理等职务,参与或主导过物流系统、BI系统、云计算操作平台等多个大中型项目的软件开发、架构设计、团队建设和项目管理等工作;在单体架构、微服务架构、设计模式、敏捷编程、软件工程等方面有多年实践经验。译有《EJB 3.0 专家编程》和《Java EE 和.NET互操作性》。
【译者】茹炳晟,腾讯Tech Lead,腾讯研究院特约研究员,中国计算机学会(CCF)技术前线委员会(TF)研发效能主席,“研发效能宣言”发起人和主要起草人,团体标准《软件研发效能度量规范》核心编写专家,中国商业联合会互联网应用工作委员会智库专家,腾讯云、阿里云、华为云最具价值专家;国内多个技术峰会的联席主席、出品人和主会场演讲嘉宾;公众号“茹炳晟聊软件研发”主理人;著有《测试工程师全栈技术进阶与实践》《软件研发效能提升之美》《高效自动化测试平台: 设计与开发实战》《软件研发效能提升实践》和《软件研发效能权威指南》,译有《持续架构实践》。
目录 · · · · · ·
第1部分 什么是软件工程?
第1章 简单介绍 3
1.1 工程——科学的实际应用 3
1.2 软件工程的定义 4
1.3 重新定义“软件工程” 6
· · · · · · (更多)
第1部分 什么是软件工程?
第1章 简单介绍 3
1.1 工程——科学的实际应用 3
1.2 软件工程的定义 4
1.3 重新定义“软件工程” 6
1.4 软件工程的诞生 7
1.5 范式转移 9
1.6 小结 10
第2章 什么是工程? 11
2.1 生产不是我们的问题 12
2.2 设计工程,而非生产工程 12
2.3 工程学的初步定义 17
2.4 工程不等于代码 18
2.5 为什么工程很重要? 20
2.6 “工艺”的极限 20
2.7 精度和可伸缩性 21
2.8 管理复杂性 22
2.9 测量的可重复性和准确性 23
2.10 工程、创造和工艺 25
2.11 为什么我们所做的不是软件工程 27
2.12 权衡 28
2.13 进步的错觉 28
2.14 从工艺到工程的旅程 29
2.15 只有工艺还不够 30
2.16 是时候反思了? 30
2.17 小结 32
第3章 工程方法的基本原理 33
3.1 变革的行业? 33
3.2 度量的重要性 35
3.3 应用稳定性和吞吐量 37
3.4 软件工程学科的基础 38
3.5 学习专家 39
3.6 管理复杂性的专家 40
3.7 小结 41
第2部分 优化学习
第4章 迭代式工作 45
4.1 迭代式工作的实际优势 47
4.2 迭代作为防御性设计策略 49
4.3 计划的诱惑 51
4.4 迭代式工作的实用性 56
4.5 小结 58
第5章 反馈 59
5.1 反馈重要性的实例 60
5.2 编码中的反馈 63
5.3 集成中的反馈 64
5.4 设计中的反馈 66
5.5 架构中的反馈 68
5.6 倾向于早期反馈 70
5.7 产品设计中的反馈 71
5.8 组织和文化中的反馈 72
5.9 小结 74
第6章 增量主义 75
6.1 模块化的重要性 76
6.2 组织增量主义 77
6.3 增量主义工具 79
6.4 限制变更的影响 80
6.5 增量式设计 82
6.6 小结 84
第7章 经验主义 85
7.1 立足于现实 86
7.2 区分经验主义与实验性 87
7.3 “我知道那个bug!” 87
7.4 避免自我欺骗 89
7.5 创造符合我们论点的现实 90
7.6 以现实为指导 93
7.7 小结 94
第8章 实验性 95
8.1 “实验性”是什么意思? 96
8.2 反馈 97
8.3 假设 99
8.4 度量 100
8.5 控制变量 101
8.6 自动化测试作为实验 102
8.7 将测试的实验结果置于环境中 103
8.8 实验范围 105
8.9 小结 106
第3部分 优化管理复杂性
第9章 模块化 109
9.1 模块化的标志 111
9.2 低估优秀设计的重要性 111
9.3 可测试性的重要性 113
9.4 可测试性设计提高模块化 114
9.5 服务和模块化 120
9.6 可部署性和模块化 121
9.7 不同规模的模块化 123
9.8 人类系统中的模块化 124
9.9 小结 126
第10章 内聚力 127
10.1 模块化和内聚力:设计的基础 127
10.2 内聚力的基本降低 128
10.3 上下文很重要 131
10.4 高性能软件 134
10.5 与耦合的联系 135
10.6 测试驱动开发推动高内聚力 136
10.7 如何实现内聚软件 136
10.8 内聚力差的代价 139
10.9 人类系统中的内聚力 140
10.10 小结 140
第11章 关注点分离 141
11.1 依赖注入 145
11.2 分离本质复杂性和偶然复杂性 146
11.3 领域驱动设计的重要性 149
11.4 可测试性 151
11.5 端口和适配器 151
11.6 何时采用端口和适配器 154
11.7 什么是API? 155
11.8 使用测试驱动开发推动关注点分离 156
11.9 小结 157
第12章 信息隐藏和抽象 158
12.1 抽象或信息隐藏 158
12.2 是什么导致了“大泥球”? 159
12.3 组织和文化问题 159
12.4 技术问题和设计问题 162
12.5 对过度设计的恐惧 165
12.6 通过测试改进抽象 168
12.7 抽象的力量 169
12.8 抽象泄漏 170
12.9 选择适当的抽象 172
12.10 问题领域的抽象 174
12.11 抽象偶然复杂性 175
12.12 隔离第三方系统和代码 178
12.13 总是倾向于隐藏信息 179
12.14 小结 180
第13章 管理耦合 181
13.1 耦合的代价 181
13.2 扩展 182
13.3 微服务 183
13.4 解耦可能意味着更多的代码 185
13.5 松耦合不是唯一重要的类型 187
13.6 倾向于松耦合 188
13.7 这与关注点分离有何不同? 189
13.8 DRY 太过于简单化 190
13.9 异步作为松耦合的工具 192
13.10 松耦合设计 193
13.11 人类系统中的松耦合 194
13.12 小结 196
第4部分 支持软件工程的工具
第14 章 工程学科的工具 199
14.1 什么是软件开发? 200
14.2 可测试性作为工具 202
14.3 测量点 205
14.4 实现可测试性的问题 205
14.5 如何提高可测试性 209
14.6 可部署性 210
14.7 速度 212
14.8 控制变量 213
14.9 持续交付 214
14.10 支持工程的通用工具 215
14.11 小结 216
第15章 现代软件工程师 217
15.1 工程作为人类过程 219
15.2 数字化颠覆性组织 220
15.3 结果与机制 222
15.4 持久且普遍适用 224
15.5 工程学科的基础 227
15.6 小结 227
· · · · · · (收起)
原文摘录 · · · · · · ( 全部 )
-
我在大学里学的是计算机科学,当然,我完成了几门名为“软件工程”或者名字与之类似的课程。 在我开始攻读学士学位时,我对编程其实并不陌生,并且已经为我的高中的职业图书馆实现了一个完全有效的目录管理系统。我记得自己曾经对“软件工程”极度困惑,它的存在似乎就是为了妨碍实际的代码编写和应用程序交付。 21 世纪初,当我毕业的时候,我去了一家大型汽车公司的IT部门工作。正如你所料,他们热衷于“软件工程”。就是在这里,我第一次看到(但肯定不是最后一次!)甘特图(Gantt chart),也是在这里,我体验到了瀑布式(waterfall)开发。也就是说,我看到软件开发团队在需求收集和设计阶段花费了大量的时间和精力,而在实现(编码)上花费的时间却少得多,这样当然会占用测试时间,然后测试......好吧,剩下的时间已经不多了。这似乎是在告诉我们,“软件工程”实际上阻碍了创建对客户有用的高质量应用程序。 和许多开发者一样,我觉得一定有更好的方法。 我了解过极限编程(extreme programming,XP)和 Scrum。我想在一个敏捷的(agile)团队中工作,为了找到一个这样的团队,我换了几次工作。很多人说他们是敏捷的,但是通常归总起来,他们不过都是把需求或任务写在索引卡上,贴在墙上,一周为一个冲刺(sprint),然后要求开发团队在每个冲刺内交付“x”张卡片,以满足任意的截止日期。以这样的方式来摆脱传统的“软件工程”方法似乎并不起作用。 在我从事软件开发工作10年后,我参加了位于伦敦的一家金融交易所的面试。软件负责人告诉我,他们采用极限编程,包括测试驱动开发(test-driven development,TDD)和结对编程(pair programming)。他告诉我,他们正在做一件叫作持续交付(continuous delivery)的事情,这很像持续集成(continu... (查看原文) —— 引自章节:序 ——特丽莎·吉(Trisha Gee),开发技术推广工程 -
不过具体来玩· 倾向认为政变现有的代码是一件好事,定 野多组织要么害怕更改他们的代码,要么对其不有某种背离现实的敬畏之心。我为怡倍相反:如果你不能或不愿更改代码,那么代码实际上是死的。再次用弗雷德痛 鲁克斯的话: 一旦一个设计被冻结,它就过时了。① 家的丽友丹·诺思说过一个有趣的想法。丹有一种用巧妙的措辞表达观点的才华,他把“团队的软件半衰期”当作质量的度量标准。 我和丹都没有数据来支持这个观点,但这是一个有趣的观点。他说,一个团队生产的软件的质量是其软件半衰期的因变量。软件半衰期是指,队重写一半他们负责骏件所花费的时间。 在丹的模型中,优秀的团队可能会在几个月内重写一半他们负责的软件,低效能队可能永远不会完成一半的重写。 现在我很确定丹的观点是有上下文的。当他想到这个的时候,他在一个非常好的快节奏的金融交易团队工作。我同样确信,在许多团队中,这条规则并不适用。然而, (查看原文) —— 引自章节:12.4 技术问题和设计问题 162
> 全部原文摘录
丛书信息
· · · · · ·
喜欢读"现代软件工程"的人也喜欢 · · · · · ·
现代软件工程的书评 · · · · · · ( 全部 11 条 )
译者征集 | Modern Software Engineering: Doing What Works to Build Better Software Faster寻找译者
这篇书评可能有关键情节透露
原书名:Modern Software Engineering: Doing What Works to Build Better Software Faster 作者:[美] 戴维·法利(David Farley) 美国亚马逊链接: https://www.amazon.com/Modern-Software-Engineering-Discipline-Development/dp/0137314914 语言:英语 类别:软件工程的... (展开)刷新对现在软件工程的认识和理解
这篇书评可能有关键情节透露
持续交付先驱戴维.法利的这本全新力作目前软件公司存在的现象是大家对于业务目标非常关注,对于软件研发能力提升关注不足,而软件工程师对于代码能力和算法能力比较重视,而对于软件工程能力的提升重视不够。持续交付先锋戴维法利的这本全新力作<<现代软件工程--如何高效构建软... (展开)工程理念、组织、优化与工具相辅相成,高效构建软件
《现代软件工程》——读后感
多示例讲解现代的软件工程
《现代软件工程:如何高效构建软件》
> 更多书评 11篇
论坛 · · · · · ·
在这本书的论坛里发言这本书的其他版本 · · · · · · ( 全部2 )
-
Addison-Wesley Professional (2021)暂无评分 8人读过
以下书单推荐 · · · · · · ( 全部 )
- 软件工程 (智能之爱)
- CS推荐 (橄榄树萍)
- EA融合企业与系统的认知----数字化支柱Ⅰ (小毛叔)
- 计算机 (Alprazolam)
- 企业级IT技术 (Snake)
谁读这本书? · · · · · ·
二手市场
· · · · · ·
- 在豆瓣转让 有291人想读,手里有一本闲着?
订阅关于现代软件工程的评论:
feed: rss 2.0










0 有用 Exaybachay 2023-11-20 14:21:43 北京
新时代围绕软件工程几个话题的散文
0 有用 Ishmael 2023-06-20 20:41:54 浙江
两组五个原则有些重叠,应该能重组吧。
3 有用 异步图书 2023-06-12 14:11:48 北京
持续交付先驱戴维·法利,继《持续交付:发布可靠软件的系统方法》后全新力作!改进复杂软件系统的工程实践指南,从思维方式到代码质量提高你的创造力和效率。
0 有用 鑫淼森 2024-10-18 21:38:47 陕西
学习专家: 迭代,反馈,增量主义,实验,经验主义 管理复杂性专家: 模块化,内聚力,关注点分离,抽象,松耦合 软件工程方法: 可测试性,可部署性,反馈的速度和质量 整本书读起来不是很清晰,减一分
0 有用 Ekexium 2025-08-31 15:16:03 浙江
书中的观点我基本赞同,新意比较少。 整本书虽然不厚,但信息密度偏低,感觉有非常多的车轱辘话,让人总想跳着读。 相比 A philosophy of software design 之类的书,读完的收获感小不少,虽然两本书覆盖的内容不完全一致。