[正版] 软件开发的201个原则 bi读经典简装本 需求工程师设计原则编码测试管理产品保证演变原则书籍

        店铺公告

  为保障消费者合理购买需求及公平交易机会，避免因非生活消费目的的购买货囤积商品，抬价转售等违法行为发生，店铺有权对异常订单不发货且不进行赔付。异常订单：包括但不限于相同用户ID批量下单，同一用户（指不同用户ID，存在相同/临近/虚构收货地址，或相同联系号码，收件人，同账户付款人等情形的）批量下单（一次性大于5本），以及其他非消费目的的交易订单。

温馨提示：请务必当着快递员面开箱验货，如发现破损，请立即拍照拒收，如验货有问题请及时联系在线客服处理，（如开箱验货时发现破损，所产生运费由我司承担，一经签收即为货物完好，如果您未开箱验货，一切损失就需要由买家承担，所以请买家一定要仔细验货）。

  关于退货运费：对于下单后且物流已发货货品在途的状态下，原则上均不接受退货申请，如顾客原因退货需要承担来回运费，如因产品质量问题（非破损问题）可在签收后，联系在线客服。

 

 

软件工程是一门工程学科，是对经过验证的原则、技术、语言和工具的智慧的运用，用于有成本效益的创造和维护能够满足用户需求的软件。 本书汇总了软件工程原则，对于软件研发中的主要思想，以一系列分类原则的方式，给出了总结。原则是关于软件工程的基本原理、规则或结论，不管所选的技术、工具或语言是什么，这些原则都有效。 全书共9章，*1章为引言，后面8章将201个软件工程的原则划分为8个大的类别：一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。

*1章 引言 ................................................................................... 3
*2章 一般原则 ........................................................................... 7
原则1 质量*一 ................................................................. 8
原则2 质量在每个人眼中都不同 ....................................... 9
原则3 开发效率和质量密不可分 .....................................10
原则4 高质量软件是可以实现的 .....................................11
原则5 不要试图通过改进软件实现高质量 ......................12
原则6 低可靠性比低效率更糟糕 .....................................13
原则7 尽早把产品交给客户.............................................14
原则8 与客户/用户沟通 ...................................................15
原则9 促使*发者与客户的目标一致 .............................16
原则10 做好抛弃的准备 ..................................................17
原则11 开发正确的原型 ..................................................18
原则12 构建合适功能的原型 ..........................................19
原则13 要快速地开发一次性原型 ...................................20
原则14 渐进地扩展系统 ..................................................21
原则15 看到越多，需要越多 ..........................................22
原则16 开发过程中的变化是不可避免的 ........................23
原则17 只要可能，购买而非开发 ...................................24
原则18 让软件只需简短的用户手册 ...............................25
原则19 每个复杂问题都有一个解决方案 ........................26
原则20 记录你的假设 ......................................................27
原则21 不同的阶段，使用不同的语言 ...........................28
原则22 技术优先于工具 ..................................................29
原则23 使用工具，但要务实 ..........................................30
原则24 把工具交给*秀的工程师 ...................................31
原则25 CASE工具是昂贵的 ...........................................32
原则26 “知道何时”和“知道如何”同样重要 ............33
原则27 实现目标就停止 ..................................................34
原则28 了解形式化方法 ..................................................35
原则29 和组织荣辱与共 ..................................................36
原则30 跟风要小心 ..........................................................37
原则31 不要忽视技术 ......................................................38
原则32 使用文档标准 ......................................................39
原则33 文档要有术语表 ..................................................40
原则34 软件文档都要有索引 ..........................................41
原则35 对相同的概念用相同的名字 ...............................42
原则36 研究再转化，不可行 ..........................................43
原则37 要承担责任 ..........................................................44
第3章 需求工程原则 .................................................................. 47
原则38 低质量的需求分析，导致低质量的成本估算 .....48
原则39 先确定问题，再写需求 .......................................49
原则40 立即确定需求 ......................................................50
原则41 立即修复需求规格说明中的错误 ........................51
原则42 原型可降低选择用户界面的风险 ........................52
原则43 记录需求为什么被引入 .......................................53
原则44 确定子集 .............................................................54
原则45 评审需求 .............................................................55
原则46 避免在需求分析时进行系统设计 ........................56
原则47 使用正确的方法 ..................................................57
原则48 使用多角度的需求视图 .......................................58
原则49 合理地组织需求 ..................................................59
原则50 给需求排列优先级 ..............................................60
原则51 书写要简洁 ..........................................................61
原则52 给每个需求单独编号 ..........................................62
原则53 减少需求中的歧义 ..............................................63
原则54 对自然语言辅助增强，而非替换 ........................64
原则55 在更形式化的模型前，先写自然语言 ................65
原则56 保持需求规格说明的可读性 ...............................66
原则57 明确规定可靠性 ..................................................67
原则58 应明确环境超出“可接受”时的系统行为 ........68
原则59 自毁的待定项 ......................................................69
原则60 将需求保存到数据库 ..........................................70
第4章 设计原则 ......................................................................... 73
原则61 从需求到设计的转换并不容易 ...........................74
原则62 将设计追溯到需求 ..............................................75
原则63 评估备选方案 ......................................................76
原则64 没有文档的设计不是设计 ...................................77
原则65 封装 .....................................................................78
原则66 不要重复造轮子 ..................................................79
原则67 保持简单 .............................................................80
原则68 避免大量的特殊案例 ..........................................81
原则69 缩小智力距离 ......................................................82
原则70 将设计置于知识控制之下 ...................................83
原则71 保持概念一致 ......................................................84
原则72 概念性错误比语法错误更严重 ...........................85
原则73 使用耦合和内聚 ..................................................86
原则74 为变化而设计 ......................................................87
原则75 为维护而设计 ......................................................88
原则76 为防备出现错误而设计 .......................................89
原则77 在软件中植入通用性 ..........................................90
原则78 在软件中植入灵活性 ..........................................91
原则79 使用高效的算法 ..................................................92
原则80 模块规格说明只提供用户需要的所有信息 ........93
原则81 设计是多维的 ......................................................94
原则82 *秀的设计出自*秀的设计师 ...........................95
原则83 理解你的应用场景 ..............................................96
原则84 无须太多投资，即可实现复用 ...........................97
原则85 “错进错出”是不正确的 ...................................98
原则86 软件可靠性可以通过冗余来实现 ........................99
第5章 编码原则 ....................................................................... 101
原则87 避免使用特殊技巧 ............................................102
原则88 避免使用全局变量 ............................................103
原则89 编写可自上而下阅读的程序 .............................104
原则90 避免副作用 ........................................................105
原则91 使用有意义的命名 ............................................106
原则92 程序首先是写给人看的 .....................................107
原则93 使用*优的数据结构 ........................................108
原则94 先确保正确，再提升性能 .................................109
原则95 在写完代码之前写注释 .....................................110
原则96 先写文档后写代码 ............................................111
原则97 手动运行每个组件 ............................................112
原则98 代码审查 ...........................................................113
原则99 你可以使用非结构化的语言 .............................114
原则100 结构化的代码未必是好的代码 .......................115
原则101 不要嵌套太深 ..................................................116
原则102 使用合适的语言 ..............................................117
原则103 编程语言不是借口 ..........................................118
原则104 编程语言的知识没那么重要 ...........................119
原则105 格式化你的代码 ..............................................120
原则106 不要太早编码 ..................................................121
第6章 测试原则 ....................................................................... 123
原则107 依据需求跟踪测试 ..........................................124
原则108 在测试之前早做测试计划 ...............................125
原则109 不要测试自己开发的软件 ...............................126
原则110 不要为自己的软件做测试计划 .......................127
原则111 测试只能揭示缺陷的存在 ...............................128
原则112 虽然大量的错误可证明软件毫无价值，
但是零错误并不能说明软件的价值 ................129
原则113 成功的测试应发现错误 ...................................130
原则114 半数的错误出现在15%的模块中 ...................131
原则115 使用黑盒测试和白盒测试 ...............................132
原则116 测试用例应包含期望的结果 ...........................133
原则117 测试不正确的输入 ..........................................134
原则118 压力测试必不可少 ..........................................135
原则119 大爆炸理论不适用 ..........................................136
原则120 使用 McCabe 复杂度指标 ............................137
原则121 使用有效的测试完成度标准 ...........................138
原则122 达成有效的测试覆盖 ......................................139
原则123 不要在单元测试之前集成 ...............................140
原则124 测量你的软件 ..................................................141
原则125 分析错误的原因 ..............................................142
原则126 对“错”不对人 ..............................................143
第7章 管理原则 ....................................................................... 145
原则127 好的管理比好的技术更重要 ...........................146
原则128 使用恰当的方法 ..............................................147
原则129 不要相信你读到的一切 ...................................148
原则130 理解客户的优先级 ..........................................149
原则131 人是成功的关键 ..............................................150
原则132 几个好手要强过很多生手 ...............................151
原则133 倾听你的员工 ..................................................152
原则134 信任你的员工 ..................................................153
原则135 期望*秀 .........................................................154
原则136 沟通技巧是必要的 ..........................................155
原则137 端茶送水 .........................................................156
原则138 人们的动机是不同的 ......................................157
原则139 让办公室保持安静 ..........................................158
原则140 人和时间是不可互换的 ...................................159
原则141 软件工程师之间存在巨大的差异 ....................160
原则142 你可以优化任何你想要优化的 .......................161
原则143 隐蔽地收集数据 ..............................................162
原则144 每行代码的成本是没用的 ...............................163
原则145 衡量开发效率没有*美的方法 .......................164
原则146 剪裁成本估算方法 ..........................................165
原则147 不要设定不切实际的截止时间 .......................166
原则148 避免不可能 ......................................................167
原则149 评估之前先要了解 ..........................................168
原则150 收集生产力数据 ..............................................169
原则151 不要忘记团队效率 ..........................................170
原则152 LOC/PM与语言无关 .......................................171
原则153 相信排期 .........................................................172
原则154 *确的成本估算并不是万无一失的 ................173
原则155 定期重新评估排期 ..........................................174
原则156 轻微的低估不总是坏事 ...................................175
原则157 分配合适的资源 ..............................................176
原则158 制订详细的项目计划 ......................................177
原则159 及时更新你的计划 ..........................................178
原则160 避免驻波 .........................................................179
原则161 知晓十大风险 ..................................................180
原则162 预先了解风险 ..................................................181
原则163 使用适当的流程模型 ......................................182
原则164 方法无法挽救你 ..............................................183
原则165 没有奇迹般提升效率的秘密 ...........................184
原则166 了解进度的含义 ..............................................185
原则167 按差异管理 ......................................................186
原则168 不要过度使用你的硬件 ...................................187
原则169 对硬件的演化要乐观 ......................................188
原则170 对软件的进化要悲观 ......................................189
原则171 认为灾难是不可能的想法往往导致灾难 ........190
原则172 做项目总结 ......................................................191
第8章 产品保证原则 ................................................................ 193
原则173 产品保证并不是*侈品 ...................................194
原则174 尽早建立软件配置管理过程 ...........................195
原则175 使软件配置管理适应软件过程 .......................196
原则176 组织SCM独立于项目管理 .............................197
原则177 轮换人员到产品保证组织 ...............................198
原则178 给所有中间产品一个名称和版本 ....................199
原则179 控制基准 .........................................................200
原则180 保存所有内容 ..................................................201
原则181 跟踪每一个变更 ..............................................202
原则182 不要绕过变更控制 ..........................................203
原则183 对变更请求进行分级和排期 ...........................204
原则184 在大型开发项目中使用确认和验证（V＆V） ....205
第9章 演变原则 ....................................................................... 207
原则185 软件会持续变化 ..............................................208
原则186 软件的熵增加 ..................................................209
原则187 如果没有坏，就不要修理它 ...........................210
原则188 解决问题，而不是症状 ...................................211
原则189 先变更需求 ......................................................212
原则190 发布之前的错误也会在发布之后出现 ............213
原则191 一个程序越老，维护起来越困难 ....................214
原则192 语言影响可维护性 ..........................................215
原则193 有时重新开始会更好 ......................................216
原则194 首先翻新*差的 ..............................................217
原则195 维护阶段比开发阶段产生的错误更多 ............218
原则196 每次变更后都要进行回归测试 .......................219
原则197 “变更很容易”的想法，会使变更更
容易出错 .........................................................220
原则198 对非结构化代码进行结构化改造，并不
一定会使它更好 ..............................................221
原则199 在优化前先进行性能分析 ...............................222
原则200 保持熟悉 .........................................................223
原则201 系统的存在促进了演变 ...................................224
参考资料索引 ............................................................................... 225

Alan M. Davis是一名计算机科学家（伊利诺伊大学厄巴纳-香槟分校计算机科学博士），他的职业生涯大约有一半在工业界，一半在学术界。他在工业界的经历包括：1.Offtoa公司的联合创始人兼&席执行官，这是一家帮助企业家制定商业战略的互联网公司（2012年到今）。2. Omni-Vista公司的联合创始人、董事长兼&席执行官，这是一家位于科罗拉多斯普林斯的软件公司（1998—2002）。3. Requisite公司的董事会创始成员，被Rational Software收购，后来被IBM收购（1995—1997）。4. BTG公司副总裁，该公司位于弗吉尼亚州，于1995年上市，被Titan收购，随后被L-3 Communications收购（1984—1991）。5. 亚利桑那州凤凰城GTE通信系统的研发总监（1983—1984）。6. 马萨诸塞州沃尔瑟姆GTE实验室的软件工程师、项目经理、部门经理和软件技术总监（1977—1983）。7. 位于科罗拉多斯普林斯的天使俱乐部High Altitude Investors（HAI）的选举委员会成员（2008—2015）。8. 催化剂信息技术发展基金（Catalyst InfoTech Development Fund）的非管理普通合伙人和有限合伙人。催化剂信息技术发展基金是科罗拉多州的一个小型风险投资基金（1995—2002）。他在学术界的经历包括：9. 位于丹佛的科罗拉多大学行政MBA创业教授，前任学术主席（2006—2018）。10. 科罗拉多大学斯普林斯分校的商业策略与企业家精神专业的教授，前El Pomar软件工程教授（1991—2015）。11. 曾在澳大利亚、印度尼西亚、尼日利亚、南非和西班牙等国家担任教职。
本书译者均为百度公司员工，同时也是参加百度培训项目“代码的艺术训练营”的学员，他们是：叶王、马学翔、吴斌、王冰清、杨光、曾浩浩、李殿斌、甘璐、李子昂、肖远昊、贾儒、王莹、张苗、李双婕、荣文升。

本书面向的读者包括软件工程师和管理者、软件工程专业的学生、软件工程领域的研发人员等。

1