《软件开发的201个原则》

目录

前言

一、一般原则

二、需求工程原则

三、设计原则

四、编码原则

五、测试原则

六、管理原则

七、产品保证原则

八、演变原则

总结

---

前言

        《软件开发的201个原则》主要面向以下三类目标读者：

1. 软件工程师和管理者。你可以弄清什么对软件项目是好的，什么是不好的。
2. 软件工程方向的学生。熟悉了解这些原则，能够让你的视野有所提升，不再局限于初步的编码层面，培养软件工程思维方式和基本专业素养。如果将来从事软件相关职业，那么一定会对你的工作有帮助。
3. 软件研究人员。（可能会有帮助。读者没有经历这种角色，待体会）

        作为一名从事软件开发工作的读者，深刻体会到《软件开发原则》书中的系列原则，在我开发过程中处处可见。如果遵循这些原则，那么对你的开发是十分有效的。在项目开发过程格遵守开发流程，让一切异常都有迹可循，有法可解，工作效率显著提示。

一、一般原则

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. 要承担责任

二、需求工程原则

1. 低质量的需求分析，导致低质量的成本估算
2. 先确定问题，再写需求
3. 立即确定需求
4. 立即修复需求规格说明中的错误
5. 原型可降低选择用户界面的风险
6. 记录需求为什么被引入
7. 确认子集
8. 评审需求
9. 避免在需求分析时进行系统设计
10. 使用正确的方法
11. 使用多角度的需求视图
12. 合理地组织需求
13. 给需求排列优先级
14. 书写要简洁
15. 给每个需求单独编号
16. 减少需求中的歧义
17. 对自然语言辅助增强，而非替换
18. 在更形式化的模型前，先写自然语言
19. 保持需求规格说明的可读性
20. 明确规定可靠性
21. 应明确环境超出预期时的系统行为
22. 自毁的待定项
23. 将需求保存到数据库

三、设计原则

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. “错进错出”是不正确的
26. 软件可靠性可以通过冗余来实现 

四、编码原则

1. 避免使用特殊技巧
2. 避免使用全局变量
3. 编写可自上而下阅读的程序
4. 避免副作用
5. 使用有意义的命名
6. 程序首先是写给人看的
7. 使用最优的数据结构
8. 先确保正确，再提升性能
9. 在写完代码之前写注释
10. 先写文档后写代码
11. 手动运行每个组件
12. 代码审查
13. 可以使用非结构化语言
14. 结构化代码未必是好代码
15. 不要嵌套太深
16. 使用合适的语言
17. 编程语言不是借口
18. 编程语言的知识没那么重要
19. 格式化你的代码
20. 不要太早编码

五、测试原则

1. 依据需求跟踪测试
2. 在测试之前早做测试
3. 不要测试自己开发的软件
4. 不要为自己的软件做测试计划
5. 测试只能揭示测试的存在
6. 虽然大量错误可证明软件毫无价值，但是零错误并不能说明软件的价值
7. 成功的测试应该发现错误
8. 半数的错误出现在15%的模块中
9. 使用黑盒测试和白盒测试
10. 测试用例应包含期望的结果
11. 测试不正确的输入
12. 测试压力必不可少
13. 大爆炸理论不适用
14. 使用McCabe复杂度指标
15. 使用有效的测试完成度标准
16. 达成有效的测试覆盖
17. 不要在单元测试之前集成
18. 测量你的软件
19. 分析错误的原因
20. 对“错”不对人

六、管理原则

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. 不要忘记团队效率
26. LOC/PM与语言无关
27. 相信排期
28. 精确的成本估算并不是万无一失的
29. 定期重新评估排期
30. 轻微的低谷不总是坏事
31. 分配合适的资源
32. 制定详细的项目计划
33. 及时更新你的计划
34. 避免驻波
35. 知晓十大风险
36. 预先了解风险
37. 使用适当的流程模型
38. 方法无法挽救你
39. 没有奇迹般提升效率的秘密
40. 了解进度的含义
41. 按差异管理
42. 不要过度使用你的硬件
43. 对硬件的演化要乐观
44. 对软件的进化要悲观
45. 认为灾难是不可能的想法往往导致灾难
46. 做项目总结

七、产品保证原则

1. 产品保证并不是奢侈品
2. 尽早建立软件配置管理过程
3. 使软件配置管理适应软件过程
4. 组织SCM独立于项目管理
5. 轮换人员到产品保证组织
6. 给所有中间产品一个名称和版本
7. 控制基准
8. 保存所有内容
9. 跟踪每一个变更
10. 不要绕过变更控制
11. 对变更请求进行分级和排期
12. 在大型开发项目中使用确认和验证

八、演变原则

1. 软件会持续变化
2. 软件的熵增加
3. 如果没有坏，就不要修理它
4. 解决问题，而不是症状
5. 先变更需求
6. 发布之前的错误也会在发布之后出现
7. 一个程序越老，维护起来越困难
8. 语言影响可维护性
9. 有时重新开始会更好
10. 首先翻新最差的
11. 维护阶段比开发阶段产生的错误更多
12. 每次变更后都要进行回归测试
13. “变更很容易”的想法，会使变更更容易出错
14. 对非结构化代码进行结构化改造，并不一定会使它更好
15. 在优化前先进性性能分析
16. 保持熟悉
17. 系统的存在促进了演变

---

总结

        以上原则有的在求学阶段接了解过一点，当时觉得“软件工程”这门课程，是及其乏味的。当我从事软件开发工作后，发现软件工程是最有用的。举个例子：在我进入职业生涯第一个项目的启动会上，我的项目经理就问了一个问题并指定。“当你遇到Bug时，你应该如何解决？”，按照软件工程思维，我内心的答案是：“记录Bug，找到Bug相关者，分析Bug，解决Bug”。气氛稍微沉默了一会，经理指定我回答······对我的回答，经理还是比较满意的，她问我怎么知道的。没等我回应。“是在新人教育时学到的吧”。我只能说：“是的”（其实，是软件工程课程上学到的）。

        关于此书的好处，我相信在我今后的职业生涯中，定会产生积极而深远的影响。