软件开发的 201 个原则 – Alan M. Davis

《软件开发的 201 个原则》 – [美] Alan M. Davis 著 叶王 马学翔 吴斌 王冰清 等译 章淼 审定

第 1 章 引言

第 2 章 一般原则

  • 原则 1 质量第一
  • 原则 2 质量在每个人眼中都不同
  • 原则 3 开发效率和质量密不可分
  • 原则 4 高质量软件是可以实现的
  • 原则 5 不要试图通过改进软件实现高质量
  • 原则 6 低可靠性比低效率更糟糕
  • 原则 7 尽早把产品交给客户
  • 原则 8 与客户/用户沟通
  • 原则 9 促使开发者与客户的目标一致
  • 原则 10 做好抛弃的准备
  • 原则 11 开发正确的原型
  • 原则 12 构建合适功能的原型
  • 原则 13 要快速地开发一次性原型
  • 原则 14 渐进地扩展系统
  • 原则 15 看到越多，需要越多
  • 原则 16 开发过程中的变化是不可避免的
  • 原则 17 只要可能，购买而非开发
  • 原则 18 让软件只需简短的用户手册
  • 原则 19 每个复杂问题都有一个解决方案
  • 原则 20 记录你的假设
  • 原则 21 不同的阶段，使用不同的语言
  • 原则 22 技术优先于工具
  • 原则 23 使用工具，但要务实
  • 原则 24 把工具交给优秀的工程师
  • 原则 25 CASE 工具是昂贵的
  • 原则 26“知道何时”和“知道如何”同样重要
  • 原则 27 实现目标就停止
  • 原则 28 了解形式化方法
  • 原则 29 和组织荣辱与共
  • 原则 30 跟风要小心
  • 原则 31 不要忽视技术
  • 原则 32 使用文档标准
  • 原则 33 文档要有术语表
  • 原则 34 软件文档都要有索引
  • 原则 35 对相同的概念用相同的名字
  • 原则 36 研究再转化，不可行
  • 原则 37 要承担责任

第 3 章 需求工程原则

  • 原则 38 低质量的需求分析，导致低质量的成本估算
  • 原则 39 先确定问题，再写需求
  • 原则 40 立即确定需求
  • 原则 41 立即修复需求规格说明中的错误
  • 原则 42 原型可降低选择用户界面的风险
  • 原则 43 记录需求为什么被引入
  • 原则 44 确定子集
  • 原则 45 评审需求
  • 原则 46 避免在需求分析时进行系统设计
  • 原则 47 使用正确的方法
  • 原则 48 使用多角度的需求视图
  • 原则 49 合理地组织需求
  • 原则 50 给需求排列优先级
  • 原则 51 书写要简洁
  • 原则 52 给每个需求单独编号
  • 原则 53 减少需求中的歧义
  • 原则 54 对自然语言辅助增强，而非替换
  • 原则 55 在更形式化的模型前，先写自然语言
  • 原则 56 保持需求规格说明的可读性
  • 原则 57 明确规定可靠性
  • 原则 58 应明确环境超出预期时的系统行为
  • 原则 59 自毁的待定项
  • 原则 60 将需求保存到数据库

第 4 章 设计原则

  • 原则 61 从需求到设计的转换并不容易
  • 原则 62 将设计追溯至需求
  • 原则 63 评估备选方案
  • 原则 64 没有文档的设计不是设计
  • 原则 65 封装
  • 原则 66 不要重复造轮子
  • 原则 67 保持简单
  • 原则 68 避免大量的特殊案例
  • 原则 69 缩小智力距离
  • 原则 70 将设计置于知识控制之下
  • 原则 71 保持概念一致
  • 原则 72 概念性错误比语法错误更严重
  • 原则 73 使用耦合和内聚
  • 原则 74 为变化而设计
  • 原则 75 为维护而设计
  • 原则 76 为防备出现错误而设计
  • 原则 77 在软件中植入通用性
  • 原则 78 在软件中植入灵活性
  • 原则 79 使用高效的算法
  • 原则 80 模块规格说明只提供用户需要的所有信息
  • 原则 81 设计是多维的
  • 原则 82 优秀的设计出自优秀的设计师
  • 原则 83 理解你的应用场景
  • 原则 84 无须太多投资，即可实现复用
  • 原则 85“错进错出”是不正确的
  • 原则 86 软件可靠性可以通过冗余来实现

第 5 章 编码原则

  • 原则 87 避免使用特殊技巧
  • 原则 88 避免使用全局变量
  • 原则 89 编写可自上而下阅读的程序
  • 原则 90 避免副作用
  • 原则 91 使用有意义的命名
  • 原则 92 程序首先是写给人看的
  • 原则 93 使用最优的数据结构
  • 原则 94 先确保正确，再提升性能
  • 原则 95 在写完代码之前写注释
  • 原则 96 先写文档后写代码
  • 原则 97 手动运行每个组件
  • 原则 98 代码审查
  • 原则 99 你可以使用非结构化的语言
  • 原则 100 结构化的代码未必是好的代码
  • 原则 101 不要嵌套太深
  • 原则 102 使用合适的语言
  • 原则 103 编程语言不是借口
  • 原则 104 编程语言的知识没那么重要
  • 原则 105 格式化你的代码
  • 原则 106 不要太早编码

第 6 章 测试原则

  • 原则 107 依据需求跟踪测试
  • 原则 108 在测试之前早做测试计划
  • 原则 109 不要测试自己开发的软件
  • 原则 110 不要为自己的软件做测试计划
  • 原则 111 测试只能揭示缺陷的存在
  • 原则 112 虽然大量的错误可证明软件毫无价值，但是零错误并不能说明软件的价值
  • 原则 113 成功的测试应发现错误
  • 原则 114 半数的错误出现在 15% 的模块中
  • 原则 115 使用黑盒测试和白盒测试
  • 原则 116 测试用例应包含期望的结果
  • 原则 117 测试不正确的输入
  • 原则 118 压力测试必不可少
  • 原则 119 大爆炸理论不适用
  • 原则 120 使用 McCabe 复杂度指标
  • 原则 121 使用有效的测试完成度标准
  • 原则 122 达成有效的测试覆盖
  • 原则 123 不要在单元测试之前集成
  • 原则 124 测量你的软件
  • 原则 125 分析错误的原因
  • 原则 126 对“错”不对人

第 7 章 管理原则

  • 原则 127 好的管理比好的技术更重要
  • 原则 128 使用恰当的方法
  • 原则 129 不要相信你读到的一切
  • 原则 130 理解客户的优先级
  • 原则 131 人是成功的关键
  • 原则 132 几个好手要强过很多生手
  • 原则 133 倾听你的员工
  • 原则 134 信任你的员工
  • 原则 135 期望优秀
  • 原则 136 沟通技巧是必要的
  • 原则 137 端茶送水
  • 原则 138 人们的动机是不同的
  • 原则 139 让办公室保持安静
  • 原则 140 人和时间是不可互换的
  • 原则 141 软件工程师之间存在巨大的差异
  • 原则 142 你可以优化任何你想要优化的
  • 原则 143 隐蔽地收集数据
  • 原则 144 每行代码的成本是没用的
  • 原则 145 衡量开发效率没有完美的方法
  • 原则 146 剪裁成本估算方法
  • 原则 147 不要设定不切实际的截止时间
  • 原则 148 避免不可能
  • 原则 149 评估之前先要了解
  • 原则 150 收集生产力数据
  • 原则 151 不要忘记团队效率
  • 原则 152 LOC/PM与语言无关
  • 原则 153 相信排期
  • 原则 154 精确的成本估算并不是万无一失的
  • 原则 155 定期重新评估排期
  • 原则 156 轻微的低估不总是坏事
  • 原则 157 分配合适的资源
  • 原则 158 制订详细的项目计划
  • 原则 159 及时更新你的计划
  • 原则 160 避免驻波
  • 原则 161 知晓十大风险
  • 原则 162 预先了解风险
  • 原则 163 使用适当的流程模型
  • 原则 164 方法无法挽救你
  • 原则 165 没有奇迹般提升效率的秘密
  • 原则 166 了解进度的含义
  • 原则 167 按差异管理
  • 原则 168 不要过度使用你的硬件
  • 原则 169 对硬件的演化要乐观
  • 原则 170 对软件的进化要悲观
  • 原则 171 认为灾难是不可能的想法往往导致灾难
  • 原则 172 做项目总结

第 8 章 产品保证原则

  • 原则 173 产品保证并不是奢侈品
  • 原则 174 尽早建立软件配置管理过程
  • 原则 175 使软件配置管理适应软件过程
  • 原则 176 组织 SCM 独立于项目管理
  • 原则 177 轮换人员到产品保证组织
  • 原则 178 给所有中间产品一个名称和版本
  • 原则 179 控制基准
  • 原则 180 保存所有内容
  • 原则 181 跟踪每一个变更
  • 原则 182 不要绕过变更控制
  • 原则 183 对变更请求进行分级和排期
  • 原则 184 在大型开发项目中使用确认和验证（V&V）

第 9 章 演变原则

  • 原则 185 软件会持续变化
  • 原则 186 软件的熵增加
  • 原则 187 如果没有坏，就不要修理它
  • 原则 188 解决问题，而不是症状
  • 原则 189 先变更需求
  • 原则 190 发布之前的错误也会在发布之后出现
  • 原则 191 一个程序越老，维护起来越困难
  • 原则 192 语言影响可维护性
  • 原则 193 有时重新开始会更好
  • 原则 194 首先翻新最差的
  • 原则 195 维护阶段比开发阶段产生的错误更多
  • 原则 196 每次变更后都要进行回归测试
  • 原则 197“变更很容易”的想法，会使变更更容易出错
  • 原则 198 对非结构化代码进行结构化改造，并不一定会使它更好
  • 原则 199 在优化前先进行性能分析
  • 原则 200 保持熟悉
  • 原则 201 系统的存在促进了演变