软件开发这一行业要么是突飞猛进，要么是深陷囹圄。一方面，我们推动它向前发展，重塑我们构建软件的方式。另一方面，我们不断忘记过去的好，而且软件团队仍然在日常工作上没有什么惊人之举。

软件架构在成功的交付软件中扮演着关键角色，然而令人沮丧的是许多团队都是会忽视这一点。无论是一个人执行还是团队共享，架构角色都存在于敏捷团队中，但前期的平衡与进化的思考方式常常反应的是愿望而非现实。大问题是，在过去十年左右的时间软件体系架构已失宠。

1.软件架构并不是重大的前端设计

历来，软件架构都与大型前端设计和瀑布式项目有关，这时团队必将确保每一个软件设计的最后元素，在编码之前都有考虑到。软件架构基本上讲是软件系统的高层结构，以及你如何去理解它。这条小技巧是关于做出重大决策来影响软件系统状态，而不是理解数据库中的每一列应该是多久。

2.每一个软件项目都需要考虑软件架构

忽略规模和复杂性，所有的软件项目都需要考虑软件架构。你会问为什么？简单说，如果他们考虑不到，就会有不好的事情发生。如果软件架构是关于结构和愿景的，不考虑的话往往会导致结构不合理，内部软件系统不一致，难以理解；难以维护，以及可能无法满足一个或多个重要的非功能性需求，例如性能、可伸缩性和安全性。软件架构显性思考给你提供了一种方法来引入技术领导，并且可能会以你喜欢的方式堆栈出成功的交付。

3.软件架构就是编码、培训和协作

软件架构师的形象,很多人认为是传统的,“象牙塔”软件架构师，听写式指导一个完全信任他的开发团队。其实他并不需要这样，因为现代软件架构师更倾向于自己喜欢的编码、培训和协作设计。软件架构角色并不需要单一的一个人来承担，另外编码是了解架构最终是否有效一条很好的途径。

4.不必使用UML

再次，传统的软件架构视图常常让人联想起巨大的统一建模语言(UML)模型，试图捕捉每一点滴的细节。虽然创建并传达一个共同的愿景很重要，但你并不需要使用UML。事实上，你可能会说，UML软件对于交流软件架构并不是一个很好的方法。如果你的脑中有一些简单的指南，轻量级”框线”草图是软件架构有效沟通的一种方式。

5.好的软件架构需具备敏捷性

一直有人误解架构和敏捷是两股相互竞争的力量，他们之间存在着冲突。然而，事实并非如此。相反，好的软件架构需要具备敏捷性，帮助你拥抱并实现变化。好的软件架构不会靠自己构建，但需要做一些努力是必要的。