软件架构概念
做开发工作十年了，去公司面试，面试官问：“你今后的职业规划是啥？” 我本无规划，如果非要问我规划，那就是朝着技术方向继续发展，技术方向发展的路线是什么？
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倍以上。。。。。。”