软件开发的２０１个原则
2021-12-31 13:10:28 0 举报AI智能生成
<<软件开发的２０１个原则>>思维导图 + 分析
作者其他创作
大纲/内容
原则１质量第一
原则 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 要承担责任
第 1 部分 一般原则
原则 38 低质量的需求分析，导致低质量的成本估算
原则 39 先确定问题，再写需求
原则 40 立即确定需求
原则 41 立即修复需求规格说明中的错误
原则 42 原型可降低选择用户界面的风险
原则 43 记录需求为什么被引入
原则 44 确定子集
原则 45 评审需求
原则 46 避免在需求分析时进行系统设计
原则 47 使用正确的方法
原则 48 使用多角度的需求视图
原则 49 合理地组织需求
原则 50 给需求排优先级
原则 51 书写要简洁
原则 52 给每个需求单独编号
原则 53 减少需求中的歧义
原则 54 对自然语言辅助增强，而非替换
原则 55 在更形式化的模型前，先写自然语言
原则 56 保持需求规格说明的可读性
原则 57 明确规定可靠性
原则 58 应明确环境超出“可接受”时的系统行为
原则 59 自毁的待定项
原则 60 将需求保存到数据库
第 2 部分 需求工程原则
原则 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 软件可靠性可以通过冗余来实现
第 3 部分 设计原则
原则 87 避免使用特殊技巧
原则 88 避免使用全局变量
原则 89 编写可自上而下阅读的程序
原则 90 避免副作用
原则 91 使用有意义的命名
原则 92 程序首先是写给人看的
原则 93 使用最优的数据结构
原则 94 先确保正确，再提升性能
原则 95 在写完代码之前写注释
原则 96 先写文档后写代码
原则 97 手动运行每个组件
原则 98 代码审查
原则 99 你可以使用非结构化的语言
原则 100 结构化的代码，未必是好的代码
原则 101 不要嵌套太深
原则 102 使用合适的语言
原则 103 编程语言不是借口
原则 104 编程语言的知识没那么重要
原则 105 格式化你的代码
原则 106 不要太早编码
第４部分 编码原则
原则 107 依据需求跟踪测试
原则 108 在测试之前早做测试计划
原则 109 不要测试自己开发的软件
原则 110 不要为自己的软件做测试计划
原则 111 测试只能揭示缺陷的存在
原则 112 虽然大量的错误可证明毫无价值，但是
原则 112 虽然大量的错误可证明毫无价值，但是零错误并不能说明软件的价值
原则 113 成功的测试应发现错误
原则 114 半数的错误出现在 15% 的模块中
原则 115 使用黑盒测试和白盒测试
原则 116 测试用例应包含期望的结果
原则 117 测试不正确的输入
原则 118 压力测试必不可少
原则 119 大爆炸理论不适用
原则 120 使用 McCabe 复杂度指标
原则 121 使用有效的测试完成度标准
原则 122 达成有效的测试覆盖
原则 123 不要在单元测试之前集成
原则 124 测量你的软件
原则 125 分析错误的原因
原则 126 对“错”不对人
第５部分 测试原则
原则 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 做项目总结
第６部分 管理原则
原则 173 产品保证并不是奢侈品
原则 174 尽早建立软件配置管理过程
原则 175 使软件配置管理适应软件过程
原则 176 组织 SCM 独立于项目管理
原则 177 轮换人员到产品保证
原则 178 给所有中间产品一个名称和版本
原则 179 控制基准
原则 180 保存所有内容
原则 181 跟踪每一个变更
原则 182 不要绕过变更控制
原则 183 对变更请求进行分级和排期
原则 184 在大型开发项目使用确认和验证（V&V）
第７部分 产品保证原则
原则 185 软件会持续变化
原则 186 软件的熵增加
原则 187 如果没有坏就不要修理它
原则 188 解决问题，而不是症状
原则 189 先变更需求
原则 190 发布之前的错误也会在发布后出现
原则 191 一个程序越老，维护起来就越困难
原则 192 语言影响可维护性
原则 193 有时重新开始会更好
原则 194 首先翻新最差的
原则 195 维护阶段比开发阶段产生的错误更多
原则 196 每次变更后都要进行回归测试
原则 197 “变更很容易”的想法，会使变更更容易出错
原则 198 对非结构化代码进行结构化改造，并不一定会使它更好
原则 199 在优化前先进行性能分析
原则 200 保持熟悉
原则 201 系统的存在促进了演变
第８部分 演变原则
软件开发的２０１个原则
收藏
收藏
0 条评论
回复 删除
下一页
