作者 | Alan Tai
在过去的 20 年里,作为一名软件工程师和软件架构师,我与不同领域和不同学科的软件工程师聊过很多次。他们中有一些人是有着 8 到 10 年经验的高级工程师,有许多人还在职业生涯早期,有着 3 到 5 年的经验。其中一些人是我的同事。有些人是求职者。聊到最后,他们几乎都会问到同样一个问题:
“我想成为一名解决方案架构师。了解更多架构相关内容的资源有哪些?“——很多软件工程师都会问的一个问题。
他们问错了问题。如果你读下去,就会知道为什么我这么说。此外,撰写本文时我的公司正在招聘首席软件架构师,所以我正好解释一下什么是软件架构师以及如何成为一名软件架构师。
1什么是软件架构?
首先什么是软件架构?提到软件架构师这个头衔,就经常听到拿建筑的架构与之作比。建筑架构师设计建筑的蓝图。工程师们将其实体按照该蓝图建造起来。我认为从很多方面来看,这都是一个糟糕的类比。
建筑的类比使人们过于关注系统的静态面。在这方面,城市建设是一个更好的类比,因为它既包括道路、建筑和桥梁等静态元素,也包括交通流量和城市居民等动态元素。城市架构师提出城市设计,制定计划来安排如何建设城市以及如何将所有东西组合在一起。最后但并非最不重要的是,城市架构师有一个城市将如何发展的愿景。但是软件架构还不仅如此。有时软件架构师需要放大或缩小”城市“,以确保计划可行。架构师可能不会太关心建筑的室内设计,而把重点放在决定在哪里放置红绿灯上。架构师需要广泛且深厚的技术知识,才能构建像城市一样复杂的软件。架构师还需要在不涉及所有技术细节的情况下向业务涉众传递一致的消息。
建筑架构的类比意味着架构师是团队中最资深的人,他做出所有关键的决定,预先创建设计规范,然后在实现过程中执行设计。起初,在很多人看来,成为那个最有经验的人,达到技术级别的顶端,是一件很酷的事情。让整个团队都听你的,服从你的命令和决定,可能会让你感觉好极了。但是,你再好好想想,这给了架构师一定要做出正确决策的巨大压力,而这在项目的早期阶段通常是不太可能的。在敏捷团队中,这意味着开发团队不是自组织的,架构师成了团队变得敏捷的障碍。架构师剥夺了团队的所有自主权。谁愿意在如此高的压力下担任这样

本文作者,资深软件架构师Alan Tai分享了他对软件架构的理解,指出成为架构师不应仅关注技术,而应关注如何连接业务与技术。软件架构师需要具备广泛而深入的技术知识,与开发团队紧密合作,具备良好的沟通和领导能力,以及对业务目标的深刻理解。文章强调,架构师的角色是迭代的,需要随着业务需求的变化而演进。
最低0.47元/天 解锁文章
1650

被折叠的 条评论
为什么被折叠?



