过程塑造: （四）一致性的思考

一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。可以想到，这又是一个需要权衡的问题。
意图
软件过程中的大部分工件都需要保持其相互之间的一致性。可是，工件越多，保持一致性的开销也就越大。我们需要在一致性和成本之间保持平衡。
示例
天利软件公司的项目经理正在为开发过程中出现的大量的不一致问题头疼不已。从软件过程一开始的需求阶段，版本问题就一直困扰着项目组的成员。项目组的成员并非没有经验，只是这一次的项目规模超过了以往的项目，因此公司决定采用严格的过程，以保证软件质量。开发过程中每个活动都必须产出文档。第一次的不一致发生在需求调研中期的一次研讨会上，当时的会议上发现了三种不同版本的需求规格书。之后情况越来越糟，文档的数量不断增多，由于所有的开发人员都需要编写文档、使用文档，因此发生了各种原先没有料到的事情，包括新文档被覆盖；设计人员手中的需求规格书不是最新的版本；设计书变更之后，代码却没有相应的变更；代码中的方法说明和设计模型中的方法说明不一致。为了对文档进行控制，公司不得不从项目组中抽调了两名开发人员来控制文档，并加强了文档的管理。但是随之而来的是开发周期的延长。
上下文
一致性包括两个方面：一是不同工件之间的一致性，二是使用同样的方法来处理问题。
软件过程的每个阶段都需要产出不同的工件。典型的例如需求分析阶段将产出需求规格书、用例模型、非功能需求等，设计阶段产出设计模型、类图。而在软件开发中，我们常常会遇到需求的变更的情况，因此我们需要依次对我们的需求模型、分析模型、设计模型、代码进行修改，以保持它们之间的一致性。如果项目处于前期阶段，这种修改量并不大，因为工件较少，如果项目进行到后期。需求的改变将会涉及到大量的工件。对于期限比较紧张的项目而言（这似乎是所有项目共同的特征），这种成本几乎是无法接受的。
另一方面，在同一个软件组织中，解决同样的问题有着不同的办法。不同的人有着不同的编码习惯、不同的目录组织方式、不同的类库、不同的框架。虽然我们并不反对同一问题的不同解法，但是当这种情况对项目的进展起到负面的效果的时候，我们就有必要来思考这个问题了。
问题
我们如何在一致性和一致性带来的成本之间做好平衡？我们如何保证不同工件之间的一致性，又该如何保证项目中解决方法的一致性。