怎样成为软件架构师?(一)


tobejiagoushi.png

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

0 个评论

要回复文章请先登录注册