怎样成为软件架构师？（一）

老子有云：“千里之行，始于足下”。
 
和大多数人一样，我是从一个软件开发人员开始自己的职业生涯，与团队合作开发软件系统。随着时间的推移，我开始设计自已的软件系统，
 
到现在我成为现在的位置，一名软件架构师，为企业提供软件架构设计，有很多技术团队从我的指导受益。
 
我很多时间是在IT咨询机构，这些客户和项目都需要软件系统。为了更好的服务客户，扩大组织就需要更多的人加入团队。了一创建一个好团队，就需要更多的软件架构师加入。
 
1、软件架构理论需要更易用：尽管业界有一些独特的导向，但我不觉得当时进入软件架构师有多容易。目前也有一些架构类的书籍，但角度却不尽相同。
我发现很多书是研究导向或学术性质的。如果是软件开发人员，他在寻找现实世界的解决方案。
 
所以，软件架构应该面向软件开发人员，程序员。
 
2、所有的软件项目都需要软件架构。我喜欢敏捷开发，在许多方法中缺乏对软件体系架构的明确关注。敏捷方法并不是表面的意义那样，不用事先做任何明确设计。这种结果就会导致错误的结果。因此，必须要有前瞻并充分的思考，特别是在一个背景复杂的团队时，这种决策就更重要。
 
 
我喜欢轻量级的软件体系和方法。这样可以像搭积木一样，及早形成一件作品，这种渐进式的成功让我更具成就感。
 
3、轻量级的软件架构实践
 
这段时光，我学习和发展了一些自己的软件架构方法论。包括软件设计过程、识别技术，沟通与记录软件架构的风险，以前我觉得这是常识，后来发现这些并不是个案。在过去的几年里，我已经把这些做法传达到成千上万的人们，并已经看到他们与以前架构的区别。
 
一种新的软件开发方法？不是，我要传达的是在传统的、普遍的、前沿思维之间寻找一个中间舒适的方法。对于发生在软件团队中考虑架构，包括对敏捷方法中的前期设计、架构演化的空间。
 
我们从最基本的开始，“架构”一词与大众心中的思维是有严格区别的，特别是在互联网上有着不同的定义。
 
在不同的场合和用户，我收集了对软件架构师的职责的定义，可谓非常全面：
 
• 模块，连接，依赖与接口
• 有大局观
• 改变的代价是昂贵的
• 难以改变的事物
• 设计时考虑到更大的图景
• 接口而不是实现
• 美学（匠人，干净的代码）
• 概念模型
• 满足非功能性要求/质量属性
• 一切都是“架构”
• 沟通能力（抽象，语言，词汇）
• 一个计划
• 鲁棒和坚固性
• 蓝图
• 系统，子系统，交互和接口
• 治理
• 战略决策的结果
• 必要的限制
• 结构（组件和交互）
• 技术方向
• 战略和愿景
• 架构模块
• 实现目标的过程
• 标准和准则
• 一整个系统
• 工具和方法
• 从需求到最终产品的路径
• 指导原则
• 技术领导
• 构成产品的元素之间的关系
• 意识到环境的限制和限制
• 创始人
• 抽象视图
• 把问题分解成更小的可实施的元素
• 产品的骨架/主干
 
天，真的很难找到一个单一定义！幸好有架构师是两个单词的组合：architect同时既是名词也是动词。
 
你认为哪个词最符合？我们下一节继续介绍 。