[敬请读者注意] 本人保留本文的全部著作权利。如果哪位读者使用本文所描述内容，请务必如实引用并明白注明本文出处。如果本人发现任何人擅自使用本文任何部分内容而不明白注明出处，恕本人在网上广泛公布侵权者姓名。敬请各位读者注意，谢谢！

201条软件开发经验原则

程京德 

    软件工程”是为了保证大规模软件系统的高可靠性，研究以系统化的、规范化的、可量化的、过程化的工程方法去定义、设计、开发和维护软件系统，以及如何将这些方法应用到工程实践的工程专业学科。软件工程界归纳总结的软件开发经验原则，在工程实践中相当有效。

    美国计算机科学家 Alan Mark Davis [IEEE Fellow(1994-)，IEEE Life Fellow(2015-), 在产业界和大学都有过职业经历，担任过几个著名学术杂志的编辑，“Communications of the ACM”编辑(1981-1991)，Journal of Systems and Software”编辑(1987-2010)，“IEEE-CS Software”杂志主编(1994-1998)，“Requirements Engineering Journal”编辑(2005-2011)] 收集归纳了201条软件开发经验原则并汇编成书“201 Principles of Software Development”[1]。该书是第一本（也是迄今为止唯一的一本）覆盖软件生存周期各个阶段的、汇集了众多软件开发经验原则的专业参考书，被誉为“软件开发工作者手边必备的圣经/手册”,并且曾在2006年被 ACM 会员投票选为20本计算机科学经典书籍之一。

    如同有的评论所说：“有效软件开发的许多重要原则都是永恒的。它们独立于开发生命周期或模型、编程语言、应用程序类型等。虽然这本书已经有些年了，但几乎所有的内容仍然有效。201条原则涵盖了软件工程的方方面面：一般原则、需求工程、设计、编码、测试、管理、产品保证和演进。…… 年轻的软件人员有一种不幸的倾向，即忽视过去的知识，认为它们与他们无关。这是不对的。这本书可以帮助弥补任何执业软件开发人员知识方面的重大差距。(Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. …… There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.)”

    本文以下部分为笔者对上述 Davis 书中软件开发经验原则的编译（省略了经验原则的详细说明等），是笔者历年给国内大学讲授“软件工程”课程的教学材料之一，现提供给有兴趣的读者参考。

一般原则

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

需求工程原则

    原则38. 蹩脚的需求会导致蹩脚的成本估算

    原则39. 编写需求前先确定问题

    原则40. 对于需求，现在能做什么就立刻做

    原则41. 发现需求规范错误就立即修改

    原则42. 原型可降低用户界面选择的风险

    原则43. 记录下需求被包含的原因

    原则44. 识别子集

    原则45. 审查需求

    原则46. 不得在需求分析定义中进行设计

    原则47. 使用正确的技术

    原则48. 从多个角度去审视需求

    原则49. 合理地组织化需求规范定义文档

    原则50. 确定需求的优先级

    原则51. 简洁地编写

    原则52. 对每个需求分别编号

    原则53. 减少需求中的歧义

    原则54. 增强而非替代自然语言

    原则55. 在更形式化的模型之前使用自然语言

    原则56. 保持需求规范的可读性

    原则57. 对于可靠性要特别规定

    原则58. 规定当环境违反“可接受”行为时的对处

    原则59. 将未决项目与使其自己消亡的注释一同描述

    原则60. 将需求规范存储在数据库中

设计原则

    原则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. 软件可靠性可以通过冗余实现

编码原则

    原则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. 虽然大量错误显示软件毫无价值，但零错误并不能说明软件的价值

    原则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. “行数/人月”独立于语言

    原则153. 相信日程表

    原则154. 精心编制的成本估算也并非万无一失

    原则155. 定期重新评估进度表

    原则156. 轻微低估并非总是坏事

    原则157. 分配适当的资源

    原则158. 详细地规划项目

    原则159. 保持计划最新

    原则160. 避免一波比一波增幅的计划变更

    原则161. 了解十大风险

    原则162. 了解当前风险

    原则163. 使用适当的过程模型

    原则164. 方法不会拯救你

    原则165. 奇迹般提高生产力没有秘诀

    原则166. 了解进展意味着什么

    原则167. 通过差异管理

    原则168. 不要过负荷地使用硬件

    原则169. 对硬件进化发展持乐观态度

    原则170. 对软件进化发展持悲观态度

    原则171. 认为灾难不可能发生的想法往往会导致灾难

    原则172. 进行项目事后分析

产品保证原则

    原则173. 产品保证不是奢侈品

    原则174. 尽早建立软件构成管理手续

    原则175. 使软件构成管理适应软件过程

    原则176. 组织软件构成管理以独立于项目管理

    原则177. 通过产品保证轮换人员

    原则178. 为每个中间产品提供名称和版本号码

    原则179. 控制基线

    原则180. 保存所有内容

    原则181. 跟踪每个变更

    原则182. 不要绕过变更控制

    原则183. 对变更请求进行排序和安排

    原则184. 在大型开发中使用验证和确认

演进原则

    原则185. 软件将持续变化

    原则186. 软件的熵会增加

    原则187. 如果没有损坏，就不要修复它

    原则188. 修复问题，而不是症状

    原则189. 首先更改需求

    原则190. 预发布的错误会导致发布后的错误

    原则191. 程序越旧，其维护就越困难

    原则192. 语言影响可维护性

    原则193. 有时最好重新开始

    原则194. 先整改最差的模块

    原则195. 维护比开发导致的错误更多

    原则196. 每次更改后都要进行回归测试

    原则197. 认为更改很容易，大多会导致错误

    原则198. 结构化非结构化代码不一定能改善它

    原则199. 在优化之前使用分析器

    原则200. 保持熟悉度

    原则201. 系统的存在促进进化

参考文献

[1] A. M. Davis, “201 Principles of Software Development,” McGraw-Hill, 1995; 日本語訳：松原友夫 訳,「ソフトウェア開発２０１の鉄則」, 日経BP社, 1996. 

微信公众号“数理逻辑与哲学逻辑”