《软件开发的201个原则》
目录
前言
一、一般原则
二、需求工程原则
三、设计原则
四、编码原则
五、测试原则
六、管理原则
七、产品保证原则
八、演变原则
总结
前言
《软件开发的201个原则》主要面向以下三类目标读者：
- 软件工程师和管理者。你可以弄清什么对软件项目是好的，什么是不好的。
- 软件工程方向的学生。熟悉了解这些原则，能够让你的视野有所提升，不再局限于初步的编码层面，培养软件工程思维方式和基本专业素养。如果将来从事软件相关职业，那么一定会对你的工作有帮助。
- 软件研究人员。（可能会有帮助。读者没有经历这种角色，待体会）
作为一名从事软件开发工作的读者，深刻体会到《软件开发原则》书中的系列原则，在我开发过程中处处可见。如果遵循这些原则，那么对你的开发是十分有效的。在项目开发过程格遵守开发流程，让一切异常都有迹可循，有法可解，工作效率显著提示。
一、一般原则
- 质量第一
- 质量在每个人眼中都不同
- 开发效率和质量密不可分
- 高质量软件是可以实现的
- 不要试图通过改进软件实现高质量
- 低可靠性比低效率更糟糕
- 尽早把产品交给客户
- 与客户用户沟通
- 促进开发者与客户的目标一致
- 做好抛弃的准备
- 开发正确的原型
- 构建合适功能的原型
- 要快速地开发一次性原型
- 渐进地扩展系统
- 看到越多，需要越多
- 开发过程中的变化是不可避免的
- 只要可能，购买而非开发
- 让软件只需简短的用户手册
- 每个复杂问题都有一个解决方案
- 记录你的假设
- 不同阶段使用不同语言
- 技术优先于工具
- 使用工具，但要务实
- 把工具交给优秀的工程师
- CASE实现目标就停止
- 工具是昂贵的
- “知道何时”和“知道如何”同样重要
- 了解形式化方式
- 和组织荣辱与共
- 跟风要小心
- 不要忽视技术
- 使用文档标准
- 文档要有术语表
- 软件文档都要有索引
- 对相同的概念用相同的名字
- 研究再转化，不可行
- 要承担责任
二、需求工程原则
- 低质量的需求分析，导致低质量的成本估算
- 先确定问题，再写需求
- 立即确定需求
- 立即修复需求规格说明中的错误
- 原型可降低选择用户界面的风险
- 记录需求为什么被引入
- 确认子集
- 评审需求
- 避免在需求分析时进行系统设计
- 使用正确的方法
- 使用多角度的需求视图
- 合理地组织需求
- 给需求排列优先级
- 书写要简洁
- 给每个需求单独编号
- 减少需求中的歧义
- 对自然语言辅助增强，而非替换
- 在更形式化的模型前，先写自然语言
- 保持需求规格说明的可读性
- 明确规定可靠性
- 应明确环境超出预期时的系统行为
- 自毁的待定项
- 将需求保存到数据库
三、设计原则
- 从需求到设计的转换并不容易
- 将设计追溯到需求
- 评估备选方案
- 没有文档的设计不是设计
- 封装
- 不要重复造轮子
- 保持简单
- 避免大量的特殊案例
- 缩小智力距离
- 将设计置于知识控制之下
- 保持概念一致
- 概念性错误比语法性错误更严重
- 使用耦合和内聚
- 为变化而设计
- 为维护而设计
- 为防备出现错误而设计
- 在软件中植入通用性
- 在软件中植入灵活性
- 使用高效的算法
- 模块规格说明只提供用户需要的所有信息
- 设计是多维的
- 优秀的设计出自优秀的设计师
- 理解你的应用场景
- 无须太多投资，即可实现复用
- “错进错出”是不正确的
- 软件可靠性可以通过冗余来实现
四、编码原则
- 避免使用特殊技巧
- 避免使用全局变量
- 编写可自上而下阅读的程序
- 避免副作用
- 使用有意义的命名
- 程序首先是写给人看的
- 使用最优的数据结构
- 先确保正确，再提升性能
- 在写完代码之前写注释
- 先写文档后写代码
- 手动运行每个组件
- 代码审查
- 可以使用非结构化语言
- 结构化代码未必是好代码
- 不要嵌套太深
- 使用合适的语言
- 编程语言不是借口
- 编程语言的知识没那么重要
- 格式化你的代码
- 不要太早编码
五、测试原则
- 依据需求跟踪测试
- 在测试之前早做测试
- 不要测试自己开发的软件
- 不要为自己的软件做测试计划
- 测试只能揭示测试的存在
- 虽然大量错误可证明软件毫无价值，但是零错误并不能说明软件的价值
- 成功的测试应该发现错误
- 半数的错误出现在15%的模块中
- 使用黑盒测试和白盒测试
- 测试用例应包含期望的结果
- 测试不正确的输入
- 测试压力必不可少
- 大爆炸理论不适用
- 使用McCabe复杂度指标
- 使用有效的测试完成度标准
- 达成有效的测试覆盖
- 不要在单元测试之前集成
- 测量你的软件
- 分析错误的原因
- 对“错”不对人
六、管理原则
- 好的管理比好的技术更重要
- 使用恰当的方法
- 不要相信你读到的一切
- 理解客户的优先级
- 人是成功的关键
- 几个好手要强过很多生手
- 倾听你的员工
- 信任你的员工
- 期望优秀
- 沟通技巧是必要的
- 端茶送水
- 人们的动机是不同的
- 让办公室保持安静（博主觉得应该保持适度安静）
- 人和时间是不可互换的
- 软件工程师之间存在巨大差异
- 可以优化任何想要优化的
- 隐蔽地收集数据
- 每行代码的成本是没用的
- 衡量开发效率没有完美的方法
- 剪裁成本估算方法
- 不要设定不切实际的截止时间
- 避免不可能
- 评估之前要先了解
- 收集生产力数据
- 不要忘记团队效率
- LOC/PM与语言无关
- 相信排期
- 精确的成本估算并不是万无一失的
- 定期重新评估排期
- 轻微的低谷不总是坏事
- 分配合适的资源
- 制定详细的项目计划
- 及时更新你的计划
- 避免驻波
- 知晓十大风险
- 预先了解风险
- 使用适当的流程模型
- 方法无法挽救你
- 没有奇迹般提升效率的秘密
- 了解进度的含义
- 按差异管理
- 不要过度使用你的硬件
- 对硬件的演化要乐观
- 对软件的进化要悲观
- 认为灾难是不可能的想法往往导致灾难
- 做项目总结
七、产品保证原则
- 产品保证并不是奢侈品
- 尽早建立软件配置管理过程
- 使软件配置管理适应软件过程
- 组织SCM独立于项目管理
- 轮换人员到产品保证组织
- 给所有中间产品一个名称和版本
- 控制基准
- 保存所有内容
- 跟踪每一个变更
- 不要绕过变更控制
- 对变更请求进行分级和排期
- 在大型开发项目中使用确认和验证
八、演变原则
- 软件会持续变化
- 软件的熵增加
- 如果没有坏，就不要修理它
- 解决问题，而不是症状
- 先变更需求
- 发布之前的错误也会在发布之后出现
- 一个程序越老，维护起来越困难
- 语言影响可维护性
- 有时重新开始会更好
- 首先翻新最差的
- 维护阶段比开发阶段产生的错误更多
- 每次变更后都要进行回归测试
- “变更很容易”的想法，会使变更更容易出错
- 对非结构化代码进行结构化改造，并不一定会使它更好
- 在优化前先进性性能分析
- 保持熟悉
- 系统的存在促进了演变
总结
以上原则有的在求学阶段接了解过一点，当时觉得“软件工程”这门课程，是及其乏味的。当我从事软件开发工作后，发现软件工程是最有用的。举个例子：在我进入职业生涯第一个项目的启动会上，我的项目经理就问了一个问题并指定。“当你遇到Bug时，你应该如何解决？”，按照软件工程思维，我内心的答案是：“记录Bug，找到Bug相关者，分析Bug，解决Bug”。气氛稍微沉默了一会，经理指定我回答······对我的回答，经理还是比较满意的，她问我怎么知道的。没等我回应。“是在新人教育时学到的吧”。我只能说：“是的”（其实，是软件工程课程上学到的）。
关于此书的好处，我相信在我今后的职业生涯中，定会产生积极而深远的影响。