因此，我们应该根据项目进行的不同时期来保证工件的一致性。例如，在实现阶段的初期，设计尚未定性，花费大量的时间在设计文档上就没有什么必要，只需要准备一份草稿，在设计的时候随手记录下设计思路就可以了。注意，不要不做任何记录，人的记忆是最不可靠的，过目不忘只出现在小说中。而当项目逐渐成数的时候，我们就可以为其中成熟的设计进行文档化的工作了。这些可以根据需要发布给用户，也可以整合到构架中。
再来看第一个问题，如何保证不同工件之间的一致性。
同时维护3个工件的工作量，要比同时维护10个工件的工作量小的多。因此，我们应该尽可能的减少在每个关键点中需要保证一致性的工件数量。同时，我们需要区分，哪一些工件属于必须保持一致性的工件，哪些属于不需要随时更新的工件。例如，我们在需求分析中使用了CRC卡片，但是它的主要目的是为了顺利的进行沟通，并得到基本的分析类。这样的工件，保持它的一致性并没有太大的意义。这种思路类似于CMM中的KPI的思路，从软件开发过程中找出关键的工件，把有限的力量投入到保持这些关键工件的一致性上。虽然一致性狂热者未必认同这种做法，但是对于一个软件组织来说，最重要的是在有限的资源下的尽量提高软件开发能力。
在构架中包括一系列指南，来指导工件一致性是有必要的。较好的做法是结合 知识接力模式中的知识传递指南。例如，指导如何从需求说明书中提炼出接受测试和设计模型，这个过程本身就是保持一致性的过程。同时，光有书面的指导也是不够的，项目进行中，架构师之类的角色需要对开发人员进行指导（一对一的形式是最佳的）。这一点我们下文还会提到。
为一致性使用工具有时候也是很有必要的。例如，我们在 知识接力模式中就提到使用建模工具来保持设计模型和代码中信息的一致性。这里我们再次强调这一点，因为根据我们的经验，这种做法对于软件项目是非常重要的。因为设计是很难能够一开始就达到目标的，它需要不断的改进，而项目的最终期限决定我们不可能等到设计已经尽善尽美之后才开始编码。因此设计过程和编码过程一定是反复进行的。重构不断的发生 。我们需要不断的修改设计模型，而此时的设计模型和代码的信息的不一致就成为主要的矛盾了。一方面它延长了重构的时间，另一方面，它使得开发人员无法把精力集中在设计上。如果能够有工具来自动的完成这项工作，将会极大的提高生产率。
另一种工具是版本控制系统，是否使用版本控制系统和项目大小无关。再小的项目同样存在着版本问题，只是严重程度不同而已。因此将工件纳入到版本控制系统中来是较好的做法。对于小型的项目而言，并没有必要限制权限，但对于大一些的项目权限控制就有必要了。
一致性的组织保证
首先，如果不进行任何的管理，项目一定是不一致的。这和人的基因有关系。因此我们需要为一致性制定专门的人选。例如，需求的一致性应该由架构师和领域专家负责，模型的一致性由开发人员负责。但是最终需要一位总的负责人，他负责所有工件的一致性，包括技术和领域两方面，并决定是否将项目中的经验并入构架中。
不要让一致性为难你的开发人员。一致性是很容易滥用的，因此请确保正确的使用了它们。例如，制定缩进或留白之类的一致性标准并没有太大的意义，因为它的成本远远超出了它的意义，并且会遭到开发人员的严重反对。另外的例子包括过于严苛的编码规则、以及模式的滥用。这些都是经常会犯的错误。它并不会带来生产率的上升，只会另开发人员反感。避免它们的办法是，在制定一致性规则之前，先思考，该条规则的成本是否大过它的利益，开发人员是否愿意接受。
一旦定义了一致性规则之后，就需要进行培训。最好是通过例子来开始。例如，教授新的模式。如果你进行类似的培训，你就会发现，把正式的培训和非正式的指导相结合是很好的做法。因此，我们往往习惯把培训课程分为理论培训和实践两个部分。实践可以安排在课程结束就开始，也可以安排在项目进行中。
最后，一致性规则需要在整个开发过程中被不择不扣的执行。这是必须的。此外，还需要评估一致性规则的实际运作情况，如果有不充分或是不完善的情况，则需要改进它。如果效果不佳，则要考虑废除该规则。
小结
使用构架来保证大原则的一致性。
在事情未确定之前，工件可以是不一致的，但是在关键点时，工件必须是一致的。
尽量减少需要保持一致性的工件数量。
使用工具来维护一致性。
指定一致性的负责人。
一致性规则必须合理。
严格执行一致性，并根据实际情况改进一致性规则。
i. 关于重构是否需要彻底执行，目前也由不同的看法。XP主张重构应该要彻底、无情，直到没有重复代码为止。这和它缺少前期设计有关系。而敏捷方法的另一些方法论则认为，少量的代码重复并没有什么值得大惊小怪的。我们的观点是，对于需要进入构架的设计（例如商业组件），需要进行严格的重构、审查和测试。而对于一些外围的代码（例如脚本代码）则比较无所谓。
文章来源于领测软件测试网 https://www.ltesting.net/
