usb协议架构及驱动架构_自我驱动架构

usb协议架构及驱动架构

谁负责软件体系结构，无论是高级开发人员，整个团队（如敏捷实践中的专家）或按性别划分的架构师，应用我喜欢的“自我驱动架构”（简称EDA，简称EDA）是一种深层的趋势。被事件驱动架构弄错了）。

当必须选择一种体系结构时，应该从许多客观标准中进行设计，包括：

• 业务需求，
• 技术限制，
• 使用方便，
• 维修费用，
• 等等

甚至有人认为您应该注意主观但实际的限制：

• 跨服务战（在开发团队和生产团队之间），
• 人际问题（项目经理和首席开发人员之间），
• 历史偏见（不使用EJB3，因为EJB2开发太复杂了），
• 等等

通常，然后为每个标准分配一个优先级，设计的体系结构的目标是根据优先级来回答最多的标准。 E，使用EDA时 ，最高优先级标准完​​全不同：无论有什么限制和要求， 项目中使用的技术都应使建筑师的CV更加明亮 。

如果您还不知道我在说什么，可以想象一个架构师在项目上使用EJB3，尽管生产应用程序服务器尚未准备好运行它们。 或者，架构师敦促生产团队升级到最新版本的应用程序服务器，尽管没有真正的需要。 我知道您已经看到了这种行为。

有许多因素促成EDA的蓬勃发展：

1. 专门的技术团队无法验证项目架构。 由于业务资金（读取能力）的原因，要么没有这样的跨项目团队，要么对体系结构的选择没有影响。 请记住，既然钱来自企业，总是很难告诉他们“不”。
2. 负责设计的建筑师是初级。 他们绝对想充分利用他们在Web上发布的文章中所阅读的内容。 不要冒犯任何人，但是在使用Scala等工具之前，如果有人已经有了足够的反馈会更好吗？
3. 仅在项目进行期间聘用建筑师。 如果在项目交付时您的贡献停止了，那就是尝试非常规技术的巨大动力。 尝试与内部IS团队交谈，您会发现“ veni，vedi，vici ”综合征是外包的最大不满原因，因为它们通常最终会清除垃圾。

尽管如此，EDA的根本原因还是架构师的错误估计。 即使是全球化的IS世界也非常有限。 您总是与同一个人一起工作。 如果您练习EDA，迟早会发现有人会记住您，因为他是提出该架构的人，而该人杀死了该项目。 我们的工作非常复杂，没有考虑到架构师的自我，却考虑到了每个业务需求，每个技术约束，每个服务战。 所以请不要使用EDA

这并不意味着您不应该努力在体系结构中使用相关技术，而是应该基于客观原因，而不是基于职业。

翻译自: https://blog.frankel.ch/ego-driven-architecture/

usb协议架构及驱动架构