架构制图：工具与方法论( 三 )

3. 架构决定了产品质量

本文插图
如何衡量一个软件产品的质量？上图是 ISO/IEC 25010 标准定义的软件产品质量模型，包括以下 8 个大类：

功能适合性：功能完整度、功能正确性和功能恰当性；
性能效率：时间表现（e.g. 响应时间）、资源利用和容量；
兼容性：共存能力（e.g. 多版本组件共存）和互操作性；
可用性：可学习性、可运维性、用户错误保护（e.g. 自动纠错）、UI 美观度、可访问性；
可靠性：成熟度、可用性、容错性、可恢复性；
安全性：机密性、完整性、不可伪造性、权威性和可审计；
可维护性：模块度、可复用性、可分析性、可修改性、可测试性；
可移植性：可适配性、可安装性、可替代性。

上述质量模型中列出的所有点，都是架构设计需要着重考虑的。其中除了功能适合性以外，其他所有点都属于非功能需求的范畴，这也是区分架构好坏的真正分水岭 —— 好的架构设计，不会停留在仅满足功能需求这一最基本的需求层次上（最坏的架构设计也同样能做到），更重要且更难以应对的是其他众多的非功能需求。

本文插图
当然，鱼与熊掌不可兼得。架构与人生一样，也是一场权衡的游戏，弄不好就跟第八季的龙母一样的下场：既要又要还要，最后反而什么都得不到。好的架构师更应该像雪诺同志学习，表面上“know nothing” ，实际上“know everthing”：清楚系统所有利益相关者（stakeholders），努力挖掘各方的主要述求（concerns），相应平衡自己的架构决策（decisions），最终实现你好我好大家好的终极架构目标。
4. 我还能说出更多理由

本文插图
要不是篇幅所限，这一页 PPT 显然不够装：

架构包含系统所有最重要的早期决策，这些决策会进而影响后续所有大大小小的技术决策。因此，早期的架构设计需要非常严谨和慎重，要尽可能“一次做对”（虽然很难），否则越往后纠错的成本越高；
架构在组织内具有非常高的复用价值，因为同一组织内的产品之间一定会具备很多共性（需求、限制、环境等），很适合在架构层面进行最大化复用，避免重复解决相似的问题；
康威定律指出，软件架构反映了组织结构。这个结论反过来也成立：好的架构也会让组织结构变得更高效；
越庞大和复杂的系统，架构越重要，因为只有好的架构才能有效控制、管理和降低系统复杂度；
是不是越听越糊涂，仿佛架构有无数种诠释和意义？不必过于纠结，按照GoF的设计模式所述：Architecture is aboutthe important stuff. Whatever that is. 对，管它是啥，记住架构很重要就够了。

如何设计一个好的架构？
理解了架构的概念和重要性后，真正的架构师修炼之路才刚刚开始。如何设计一个好的架构？这显然是一个非常博大精深的主题，但并不是本文的重点，因此这里只简单列举了一些基本思想（原则）和经典套路（模式）。当然，架构设计更接近一门经验学科，仅停留在能脱口而出一些玄乎而高大上的理论概念肯定是不够的，需要结合实际工作内容和业务场景多多实践和揣摩才行，否则只能算是徘徊在架构的门外，连入门都谈不。
1. 架构原则（principles）