认识达内从这里开始

DevOps编程开发是目前大多数软件开发程序员都在学习与应用的一种软件开发模式，下面我们就通过案例分析来了解一下，DevOps编程反模式类型都有哪些。

反模式1：服务层不是自助服务层。

假设服务层需要它的消费者与某人或某物取得联系，在这种情况下，引入的依赖关系会减缓开发流程，浪费使用者和提供者的时间，因为好将其自动化。

为了提高效率并使服务层能够扩展，有必要在整个过程中提供自助服务功能。这样，使用者就可以独立使用服务，而无需等待或依赖于服务提供者。

反模式2：使用者需要知道服务实现的技术细节才能使用它。

如果人们想要使用特定服务，不应该需要知道它的技术规范。例如，如果消费者需要知道服务层引入了新的语言或框架，那就会增加DevOps团队所需的知识。而由于团队需要在核心技术栈和服务层的其他语言、框架之间切换，这将降低人们的工作效率。如果配置不能通过服务接口快速完成，那么就需要记住大量的技术知识。

抽象的技术实现，让服务易于使用!但只是将不相关的复杂性进行抽象，而不会影响到重要的功能。

消费者也是特定应用程序的开发人员，他们知道自己应用程序的技术栈，并且是这个领域的专家。如果他们使用来自三方的服务，技术实现必然与他们无关。当然，他们需要知道服务以及它是如何工作的，但是实现细节并不相关。

反模式3：对消费者而言，服务不够一目了然。

如果不够一目了然，那么这个服务要么不会被使用，要么使用者需要联系提供者以获得所需的信息。和人的接触会大大减缓使用过程。既浪费了时间，又浪费了金钱。

为了提供更好的消费体验，服务应该是一目了然、不言自明的。通过创建一个向导来描述必要的步骤，或者提供内置在服务接口中的步骤指南。同时，倾听消费者的诉求。反馈很关键，消费者和提供者之间的工作反馈循环是高质量服务层的支柱。

反模式4：开发人员不知道服务存在或找不到它。

营销是关键!作为供应商，你的工作是向消费者宣传你提供的产品以及告诉他们如何消费这些产品。提供包含消费者所需的所有信息的完整的服务中心、新的概述，提供订阅功能，从而使新信息也成为自助服务，从而能够自动通知消费者关于更改或新版本的信息。

如果服务不为人知，就不会被使用。

如果你有一个大型服务层，组织定期的谈话或小型的活动，让消费者了解新的新闻和功能。

反模式5：在服务层中没有版本控制。

如果没有实现版本控制，那么当新版本发布时，所有使用者都必须立即切换到新版本，这既不稳定也不安全。要提供安全的环境，请确保支持服务层的旧版本，直到所有使用者都切换到新版本。一旦旧版本不再使用，提供者可以安全的删除它。

始终以新版本提供服务的变更，同时继续维护旧版本的服务!

不要强迫用户立即切换到更新的版本，这将使得他们不得不做不能为应用程序提供额外价值的事情，而这可能会阻止某些更重要的更改。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。