读了这个标题后，你也许立刻会以为我们会说，瀑布开发周期是在高可扩展的环境中取得成功的关键。屏障条件或者开始和结束条件通常会被关联到瀑布开发周期的某个阶段，有时会被看作瀑布开发模型具有灵活性的原因之一。但我们的意图并不是要推荐瀑布开发方法，而是要讨论无论采用哪种开发方法都需要的标准和保护措施。
读了这个标题后，你也许立刻会以为我们会说，瀑布开发周期是在高可扩展的环境中取得成功的关键。屏障条件或者开始和结束条件通常会被关联到瀑布开发周期的某个阶段，有时会被看作瀑布开发模型具有灵活性的原因之一。但我们的意图并不是要推荐瀑布开发方法，而是要讨论无论采用哪种开发方法都需要的标准和保护措施。
出于这一目的，我们假设屏障条件是一种标准，根据这种标准可以判断你的开发生命周期是成功了，还是失败了。在理想状况下，你会在开发生合周期中设置这些条件或检查点，以便帮助你判断在开发产品或改善产品时，你是否确实在沿着正确的路径前进。屏障条件是开发过程中于可扩展性来说，屏障条件可以是在实施一个设计之前， 在架构评审委员会的会议上对它进行桌的静态目标，每隔定时间就要检查一次， 以确保你在开发的东西是符合你的愿景和需要的。对面检查，看它是否符合架构设计原则；也可以是对一一个实现进行代码审查，确保它与设计一致；还可以是在QA过程中对一个实现进行性能测试，然后衡量把它发布到生产环境后会对可扩展性造成哪些影响。
可扩展性的屏障条件示例
我们通常建议在你的开发方法或开发生命周期中加入下列屏障条件。它们每一个的目的都是为了限制在生产环境中发生扩展问题的可能性以及它们造成的影响。
1.架构评审委员会。ARB的存在是为了确保设计符合架构设计原则。而架构设计原则相应对应了一个或多个关键的可扩展性原则。这个屏障的目的是为了确保不浪费时间实施或开发难以扩展或不能扩展到满足你的需求的系统。
2.代码审查。如果你已经有了强大的代码审查流程，那么可以修改该流程，以确保被审查的系统实现进守了架构设计原则，这样可以确保在QA发现系统的扩展问题，要求修复它之前，就能够先行修复它了。
3.性能测试。性能测试可以在把系统引入生产环境之前，就发现潜在的问题，并且发现可扩展性带来的问题可能对客户产生的影响。
4.生产环境监控和评估。在理想状况下，你的系统应该被设计为能够监控的。即使它是不可监控的，在发布之后，也要从用户的角度、应用的角度和系统的角度捕捉关键的性能数据，与上一次发布的版本的性能数据进行对比，这样有助于在潜在的扩展问题影响到客户之前，就及早地发现它们。
也许你的流程中还有其他的屏障条件，长期以来你都觉得它们很有用。不过我们认为，要管理发布的系统由于扩展带来的问题而对客户产生负面影响的风险，至少需要采用上述的屏障条件。
可能您还想看