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

21CTO

资讯 0 3103 2017-11-15 11:56:26

老子有云：“千里之行，始于足下”。

和大多数人一样，我是从一个软件开发人员开始自己的职业生涯，与团队合作开发软件系统。随着时间的推移，我开始设计自已的软件系统，

到现在我成为现在的位置，一名软件架构师，为企业提供软件架构设计，有很多技术团队从我的指导受益。

我很多时间是在IT咨询机构，这些客户和项目都需要软件系统。为了更好的服务客户，扩大组织就需要更多的人加入团队。了一创建一个好团队，就需要更多的软件架构师加入。

1、软件架构理论需要更易用：尽管业界有一些独特的导向，但我不觉得当时进入软件架构师有多容易。目前也有一些架构类的书籍，但角度却不尽相同。
我发现很多书是研究导向或学术性质的。如果是软件开发人员，他在寻找现实世界的解决方案。

所以，软件架构应该面向软件开发人员，程序员。

2、所有的软件项目都需要软件架构。我喜欢敏捷开发，在许多方法中缺乏对软件体系架构的明确关注。敏捷方法并不是表面的意义那样，不用事先做任何明确设计。这种结果就会导致错误的结果。因此，必须要有前瞻并充分的思考，特别是在一个背景复杂的团队时，这种决策就更重要。

我喜欢轻量级的软件体系和方法。这样可以像搭积木一样，及早形成一件作品，这种渐进式的成功让我更具成就感。

3、轻量级的软件架构实践

这段时光，我学习和发展了一些自己的软件架构方法论。包括软件设计过程、识别技术，沟通与记录软件架构的风险，以前我觉得这是常识，后来发现这些并不是个案。在过去的几年里，我已经把这些做法传达到成千上万的人们，并已经看到他们与以前架构的区别。

一种新的软件开发方法？不是，我要传达的是在传统的、普遍的、前沿思维之间寻找一个中间舒适的方法。对于发生在软件团队中考虑架构，包括对敏捷方法中的前期设计、架构演化的空间。

我们从最基本的开始，“架构”一词与大众心中的思维是有严格区别的，特别是在互联网上有着不同的定义。

在不同的场合和用户，我收集了对软件架构师的职责的定义，可谓非常全面：

• 模块，连接，依赖与接口
• 有大局观
• 改变的代价是昂贵的
• 难以改变的事物
• 设计时考虑到更大的图景
• 接口而不是实现
• 美学（匠人，干净的代码）
• 概念模型
• 满足非功能性要求/质量属性
• 一切都是“架构”
• 沟通能力（抽象，语言，词汇）
• 一个计划
• 鲁棒和坚固性
• 蓝图
• 系统，子系统，交互和接口
• 治理
• 战略决策的结果
• 必要的限制
• 结构（组件和交互）
• 技术方向
• 战略和愿景
• 架构模块
• 实现目标的过程
• 标准和准则
• 一整个系统
• 工具和方法
• 从需求到最终产品的路径
• 指导原则
• 技术领导
• 构成产品的元素之间的关系
• 意识到环境的限制和限制
• 创始人
• 抽象视图
• 把问题分解成更小的可实施的元素
• 产品的骨架/主干

天，真的很难找到一个单一定义！幸好有架构师是两个单词的组合：architect同时既是名词也是动词。

你认为哪个词最符合？我们下一节继续介绍。

本文为 @ 21CTO 创作并授权 21CTO 发布，未经许可，请勿转载。

内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。

该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。