软件架构概念

做开发工作十年了，去公司面试，面试官问：“你今后的职业规划是啥？” 我本无规划，如果非要问我规划，那就是朝着技术方向继续发展，技术方向发展的路线是什么？

1、程序员-高级程序员-架构师-cto

2、程序员-高级程序员-技术专家

这个只是我自己想到的，当然发展的路线可能有多样。比如有人喜欢写作，可以出书；有人喜欢演讲，可以做企业培训；有人喜欢做管理，可以管理项目；有人喜欢特定领域，比如图像识别，语音识别，NLP，可以做这方面专家，不断研究；有人喜欢创业和冒险，可以开公司；有人喜欢当老师，可以带学生。

其实不管最终做什么，前期的基础要打好，这个是关键。今天，我就来谈下，我眼中的软件架构和架构师。

什么是软件架构？

要明白什么是软件架构，必须要知道为什么需要架构。一句话，因为软件的复杂性，为了降低软件的复杂性而被迫做出的层次划分。想想经典的三层划分，为什么很经典？因为在每一层上面，可以继续分层。简单的，我们用三层，复杂的，三层可以扩充，它是有弹性的。docker出现的目的，就是解决部署的问题，微服务架构的出现，就是为了隔离不同的服务。

软件工程的目的是控制复杂性，而不是创造复杂性。

                                                                    ——Pamela Zave 博士

通用的定义:计算机系统内部组件的组合、整合和交互

ISO/IEC给出的定义：软件架构与软件密集型系统的组织有关，从利益相关者的角度解决问题和完成使命。

什么是利益相关者？

关注系统构建的所有个体，架构师、开发者、测试者、买家、最终用户、分析师等

以上的定义，太过于抽象，我理解的架构：明确需求，根据需求进行软件总体规划，输出一组规范，此规范是架构与具体开发的边界。当然架构的过程是很困难的，尤其是大型项目。比如架构决定使用AOP或者IOC、或者SOA，开发人员的实现，可以采用多种技术。现实中的架构师，会给出一些技术方面的指导和建议。

什么是明确需求？

ISO/IEC给出了软件质量的一些特征：

功能：软件能做的事情

可靠性：成熟性、容错性、可恢复性

可用性：被用户理解，有吸引力

效率：响应和性能

可维护性：修改的难易程度

可移植性：平台移植

需求可分为功能性需要和非功能性需求（如可伸缩性）

架构流程

根据开发方法来决定

1、瀑布模型对应前期架构

2、敏捷开发对应渐现架构或者浮现式架构，敏捷开发分为XP（极限编程）和Scrum

3、两种方法的结合，带有前期分析的渐现架构

架构师职责

1、确认需求

2、分解系统，分解为更小的系统和组件

3、识别和评估技术，就是平常所说的技术选型

4、制定规范，开发人员和架构师沟通的基础，以UML、Visio、思维导图等文档形式表示

小结：我见到的架构师是个狂傲的家伙，令人特别讨厌，曾经放出豪言：“我的开发效率至少是程序员的N倍以上。。。。。。”