写点什么
创作场景
- 记录自己日常工作的实践、心得
- 发表对生活和职场的感悟
- 针对感兴趣的事件发表随笔或者杂谈
- 从 0 到 1 详细介绍你掌握的一门语言、一个技术,或者一个兴趣、爱好
- 或者,就直接把你的个人博客、公众号直接搬到这里
登录/注册
在本系列文章中,作者根据团队所做的关于系统如何处理质量属性需求(QAR)的决策来重新构建软件架构。在他们看来,根据决策重新构建的软件架构通过明确团队所做的选择及其原因让系统的工作原理变得更加清晰。

软件架构是一个常常被人误解的概念。

软件开发团队一直反对“前期大设计”,而倾向于自组织团队中出现的架构设计,这可能导致低估软件架构重要性的心态。

作为最小可行产品的一部分,创建一个最小可行架构可以帮助团队评估技术可行性,并为产品提供一个稳定的基础,可以随着产品的演进进行调整。

即使是简单的应用程序,比如本文所描述的应用程序,也需要最小可行产品(MVP)和最小可行架构(MVA)。

在真正需要之前,不要对任何特定的框架、模式或策略过多投入。

遗留应用的每个版本,都可以视为一个 MVP。

在设计最小可行架构时,开发人员也必须考虑资源所处的位置,特别是当移动应用程序是分布式系统的一部分时。