敏捷和架构的冲突
![](/theme/default/default/images/main/eye-open.png)
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
![](/theme/default/default/images/main/icon-link.png)
![](/theme/default/default/images/main/icon-jing.png)
敏捷方法和企业架构设计之间存在一定的冲突。敏捷开发倾向于根据业务领域的深入理解逐步调整设计,而架构设计则需要建立起能够展示给利益相关者并满足质量属性的技术架构。然而,实际上,将敏捷方法用于引导架构设计可以实现双赢的局面。Tom Graves指出,敏捷需要像脊柱一样的结构来提供支持和指引方向,从而提高工作效率,而软件架构就提供了这种支持。
Jan Van Til认同Tom的看法,强调了坚实的“后台”脊柱对于展示“前端”的敏捷性是必不可少的。没有一个稳定的后台支撑,我们无法识别出哪些是新潮的。Simon Brown和John Bauer认为,敏捷项目经常面临架构问题,需要在早期迭代中解决。他们提倡“刚刚好”的架构设计,既不是做过多的预先设计,也不是完全没有设计,而是要保持平衡。
James Coplien和Kevlin Henney介绍了一种从项目开始就进行恰到好处的架构设计的有效方法,这在实际中确保了项目的成功。Simon Brown通过提出一个挑战,要求在4个月内用敏捷方法重新开发一个在线银行系统,展示了怎样在实际中实现这种平衡。他的博文中列出了多种方案,并鼓励大家提出自己的想法,表明架构设计和敏捷不仅可以共存,还可以相互合作。
Simon Brown对“刚刚好”的架构进行了定义,认为它应当使人们清楚地了解目标及其实现方式。架构是重大决定,因为其修改成本高昂。例如,质量属性如性能、扩展性、安全性和可用性通常需要在早期就纳入基础框架中,因为在后期修改现有代码库会非常困难。架构设计不是某个下午就能简单重构的事项,它涉及核心技术选择、架构模式和框架等。
想要了解更多内容?
![](/theme/default/default/images/main/icon-link.png)
![](/theme/default/default/images/main/icon-jing.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)