一般原则(GENERAL PRINCIPLES)
原则1 质量第一
QUALITY IS #1
原则2 质量在每个人眼中都不同
QUALITY IS IN THE EYES OF THE BEHOLDER
原则3 开发效率和质量密不可分
PRODUCTIVITY AND QUALITY ARE INSEPARABLE
原则4 高质量软件是可以实现的
HIGH-QUALITY SOFTWARE IS POSSIBLE
原则5 不要试图通过改进软件实现高质量
DON'T TRY TO RETROFIT QUALITY
原则6 低可靠性比低效率更糟糕
POOR RELIABILITY IS WORSE THAN POOR EFFICIENCY
原则7 尽早把产品交给客户
GIVE PRODUCTS TO CUSTOMERS EARLY
原则8 与客户/用户沟通
COMMUNICATE WITH CUSTOMERS/USERS
原则9 促使开发者与客户的目标一致
ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER
原则10 做好抛弃的准备
PLAN TO THROW ONE AWAY
原则11 开发正确的原型
BUILD THE RIGHT KIND OF PROTOTYPE
原则12 构建合适功能的原型
BUILD THE RIGHT FEATURES INTO A PROTOTYPE
原则13 要快速地开发一次性原型
BUILD THROWAWAY PROTOTYPES QUICKLY
原则14 渐进地扩展系统
GROW SYSTEMS INCREMENTALLY
原则15 看到越多，需要越多
THE MORE SEEN，THE MORE NEEDED
原则16 开发过程中的变化是不可避免的
CHANGE DURING DEVELOPMENT IS INEVITABLE
原则17 只要可能，购买而非开发
IF POSSIBLE，BUY INSTEAD OF BUILD
原则18 让软件只需简短的用户手册
BUILD SOFTWARE SO THAT IT NEEDS A SHORT USERS'MANUAL
原则19 每个复杂问题都有一个解决方案
EVERY COMPLEX PROBLEM HAS A SOLUTION
原则20 记录你的假设
RECORD YOUR ASSUMPTIONS
原则21不同的阶段，使用不同的语言
DIFFERENT LANGUAGES FOR DIFFERENT PHASES
原则22 技术优先于工具
TECHNIQUE BEFORE TOOLS
原则23 使用工具，但要务实
USE TOOLS，BUT BE REALISTIC
原则24 把工具交给优秀的工程师
GIVE SOFTWARE TOOLS TO GOOD ENGINEERS
原则25 CASE工具是昂贵的
CASE TOOLS ARE EXPENSIVE
原则26 "知道何时"和"知道如何"同样重要
“KNOW-WHEN”IS AS IMPORTANT AS KNOW-HOW
原则27 实现目标就停止
STOP WHEN YOU ACHIEVE YOUR GOAL
原则28 了解形式化方法
KNOW FORMAL METHODS
原则29 和组织荣辱与共
ALIGN REPUTATION WITH ORGANIZATION
原则30 跟风要小心
FOLLOW THE LEMMINGS WITH CARE
即使有五千万人说傻话，那仍然是傻话。——安那托尔·佛朗士(Anatole France)
原则31 不要忽视技术
DON'T IGONRE TECHNOLOGY
原则32 使用文档标准
USE DOCUMENTATION STANDARDS
原则33 文档要有术语表
EVERY DOCUMENT NEEDS A GLOSSARY
原则34 软件文档都要有索引
EVERY SOFTWARE DOCUMENT NEEDS AN INDEX
原则35 对相同的概念用相同的名字
USE THE SAME NAME FOR THE SAME CONCEPT
原则36 研究再转化，不可行
RESEARCH-THEN-TRANSFER DOESN'T WORK
原则37 要承担责任
TAKE RESPONSIBILITY
需求工程原则(REQUIREMENTS ENGINEERING PRINCIPLES)
需求工程包括以下活动:
- 提出或研究需要解决的问题；
- 具体说明一个能解决该问题的系统外部(黑盒)行为。
需求工程的最终产出是需求规格说明(Requirement Specification)。
原则38 低质量的需求分析，导致低质量的成本估算
POOR REQUIREMENTS YIELD POOR COST ESTIMATES
原则39 先确定问题，再写需求
DETERMINE THE PROBLEM BEFORE WRITING REQUIREMENTS
原则40 立即确定需求
DETERMINE THE REQUIREMENTS NOW
原则41 立即修复需求规格说明中的错误
FIX REQUIREMENTS SPECIFICATION ERRORS NOW
如果在需求规格说明中有错误，你将付出以下代价:
- 如果错误保持到系统设计阶段，定位和修复要多花5倍的代价。
- 如果保持到编码阶段，要多花10倍的代价。
- 如果保持到单元测试阶段，要多花20倍的代价。
- 如果保持到交付阶段，要多花200倍的代价。
这是“要在需求分析阶段修复错误”的最令人信服的证据。
原则42 原型可降低选择用户界面的风险
PROTOTYPES REDUCE RISK IN SELECTING USER INTERFACES
原则43 记录需求为什么被引入
RECORD WHY REQUIREMENTS WERE INCLUDED
原则44 确定子集
IDENTIFY SUBSETS
原则45 评审需求
REVIEW THE REQUIREMENTS
原则46 避免在需求分析时进行系统设计
AVOID DESIGN IN REQUREMENTS
原则47 使用正确的方法
USE THE RIGHT TECHNIQUES
原则48 使用多角度的需求视图
USE MULTIPLE VIEWS OF REQUIREMENTS
原则49 合理地组织需求
ORGANIZE REQUIREMENTS SENSIBLY
原则50 给需求排列优先级
PRIORITIZE REQUIREMENTS
原则51 书写要简洁
WRITE CONCISELY
原则52 给每个需求单独编号
SEPARATELY NUMBER EVERY REQUIREMENT
原则53 减少需求中的歧义
REDUCE AMBIGUITY IN REQUIREMENTS
原则54 对自然语言辅助增强，而非替换
AUGMENT，NEVER REPLACE，NATURAL LANGUAGE
原则55 在更形式化的模型前，先写自然语言
WRITE NATURAL LANGUAGE BEFORE A MORE FORMAL MODEL
原则56 保持需求规格说明的可读性
KEEP THE REQUIREMENTS SPECIFICATION READABLE
原则57 明确规定可靠性
SPECIFY RELIABILITY SPECIFICALLY
原则58 应明确环境超出预期时的系统行为
SPECIFY WHEN ENVIRONMENT VIOLATES "ACCEPTABLE" BEHAVIOR
原则59 自毁的待定项
SELF-DESTRUCT TBD'S
原则60 将需求保存到数据库
STORE REQUIREMENTS IN A DATABASE
设计原则 (DESIGN PRINCIPLES)
设计包括以下活动:
- 定义满足需求的软件架构(architecture)
- 具体说明架构中的各个软件组件的算法。架构包括: 软件中所有模块的定义，它们之间如何提供接口，它们之间如何组装，组件的拷贝如何实例化(即在内存中创建并执行的组件拷贝)和销毁。设计的最终产出是设计规格说明(DesignSpecification)。
原则61 从需求到设计的转换并不容易
TRANSITION FROM REQUIREMENTS TO DESIGN IS NOT EASY
原则62 将设计追溯至需求
TRACE DESIGN TO REQUIREMENTS
原则63 评估备选方案
EVALUATE ALTERNATIVES
原则64 没有文档的设计不是设计
DESIGN WITHOUT DOCUMENTATION IS NOT DESIGN
原则65 封装
ENCAPSULATE
原则66 不要重复造轮子
DON'T REINVENT THE WHEEL
原则67 保持简单
KEEP IT SIMPLE
原则68 避免大量的特殊案例
AVOID NUMEROUS SPECIAL CASES
原则69 缩小智力距离
MINIMIZE INTELLECTUAL DISTANCE
原则70 将设计置于知识控制之下
KEEP DESIGN UNDER INTELLECTUAL CONTROL
原则71 保持概念一致
MAINTAIN CONCEPTUAL INTEGRITY
原则72 概念性错误比语法错误更严重
CONCEPTUAL ERRORS ARE MORE SIGNIFICANT THAN SYNTACTIC ERRORS
原则73 使用耦合和内聚
USE COUPLING AND COHESION
耦合和内聚是由Larry Constantine和Edward Yourdon在20世纪70年代定义的。 它们依然是目前所知用来度量软件系统自身可维护性和适应性的最好方法。 简单来说，耦合，是对两个软件组件之间关联程度的度量。 内聚，是对一个软件组件内功能之间相关程度的度量。 我们要追求的是低耦合和高内聚。 高耦合意味着，当修改一个组件时，很可能需要修改其他组件。 低内聚意味着，难以分离出错误原因或者难以判断为满足新需求而要修改的位置。
原则74 为变化而设计
DESIGN FOR CHANGE
为了适应变化，设计需要做到:
- 模块化，即产品应该由独立的部分组成，每一部分可以很容易地被升级或替换，以对其他部分造成最小的影响(见原则65、70、73、80)。
- 可移植性，即产品应该很容易修改以适应新的硬件和操作系统。
- 可塑性，即产品可以灵活地适应预期外的新需求。
- 保证最小智力距离(见原则69)。
- 在智力可控范围内(见原则70)。
- 这样它就能表现出概念一致(见原则71)。
原则75 为维护而设计
DESIGN FOR MAINTENANCE
原则76 为防备出现错误而设计
DESIGN FOR ERRORS
不管你为软件付出多少努力，它都会有错误。你的设计决策应该尽可能做到以下优化:
- 不引入错误。
- 引入的错误容易被检测。
- 部署后软件中遗留的错误要么是不危险的，要么在执行时有补偿措施，这样错误不会造成灾难。
将这种健壮性融入设计并不容易。下面是一些有帮助的想法:
- 不要省略case语句。比如，如果某个变量有四个可能的值，不要只检查三种情况就假定第四个是剩下的唯一可能值。相反，要设想不可能情况的发生。要检查第四个可能值，并尽早处理错误情况。
- 要尽可能多地预想“不可能”的情况，并制定恢复策略。
- 为了减少可能造成灾难的情况，要对可预测的不安全情况进行故障树分析。
原则77 在软件中植入通用性
BUILD GENERALITY INTO SOFTWARE
原则78 在软件中植入灵活性
BUILD FLEXIBILITY INTO SOFTWARE
原则79 使用高效的算法
USE EFFICIENT ALGORITHMS
原则80 模块规格说明只提供用户需要的所有信息
MODULE SPECIFICATIONS PROVIDE ALL THE INFORMATION THE USER NEEDSAND NOTHING MORE
原则81 设计是多维的
DESIGN IS MULTIDIMENSIONAL
在设计一座房子时，建筑设计师需要以多种方式来描述，以方便建筑工人、建筑原材料购买者，以及房屋购买者来充分了解房屋的本质。这些描述方式包括：立面图、平面图、框架、电气图、管道图、门窗细节，以及其他。对于软件设计，也是一样的道理。 一份完整的软件设计至少需要包括：
- 打包方案(Packaging)。通常用层次图的形式给出，用于说明“什么是什么的一部分”，它通常隐含说明了数据可见性。它还能体现封装性，如对象内包含的数据和方法。
- 依赖层次(Needs Hierarchy)。用于说明“谁需要谁”。以组件网状图的形式表达，其中箭头的指向表明组件间的依赖关系。依赖可能是数据、逻辑或者其他信息。
- 调用关系(Invocation)。用于说明“谁调用谁”。以组件网状图的形式表达，其中箭头的指向表明组件间的调用、中断、消息传递关系等。
- 进程组织(Processes)。一批组件被组织在一起，作为异步处理的进程。这是与其他进程同时运行的组件副本。零个、一个或多个副本可能同时存在。另外，还需要说明导致进程创建、执行、停止或销毁的条件。
原则82 优秀的设计出自优秀的设计师
GREAT DESIGNS COME FROM GREAT DESIGNERS
优秀设计的特征是：
- 简洁 (Clean)
- 简单 (Simple)
- 优雅 (Elegant)
- 快速 (Fast)
- 可维护 (Maintainable)
- 易于实现(Easy to Implement)
优秀的设计源于灵感和洞察力，而不仅是努力工作或按部就班的设计方法。
原则83 理解你的应用场景
KNOW YOUR APPLICATION
原则84 无须太多投资，即可实现复用
YOU CAN REUSE WITHOUT A BIG INVESTMENT
原则85 “错进错出”是不正确的
“GARBAGE IN，GARBAGE OUT” IS INCORRECT
原则86 软件可靠性可以通过冗余来实现
SOFTWARE RELIABILITY CAN BE ACHIEVED THROUGH REDUNDANCY
编码原则 (CODING PRINCIPLES)
编码是包含以下行为的集合：
- 将设计阶段确定的算法转换为用计算机语言编写的程序。
- 将程序(通常是自动化的)转换为可被计算机直接执行的语言。
编码的主要输出结果就是程序清单。
原则87 避免使用特殊技巧
AVOID TRICKS
原则88 避免使用全局变量
AVOID GLOBAL VARIABLES
原则89 编写可自上而下阅读的程序
WRITE TO READ TOP-DOWN
原则90 避免副作用
AVOID SIDE-EFFECTS
原则91 使用有意义的命名
USE MEANINGFUL NAMES
原则92 程序首先是写给人看的
WRITE PROGRAMS FOR PEOPLE FIRST
原则93 使用最优的数据结构
USE OPTIMAL DATA STRUCTURES
原则94 先确保正确，再提升性能
GET IT RIGHT BEFORE YOU MAKE IT FASTER
原则95 在写完代码之前写注释
COMMENT BEFORE YOU FINALIZE YOUR CODE
原则96 先写文档后写代码
DOCUMENT BEFORE YOU START CODING
原则97 手动运行每个组件
HAND-EXECUTE EVERY COMPONENT
原则98 代码审查
INSPECT CODE
原则99 你可以使用非结构化的语言
YOU CAN USE UNSTRUCTURED LANGUAGES
原则100 结构化的代码未必是好的代码
STRUCTURED CODE IS NOT NECESSARILY GOOD CODE
原则101 不要嵌套太深
DON'T NEST TOO DEEP
原则102 使用合适的语言
USE APPROPRIATE LANGUAGES
原则103 编程语言不是借口
PROGRAMMING LANGUAGES IS NOT AN EXCUSE
原则104 编程语言的知识没那么重要
LANGUAGE KNOWLEDGE IS NOT SO IMPORTANT
原则105 格式化你的代码
FORMAT YOUR PROGRAMS
原则106 不要太早编码
DON'T CODE TOO SOON
测试原则 (TESTING PRINCIPLES)
测试是包含以下行为的集合:
- 对独立的软件组件执行测试(即单元测试，Unit Testing)，以确保其行为与组件设计规格说明中的定义足够接近。
- 对执行过单元测试的组件集合执行测试(即集成测试，Integration Testing)，以确保这些组件一起工作时的行为足够接近设计规格说明中的定义。
- 对集成测试过的所有组件进行测试(即软件系统级测试，Software Systems-level Testing)，以确保它们可以作为一个系统来运行，且行为足够接近软件需求规格说明中的定义。
- 制订软件系统级测试的测试计划。
- 制订软件集成测试的测试计划。
- 制订单元测试的测试计划。
- 建立测试装置(test harness)和测试环境(test environment)。
原则107 依据需求跟踪测试
TRACE TESTS TO REQUIREMENTS
原则108 在测试之前早做测试计划
PLAN TEST LONG BEFORE IT IS TIME TO TEST
原则109 不要测试自己开发的软件
DON'T TEST YOUR OWN SOFTWARE
原则110 不要为自己的软件做测试计划
DON'T WRITE YOUR OWN TEST PLANS
原则111 测试只能揭示缺陷的存在
TESTING EXPOSES PRESENCE OF FLAWS
原则112 虽然大量的错误可证明软件毫无价值，但是零错误并不能说明软件的价值
THOUGH COPIOUS ERRORS GUARANTEE WORTHLESSNESS，ZERO ERROR SAYS NOTHINGABOUT THE VALUE OF SOFTWARE
原则113 成功的测试应发现错误
A SUCCESSFUL TEST FINDS AN ERROR
原则114 半数的错误出现在15%的模块中
HALF THE ERRORS FOUND IN 15 PERCENT OF MODULES
原则115 使用黑盒测试和白盒测试
USE BLACK-BOX AND WHITE-BOX TESTING
原则116 测试用例应包含期望的结果
A TEST CASE INCLUDES EXPECTED RESULTS
原则117 测试不正确的输入
TEST INVALID INPUTS
原则118 压力测试必不可少
ALWAYS STRESS TEST
原则119 大爆炸理论不适用
THE BIG BANG THEORY DOES NOT APPLY
原则120 使用 McCabe 复杂度指标
USE MCCABE COMPLEXITY MEASURE
原则121 使用有效的测试完成度标准
USE EFFECTIVE TEST COMPLETION MEASURES
原则122 达成有效的测试覆盖
ACHIEVE EFFECTIVE TEST COVERAGE
原则123 不要在单元测试之前集成
DON'T INTEGRATE BEFORE UNIT TESTING
原则124 测量你的软件
INSTRUMENT YOUR SOFTWARE
原则125 分析错误的原因
ANALYZE CAUSES FOR ERRORS
原则126 对“错”不对人
DON'T TAKE ERRORS PERSONALLY
管理原则 (MANAGEMENT PRINCIPLES)
管理是围绕软件开发的所有工程活动，是进行计划(plan)、控制(control)、监视(monitor)和报告(report)的一组活动。
原则127 好的管理比好的技术更重要
GOOD MANAGEMENT IS MORE IMPORTANT THAN GOOD TECHNOLOGY
原则128 使用恰当的方法
USE APPROPRIATE SOLUTIONS
原则129 不要相信你读到的一切
DON'T BELIVE EVERYTHING YOU READ
原则130 理解客户的优先级
UNDERSTAND THE CUSTOMERS' PRIORITIES
原则131 人是成功的关键
PEOPLE ARE THE KEY TO SUCCESS
原则132 几个好手要强过很多生手
A FEW GOOD PEOPLE ARE BETTER THAN MANY LESS SKILLED PEOPLE
原则133 倾听你的员工
LISTEN TO YOUR PEOPLE
原则134 信任你的员工
TRUST YOUR PEOPLE
原则135 期望优秀
EXPECT EXCELLENCE
原则136 沟通技巧是必要的
COMMUNICATION SKILLS ARE ESSENTIAL
原则137 端茶送水
CARRY THE WATER
原则138 人们的动机是不同的
PEOPLE ARE MOTIVATED BY DEFFERENT THINGS
原则139 让办公室保持安静
KEEP THE OFFICE QUIET
原则140 人和时间是不可互换的
PEOPLE AND TIME ARE NOT INTERCHANGEABLE
原则141 软件工程师之间存在巨大的差异
THERE ARE HUGE DIFFERENCES AMONG SOFTWARE ENGINEERS
从最好的软件工程师到最差的软件工程师，研发效率（按每人每月完成的代码行来衡量）可能相差25倍之多，质量（按每千行代码中发现的错误量来衡量）可能相差10倍之多。
原则142 你可以优化任何你想要优化的
YOU CAN OPTIMIZE WHATEVER YOU WANT
原则143 隐蔽地收集数据
COLLECT DATA UNOBTRUSIVELY
原则144 每行代码的成本是没用的
COST PER LINE OF CODE IS NOT USEFUL
原则145 衡量开发效率没有完美的方法
THERE IS NO PERFECT WAY TO MEASURE PRODUCTIVITY
原则146 剪裁成本估算方法
TAILOR COST ESTIMATION METHODS
原则147 不要设定不切实际的截止时间
DON'T SET UNREALISTIC DEADLINES
原则148 避免不可能
AVOID THE IMPOSSIBLE
原则149 评估之前先要了解
KNOW BEFORE YOU COUNT
原则150 收集生产力数据
COLLECT PRODUCTIVITY DATA
原则151 不要忘记团队效率
DON' T FORGET TEAM PRODUCTIVITY
原则152 LOC/PM与语言无关
LOC/PM INDEPENDENT OF LANGUAGE
原则153 相信排期
BELIEVE THE SCHEDULE
原则154 精确的成本估算并不是万无一失的
A PRECISION-CRAFTED COST ESTIMATE IS NOT FOOLPROOF
原则155 定期重新评估排期
REASSESS SCHEDULES REGULARLY
原则156 轻微的低估不总是坏事
MINOR UNDERESTIMATES ARE NOT ALWAYS BAD
原则157 分配合适的资源
ALLOCATE APPROPRIATE RESOURCES
原则158 制订详细的项目计划
PLAN A PROJECT IN DETAIL
原则159 及时更新你的计划
KEEP YOUR PLAN UP-TO-DATE
原则160 避免驻波
AVOID STANDING WAVES
原则161 知晓十大风险
KNOW THE TOP 10 RISKS
作为项目经理，当你开始一个项目时，你需要熟悉最经常导致软件灾难的情况。这些是你最可能遇到的风险，但很可能不是全部。根据Boehm的说法，它们是:
- 人员短缺 (见原则131)。
- 不切实际的排期 (见原则148)。
- 不理解需求 (见原则40)。
- 开发糟糕的用户界面 (见原则42)。
- 当用户并不需要时尝试镀金 (见原则67)。
- 没有控制需求变更 (见原则179和189)。
- 缺乏可重用的或者接口化的组件。
- 外部执行任务不满足要求。
- 糟糕的响应时间。
- 试图超越当前计算机技术的能力。
原则162 预先了解风险
UNDERSTAND RISKS UP FRONT
原则163 使用适当的流程模型
USE AN APPROPRIATE PROCESS MODEL
原则164 方法无法挽救你
THE METHOD WON'T SAVE YOU
原则165 没有奇迹般提升效率的秘密
NO SECRETS FOR MIRACULOUS PRODUCTIVITY INCREASE
原则166 了解进度的含义
KNOW WHAT PROGRESS MEANS
原则167 按差异管理
MANAGE BY VARIANCE
原则168 不要过度使用你的硬件
DON'T OVERSTRAIN YOUR HARDWARE
原则169 对硬件的演化要乐观
BE OPTIMISTIC ABOUT HARDWARE EVOLUTION
原则170 对软件的进化要悲观
BE PESSIMISTIC ABOUT SOFTWARE EVOLUTION
原则171 认为灾难是不可能的想法往往导致灾难
THE THOUGHT THAT DISASTER IS IMPOSSIBLE OFTEN LEADS TO DISASTER
原则172 做项目总结
DO A PROJECT POSTMORTEM
第8章 产品保证原则 (PRODUCT ASSURANCE PRINCIPLES)
产品保证是通过使用分权制衡(checks and balances)来确保软件质量的一系列工作。产品保证通常包括如下几项。
- 软件配置管理(Software configuration management)：是管理软件变更的过程。
- 软件质量保证(Software quality assurance)：是检查所有做法和产品是否符合既定流程和标准的过程。
- 软件验证和确认(Software verification and validation)：这个过程用于验证(verify)每个中间产品是否正确地建立在以前的中间产品的基础上，以及确认(validate)每个中间产品是否适当地满足客户的要求。
- 测试(Testing)。
原则173 产品保证并不是奢侈品
PRODUCT ASSURANCE IS NOT A LUXURY
原则174 尽早建立软件配置管理过程
ESTABLISH SCM PROCEDURES EARLY
有效的软件配置管理 (SCM，Software Configuration Management) 不仅仅是一个记录谁在什么时候对代码和文档进行了怎样修改的工具。它还包括深思熟虑地创建命名约定、策略和过程，以确保所有相关方都能参与软件的更改。它必须根据每个项目进行定制。它的存在意味着：
- 我们知道怎样去报告一个软件问题。
- 我们知道怎样去提出一个新的需求。
- 所有利益相关方对于建议的改动都能知晓，且他们的意见都被考虑了。
- 有一块看板用于展示变更请求的优先级和排期。
- 所有基线化的中间产品或最终产品都在掌控之中 (即，它们不可能不遵循合规的流程而被修改)。
以上所有内容最好记录在一个文档中，这个文档通常被称为软件配置管理计划(SCMP，Software Configuration Management Plan)。这个文档应当在项目早期编写，典型的是在软件需求规格说明被评审通过的同时也被评审通过。
原则175 使软件配置管理适应软件过程
ADAPT SCM TO SOFTWARE PROCESS
原则176 组织SCM独立于项目管理
ORGANIZE SCM TO BE INDEPENDENT OF PROJECT MANAGEMENT
原则177 轮换人员到产品保证组织
ROTATE PEOPLE THROUGH PRODUCT ASSURANCE
原则178 给所有中间产品一个名称和版本
GIVE ALL INTERMEDIATE PRODUCTS A NAME AND VERSION
原则179 控制基准
CONTROL BASELINES
原则180 保存所有内容
SAVE EVERYTHING
原则181 跟踪每一个变更
KEEP TRACK OF EVERY CHANGE
每次变更都有可能引发问题。三个常见的问题是：
- 变更未解决预期要解决的问题。
- 变更解决了问题，但导致了其他问题。
- 在将来的某天变更被注意到时，没有人能弄清楚更改的原因 (或由谁更改)。
在这三种情况下，预防措施都是跟踪所有变更。
跟踪意味着记录：
- 最初的变更请求 (这可能是客户对新功能的请求，客户对故障的投诉，开发人员发现了一个问题，或者开发人员想要添加一个新功能)。
- 用于批准变更的审批流程 (谁，何时，为什么，在哪个发布版本中)。
- 所有中间产出的变更 (谁，什么，何时)。
- 在变更请求、变更审批和变更本身之间进行适当的交叉引用。
这样的审计追踪使你可以轻松撤销、重做并且/或者理解变更。
原则182 不要绕过变更控制
DON'T BYPASS CHANGE CONTROL
原则183 对变更请求进行分级和排期
RANK AND SCHEDULE CHANGE REQUESTS
原则184 在大型开发项目中使用确认和验证 (V＆V)
USE VALIDATION AND VERIFICATION (V＆V) ON LARGE DEVELOPMENTS
演变原则 (EVOLUTION PRINCIPLES)
演变是与修改软件产品相关的一系列工作，用于：
- 满足新功能。
- 更有效地运行。
- 正常运行(当检测到原始产品中的错误时)。
原则185 软件会持续变化
SOFTWARE WILL CONTINUE TO CHANGE
原则186 软件的熵增加
SOFTWARE'S ENTROPY INCREASES
原则187 如果没有坏，就不要修理它
IF IT AIN'T BROKE，DON'T FIX IT
原则188 解决问题，而不是症状
FIX PROBLEMS，NOT SYMPTOMS
原则189 先变更需求
CHANGE REQUIREMENTS FIRST
原则190 发布之前的错误也会在发布之后出现
PRERELEASE ERRORS YIELD POSTRELEASE ERRORS
原则191 一个程序越老，维护起来越困难
THE OLDER A PROGRAM，THE MORE DIFFICULT IT IS TO MAINTAIN
原则192 语言影响可维护性
LANGUAGE AFFECTS MAINTAINABILITY
原则193 有时重新开始会更好
SOMETIMES IT IS BETTER TO START OVER
原则194 首先翻新最差的
RENOVATE THE WORST FIRST
原则195 维护阶段比开发阶段产生的错误更多
MAINTENANCE CAUSES MORE ERRORS THAN DEVELOPMENT
原则196 每次变更后都要进行回归测试
REGRESSION TEST AFTER EVERY CHANGE
原则197 “变更很容易”的想法，会使变更更容易出错
BELIEF THAT A CHANGE IS EASY MAKES IT LIKELY IT WILL BE MADEINCORRECTLY
原则198 对非结构化代码进行结构化改造，并不一定会使它更好
STRUCTURING UNSTRUCTURED CODE DOES NOT NECESSARILY IMPROVE IT
原则199 在优化前先进行性能分析
USE PROFILER BEFORE OPTIMIZING
原则200 保持熟悉
CONSERVE FAMILIARITY
原则201 系统的存在促进了演变
THE SYSTEM'S EXISTENCE PROMOTES EVOLUTION