软件架构师不等同于资深程序员

本文的作者Armel Nene是ETAPIX Global公司的首席架构师，他居住在伦敦，他参与过的开源项目包括 Apache Lucene,，Apache Nutch， Liferay 和 Pentaho等。

 

如今很多的公司的IT部门仍然认为招聘一个资深的程序员，他同样也能承担软件架构师的角色。

 

资深程序员对整个软件生命周期很了解，他们可以经过培训成为架构师，但他们不等同于架构师。一个软件架构师首要的和最重要的是他的远见。如果一个架构师拥有一些软件开发经验，那会更好，但大多时候，他们面对的是一个多语言的复杂环境。在第一行代码开始编写之前，架构师需要制定出业务需求如何转变成解决方案。这不仅仅需要业务环境的相关知识，从业务操作到客户环境，他还需要向公司上级勾画出一个令人信服的系统。如果有些问题不事先考虑，如扩展性，访问延迟问题，安全问题，系统开始开发时就会忽略这些。而资深程序员了解自己的团队，了解他们的能力。资深程序员知道如何管理工作进度，确保开发中的软件如何实现架构设计的目标。

 

架构师能决定的是需求应该如何开发才能满足业务需要，例如：

这个业务分布全球，业务在需求上需要网站响应延迟不超过3秒——不管用户在什么地方，网站最少要能承受10万以上的用户访问量。

上面的需求涉及的是系统的架构，而不是形如我们如何用Oracle数据库来对用户安全认证的问题。

有很重要的一点需要注意，很多的软件架构师在之前都是资深程序员(比如我自己)，尽管如此，很多的资深程序员对架构设计并不感兴趣。决定一个系统是该使用Tomcat还是Glassfish，是否要用Apache Webserver做负载均衡，这属于架构事务。做代码审查，确保设计模式被正确的应用，这是资深程序员的事务。资深程序员可以决定开发方法，比如使用敏捷开发方法，但需要项目经理的认可。架构师要参加项目各方一起的会议：用户，经营方，基础设施提供方，开发，测试人员。当用户询问为什么系统缓慢时，他们会找架构师，架构师则会找资深开发负责人研究目前的开发是否达到了架构设计目标，或看看架构设计上是否有缺陷。

 

我是一名软件架构师，我可以轻松的把我的见解表达给开发团队，但同时我也是一名资深程序员，我仍然热爱编程。我在一个软件架构协会工作，经常会遇到一些没有开发经验的架构师，我不认同他们的这种出身。软件架构师应该了解各种语言的特点，而不是只偏爱自己喜欢的那种。

 

我希望有更多的软件公司能认识到在软件项目中架构师的价值——不论项目有多大有多小。

本文转载自：http://www.aqee.net/a-software-architect-is-not-a-senior-developer/

[英文原文：A software architect is not a senior developer ]

评论

14 楼 zhangcs053 2014-01-10  

bitray 写道

zhangcs053 写道

同意你的说法，架构师应该了解各种语言，就像建筑师需要了解化学一样，如何开发和如何建筑本质上是相同的，如果软件系统向建筑一样，第一眼就让人觉得很漂亮，它一定足够优美

估计多语言很难，架构师应该了解的和深入理解功能性需求和非功能性需求，并且根据非功能性需求进行深入的研究和分析。要求多种语言的太难了，一个架构师有着解决问题的能力，并且有大局观，敏捷的思维就够了。

我不想去争论什么，很多优秀的架构不是由单一的语言完成，像facebook，部分服务由c语言开发，部分服务由java开发，部分服务有php开发，为什么要这么做，因为这样足够清晰，各司其职，看到就知道它将要负责什么，如果一个大型系统，由一中语言开发，我可以想象代码量以及复杂程度，如果没有ant这样的工具就是一个灾难

13 楼 niva 2014-01-06  

cwqcwqmax9 写道

在这种客户需求不断变化，公司不肯花时间稳定需求只求一味快速的盈利为目的的中国IT文化氛围中  对用敏捷表示怀疑

那怎么办？冻结需求？

12 楼 bitray 2014-01-06  

zhangcs053 写道

同意你的说法，架构师应该了解各种语言，就像建筑师需要了解化学一样，如何开发和如何建筑本质上是相同的，如果软件系统向建筑一样，第一眼就让人觉得很漂亮，它一定足够优美

估计多语言很难，架构师应该了解的和深入理解功能性需求和非功能性需求，并且根据非功能性需求进行深入的研究和分析。要求多种语言的太难了，一个架构师有着解决问题的能力，并且有大局观，敏捷的思维就够了。

11 楼 cwqcwqmax9 2014-01-06  

在户需求不断变化下用敏捷，你试试看，保证你死得极惨

加班加到挂水

10 楼 cwqcwqmax9 2014-01-06  

在这种客户需求不断变化，公司不肯花时间稳定需求只求一味快速的盈利为目的的中国IT文化氛围中  对用敏捷表示怀疑

9 楼 cuippan 2014-01-05  

niva 写道

ningboxiao 写道

随着项目的展开，虽然是敏捷，但是要想改动架构或者一些底层的东西就很困难了

这说明两个问题：
1.这个项目肯定不是真正的敏捷，很可能是打着敏捷的幌子，搞瀑布的东西。
2.把底层作为核心，而不是把业务作为核心，证明负责这个项目的人，完全不懂面向对象。

8 楼 niva 2014-01-05  

ningboxiao 写道

随着项目的展开，虽然是敏捷，但是要想改动架构或者一些底层的东西就很困难了

这说明两个问题：
1.这个项目肯定不是真正的敏捷，很可能是打着敏捷的幌子，搞瀑布的东西。
2.把底层作为核心，而不是把业务作为核心，证明负责这个项目的人，完全不懂面向对象。

7 楼 jueyue 2014-01-04  

之前一直 不理解架构师与程序员的区别,现在慢慢理解了,好文章

6 楼 颠才泪狼空色 2014-01-04  

非常赞同，现在又多小公司，开发一个系统的时候都是优先上线为主，然后后期才开始恶补一些问题。

5 楼 ningboxiao 2014-01-04  

zhangcs053 写道

同意你的说法，架构师应该了解各种语言，就像建筑师需要了解化学一样，如何开发和如何建筑本质上是相同的，如果软件系统向建筑一样，第一眼就让人觉得很漂亮，它一定足够优美

4 楼 ningboxiao 2014-01-04  

不太同意你的看法，虽然提倡敏捷，但是如果在项目一开始，架构设计阶段没有考虑扩展性等问题，那么产品的架子就会存在问题，随着项目的展开，虽然是敏捷，但是要想改动架构或者一些底层的东西就很困难了，这也是架构师需要通盘考虑的问题

niva 写道

虽然很佩服作者的成就，但这种观点明显与敏捷理念相悖，如果是按敏捷方法，不可能一上来就考虑扩展性，访问延迟问题，安全问题这些东西，这些肯定是后面循环轮次才需要考虑的东西。

3 楼 zhangcs053 2014-01-04  

同意你的说法，架构师应该了解各种语言，就像建筑师需要了解化学一样，如何开发和如何建筑本质上是相同的，如果软件系统向建筑一样，第一眼就让人觉得很漂亮，它一定足够优美

2 楼 niva 2014-01-04  

虽然很佩服作者的成就，但这种观点明显与敏捷理念相悖，如果是按敏捷方法，不可能一上来就考虑扩展性，访问延迟问题，安全问题这些东西，这些肯定是后面循环轮次才需要考虑的东西。

1 楼 chenfuzhao 2014-01-04  

我很是赞同。