具体描述
本书的最佳实践来自作者所研究的超过600家全球知名软件公司和30余个美国大型政府组织，是软件行业半个世纪以来全球范围内软件工程实践的精华。本书从软件工程的宏观层面，对比各种软件工程实践，剖析优劣，洞悉软件工程的是非与成败，揭露各种软件工程实践的伪真理，深刻指出软件项目中存在的各种问题的实质，为并给出中肯的改进建议和解决方案。
本书深入地探讨了其他软件文献中很少涵盖的如下软件工程主题：为什么软件行业开发出了超过2500种之多的编程语言；软件质量传统定义的诸多问题；“代码行数”和“平均缺陷成本”等违反标准经济学假设的通用度量指标的种种缺陷。本书指出，数量巨大的“新”项目实际上只不过是遗留应用的替代品，这说明为寻找那些已遗失的初始需求而进行的数据挖掘应该成为软件项目的标准实践。本书还讨论了诸如如何将裁员和紧缩的危害降至最小等困难的社会工程问题。
本书说明了如何有效地使用成熟、可靠的工程过程来规划、估算、安排进度和管理各种类型的软件项目。它详细地阐述了从软件初始需求到20年的软件维护之后各种方法，这些方法贯穿软件整个生命周期的各阶段，已被实践证明是行之有效的。本书各部分受到来自包括IBM、微软、Unisys和索尼等顶级软件公司的资深工程师们广泛、深入地审核和评论。
• 管理敏捷、层级式、矩阵式和虚拟软件开发团队
• 使用JAD、QFD、TSP、静态分析、审查和其他具有出色成功案例记录的方法优化软件质量
• 使用高速功能性度量指标评估软件项目的生产力和软件质量水平
• 规划最佳软件组织，从小型团队到1000人以上的大型组织
作者简介
Capers Jones，目前是Namcook Analytics公司的合伙创始人、副总裁兼首席技术官。他还是软件生产力研究所（SPR）的创始人和前总裁。Capers获得了SPR首席科学家的荣誉称号。他还是软件质量世界大会的主题演讲人，是国际功能点用户组（IFPUG）的终身会员。他获得了IFPUG终身会员的荣誉。Capers还曾被信息技术软件质量联盟（CISQ）评为“杰出顾问”（Distinguished Advisor）。Capers的研究囊括了软件质量评估、质量度量、软件成本与进度估算以及软件度量指标。Capers的著作包括如下:《Patterns of Software Systems Failure and Success》、《Applied Software Measurement，Third Edition》、《Software Quality: Analysis and Guidelines for Success》、《Estimating Software Costs，Second Edition》以及《Software Assessments, Benchmarks and Best Practices》。
目录信息
序
前言
第1章 软件最佳实践的介绍和定义 1
1.1 什么是“最佳实践”？如何进行评估 5
1.2 软件开发、部署以及维护的多种路径 7
1.3 软件部署的路径 9
1.4 维护和部署的路径 10
1.5 软件开发、部署以及维护的量化 12
1.6 软件工程中的关键主题 14
1.7 方法、实践以及社会学因素的总排名 18
1.8 总结 28
参考文献 28
第2章 50个软件最佳实践概述 31
2.1 最大限度地减少裁员所带来的危害 33
2.2 技术人员的积极性和动力 35
2.3 经理和高管的积极性与动力 37
2.4 软件人才的选拔和招聘 39
2.5 软件人员的考核以及职业生涯规划 39
2.6 软件应用早期的范围控制 40
2.7 软件应用的外包 41
2.8 使用承包商和管理顾问 44
2.9 选择软件方法、工具以及做法的最佳实践 45
2.10 认证方法、工具以及实践 49
2.11 软件应用的需求 54
2.12 用户参与软件项目 55
2.13 软件应用中的行政管理支持 56
2.14 软件架构和设计 57
2.15 软件项目规划 58
2.16 软件项目的成本估算 59
2.17 软件项目的风险分析 61
2.18 软件项目的价值分析 63
2.19 取消或拯救陷入困境的项目 64
2.20 软件项目的组织结构 65
2.21 培训软件项目经理 67
2.22 培训软件技术人员 69
2.23 使用软件专家 69
2.24 软件工程师、专家以及管理人员的认证 71
2.25 软件项目中的沟通 73
2.26 软件的可重用性 74
2.27 可重用材料的认证 76
2.28 编程 80
2.29 软件项目管理 82
2.30 软件项目的度量和指标 82
2.31 软件的基准和基线 84
2.32 软件项目的里程碑和成本跟踪 86
2.33 软件发布前的变更控制 87
2.34 配置控制 89
2.35 软件质量保证 90
2.36 审查以及静态分析 92
2.37 测试和测试库的控制 95
2.38 软件的安全性分析与控制 98
2.39 软件的性能分析 100
2.40 软件的国际标准 101
2.41 软件中的知识产权保护 101
2.42 防止病毒、间谍软件以及黑客 103
2.43 软件的部署和定制 114
2.44 培训软件应用的客户或用户 115
2.45 软件应用部署后的客户支持 116
2.46 软件担保和召回 117
2.47 软件发布后的变更管理 118
2.48 软件的维护和功能增强 119
2.49 软件应用的更新和发布 121
2.50 遗留应用的终止或撤销 122
2.51 总结 123
参考文献 123
第3章 2049年的软件开发和维护预览 133
3.1 引言 133
3.2 需求分析 134
3.3 设计 136
3.4 软件开发 138
3.5 用户文档 140
3.6 客户支持 140
3.7 部署和客户培训 142
3.8 软件维护和功能增强 143
3.9 软件外包 146
3.10 软件包评估和收购 152
3.11 技术选择和技术转型 154
3.12 企业架构和项目组合分析 156
3.13 软件学习预览 158
3.14 尽职调查 160
3.15 认证和授权 162
3.16 软件诉讼 164
3.17 总结 166
参考文献 167
第4章 软件人员如何学习新技能 168
4.1 引言 168
4.2 软件学习渠道的演变 169
4.3 软件工程师当前需要学习哪些技术主题 171
4.4 软件工程专家 173
4.5 软件专业的种类 175
4.6 专家与普通软件人员的大概比率 178
4.7 评估软件工程师所使用的学习渠道 179
4.8 需要额外教育的软件领域 196
4.9 软件学习的新动向 197
4.10 总结 198
4.11 软件管理和技术类主题课程 198
参考文献 201
第5章 软件团队的组织和专业化 203
5.1 引言 203
5.2 量化组织结果 204
5.3 割裂的信息技术和系统软件世界 204
5.4 集中办公与分布式开发 205
5.5 软件专家组织面临的挑战 207
5.6 由小到大的软件组织结构 209
5.7 大型公司的专家组织 226
5.8 总结 254
参考文献 255
第6章 项目管理和软件工程 257
6.1 引言 257
6.2 软件规模估算 263
6.3 软件进度与问题跟踪 296
6.4 软件基准 300
6.5 总结 318
参考文献 318
第7章 需求、业务分析、架构及设计 322
7.1 引言 322
7.2 软件需求 323
7.3 软件需求方法论及实践 337
7.4 业务分析 347
7.5 软件架构 349
7.6 企业架构师 352
7.7 软件设计 356
7.8 总结 360
参考文献 361
第8章 编程和代码开发 364
8.1 引言 364
8.2 编程语言开发简史 364
8.3 我们为什么会有超过2500种编程语言 366
8.4 编程语言普及性的探索 369
8.5 我们到底需要多少种编程语言 372
8.6 建立一个国家级的编程语言翻译中心 374
8.7 为什么大多数软件都使用2～15种编程语言 377
8.8 有多少程序员使用多种编程语言 378
8.9 源代码中通常会出现何种类型的缺陷 380
8.10 软件缺陷的逻辑和属性 382
8.11 软件源代码缺陷的预防和去除 387
8.12 编程缺陷预防方法 388
8.13 缺陷去除方法 396
8.14 “代码行”度量方法的经济学问题 403
8.15 总结 415
参考文献 416
第9章 软件质量：软件工程成功的关键 419
9.1 引言 419
9.2 软件质量定义 421
9.3 软件质量度量 441
9.4 软件缺陷预防 453
9.5 软件缺陷去除 462
9.6 软件质量专家 467
9.7 软件质量的经济价值 479
9.8 总结 486
参考文献 486
· · · · · · (收起)
读后感
评分
评分
评分
评分
用户评价
老实说，我是一个对“最佳实践”这个词汇抱有高度警惕心的读者，因为它常常意味着僵化和教条。我更偏爱那种充满探索性和辩证性的著作。这本书却以一种近乎哲学思辨的方式，探讨了“什么是适度的自动化”。我之前盲目地相信“越多越好”的自动化原则，结果引入了一堆过度工程化的工具链，反而增加了维护的复杂性和学习成本。书中对于“自动化边界”的讨论非常精妙，它提出了一个衡量标准：如果一个测试或流程的维护成本超过了它可能预防的潜在损失，那么它可能就是一种反向实践。这种辩证的思考方式，让我重新审视了团队内部引入的各种工具和流程。它不是简单地告诉你“要怎么做”，而是引导你去思考“在我的具体情境下，‘最好’的标准到底是什么”。这本书的价值在于它提供了一套思考工具箱，而不是一套预设的工具集。对于那些已经有一定开发经验，但开始对现有流程产生困惑，渴望超越表层操作的资深开发者来说，这本书的深度和广度是极具启发性的。
评分我是一个对文档和知识管理有执念的人，因为我发现，大部分软件项目的失败不是因为技术能力不行，而是因为知识的快速流失和文档的严重滞后。这本书中关于“知识资产化”的章节，简直是为我们这种饱受“老员工一走，项目就停滞”之苦的团队量身定做的。作者提出的“代码即文档，文档即代码”的理念，并不仅仅是一个口号，而是提供了一套具体的实践方法论，比如如何利用代码注释、Markdown 文件和自动化文档生成工具，确保文档的更新速度与代码的迭代速度保持同步。最让我感到振奋的是，书中提供了一种评估文档“新鲜度”的量化指标，这使得文档维护不再是可有可无的“美德行为”，而是可以被纳入绩效考核和CI流程的关键环节。这本书让我明白，软件工程的最佳实践，最终都要回归到如何有效地管理“人”和“信息”的协作上。它成功地将那些容易被忽视的软技能和流程管理，提升到了与架构设计同等重要的战略地位。
评分这本书简直是软件开发领域的“葵花宝典”！我最近在负责一个跨部门的大型项目，需求不断变化，技术栈也异常复杂，搞得团队焦头烂额。说实话，在读这本书之前，我对敏捷和DevOps的理解还停留在理论层面，总觉得是空中楼阁，难以落地。但这本书的厉害之处在于，它没有过多地谈那些高深的学术概念，而是用大量真实的案例和清晰的流程图，手把手地教你如何将那些“最佳实践”融入到日常工作中。特别是关于“反馈循环”和“持续集成/持续部署（CI/CD）”的那几章，我简直是茅塞顿开。作者没有回避实践中的陷阱，而是直接点出“为什么你的持续集成会失败”，然后给出了一套非常实用的排错清单。我按照书里的建议，重新梳理了我们的发布流程，压缩了平均部署时间近40%。现在，团队的士气明显高涨，因为大家都能看到代码的价值能更快地交付给用户，而不是被冗长的测试和合并流程卡住。对于那些在追求效率和质量之间挣扎的团队领导来说，这本书提供的框架是立竿见影的指导手册，绝对是值得反复研读的宝藏。
评分我刚从一个以“瀑布模型”为核心的项目中脱身，那段经历简直是一场噩梦，充满了无休止的文档迭代和临近上线时的“需求雪崩”。带着对现代软件开发方法论的强烈渴望，我翻开了这本书，本以为它会像市面上大多数书籍一样，鼓吹一套完美的、不切实际的“新范式”。然而，这本书的叙事角度非常接地气，它承认了现实世界中的混乱和妥协。令我印象深刻的是关于“技术债务管理”的那部分内容。作者没有简单粗暴地要求“立即重构所有老代码”，而是提供了一套基于业务风险评估的债务清理路线图，教你如何与产品经理谈判，让他们理解为什么清理那块“看起来很稳定但底层架构已经腐朽”的模块，比增加一个新功能更有长期价值。这种将技术决策与商业目标紧密挂钩的思维方式，彻底改变了我过去那种只埋头写代码的工程师视角。这本书的语言风格非常沉稳，论证严密，读起来就像是听一位经验丰富、阅历深厚的首席架构师在为你做一对一的职业咨询，每一个建议都带着厚重的实践分量，让你信服。
评分这本书的版面设计和内容组织方式，让我这个习惯于快速检索信息的读者感到非常舒适。它不是那种需要从头读到尾的叙事小说，而是更像一本可随时查阅的“故障排除手册”。我特别欣赏它对“可观测性”这一主题的处理。它不仅仅停留在 Prometheus 或 ELK Stack 的配置层面，而是深入探讨了如何设计出能回答“为什么系统会这样表现”而不是仅仅报告“系统出问题了”的日志和指标体系。书中划分了“健康指标”、“业务指标”和“系统指标”三个层次，并清晰地描述了不同角色（开发、运维、业务分析师）应该关注哪些层次的指标。这极大地帮助我们团队打破了“监控就是看CPU和内存”的传统认知。当我需要快速理解一个新上线的微服务在生产环境中的表现时，这本书提供的那套指标体系框架，能让我迅速定位问题所在的服务边界和瓶颈。对于那些正处于从传统运维向 SRE 模型过渡的团队来说，这种结构化的指导是无可替代的。
评分很不错的一个清单参考书。
评分很不错的一个清单参考书。
评分很不错的一个清单参考书。
评分很不错的一个清单参考书。
评分第二章介绍的50个最佳实践比较有价值！
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有